One working mailbox password let an Exchange user read everyone else's mail, and the cloud was fixed before anyone was told

On 2 October 2026, Microsoft published an out-of-band advisory for CVE-2026-96940, an elevation of privilege flaw in Exchange Server scored 8.8.

The flaw is in Exchange's authorisation logic. A user who is already authenticated can, under certain conditions, reach other users' mailboxes and read their messages, including bodies and file attachments.

Microsoft found it internally and says it is not aware of active exploitation.

The bar is one account

The requirement is valid credentials for any mailbox in the organisation. Not an administrator. Not a privileged service account. Any one.

In an organisation of a thousand people, that is a thousand chances for someone to reuse a password, fall for a phish, or leave a token in a repository. The attacker does not need to pick a target; they need any employee, and then they choose the target afterwards.

This is what makes an 8.8 that needs authentication worth more attention than the score suggests. Authentication as a prerequisite is a meaningful barrier when the credential has to belong to someone specific. When it can belong to anyone at all, it is closer to a formality — and the recent work on credentials that stay live for years in public repositories is a reminder of how large the pool of anyone is.

What it is not

The limits matter and Microsoft states them.

There is no cross-tenant access, so this does not reach other organisations. There is no unauthenticated remote code execution. And the access is read-only: no writing, no deleting, no administrative control over the mailboxes reached.

Read-only sounds like the mild version. For a mailbox it is most of the harm. Mail is where contracts, credentials, legal advice, personal matters and password reset links live. An attacker who can read the chief executive's mail and nobody else's inbox has what they came for, and read-only access leaves far less evidence than anything that writes.

Two populations, two experiences

The part of this advisory worth sitting with is the split in who had to do anything.

Microsoft applied a service-side mitigation to Exchange Online. Microsoft 365 customers had nothing to do, and for most of them the fix was already in place when the advisory appeared.

On-premises Exchange stays exposed until an administrator installs the cumulative update. Learning about it and fixing it are separate events, days or weeks apart depending on the change window.

Who is still on-premises is the uncomfortable part. Government bodies. Regulated industries. Defence suppliers. Organisations in jurisdictions with data residency rules, and organisations that made a deliberate decision not to put their mail in somebody else's infrastructure. The population carrying the exposure is disproportionately the one with the most sensitive mail, and that is structural rather than accidental — it is the same asymmetry every hybrid Exchange advisory produces.

Mail infrastructure has been the recurring target this month, from the FortiMail flaw CISA gave agencies three days to fix to the iCloud parsing bugs. The common thread is not a shared bug class. It is that mail is where the valuable text is.

What to do

• Install the cumulative update on every on-premises Exchange server, including the one nobody has touched since the migration that was never finished.
• If you are hybrid, confirm which servers are actually yours to patch. Organisations part-way through a migration routinely keep a server for mail flow and stop counting it as a mail server.
• Look at mailbox access logs for the exposure window. The flaw is read-only, which means the only trace is an access pattern, not a change.
• Reduce the pool of anyone. This needs one working credential, so the controls that matter are the ordinary ones — phishing-resistant MFA, and getting rid of accounts that should not still work.

What is not established

• Whether it has been exploited. Microsoft says it is not aware of any, which is not the same as none.
• The specific conditions under which the authorisation check fails, which Microsoft has not detailed.
• How long the flaw existed in Exchange Server.
• Whether Exchange Online was ever exploitable before the service-side mitigation went in.