On 2 October Microsoft released an out-of-band security update for on-premises Exchange Server. It fixes CVE-2026-96940, a weak-authorisation flaw that lets an authenticated user read other people's mailboxes in the same organisation. Microsoft rates it Important rather than Critical. We think that understates it. On-premises Exchange is one of the most heavily researched targets in the Microsoft estate, and this bug turns any compromised mailbox into access to everyone else's.
What follows covers what Microsoft has disclosed, who has to act, the order to do it in, and how to hunt for the bug being used against you in Microsoft Sentinel and Defender, including before it was patched.
What Microsoft has disclosed
The advisory is short, and most of it fits in a list:
- Type: elevation of privilege through weak authorisation (CWE-1390). Microsoft's description: "Weak authorization in Microsoft Exchange Server allows an authenticated attacker to elevate privileges over a network."
- Impact: an attacker who exploits it "could gain unauthorized access to other users' mailboxes within the same organization and read email messages and attachments." It does not cross tenant boundaries.
- Severity: CVSS 3.1 base score 8.8. Network attack vector, low complexity, low privileges required, no user interaction.
- Exploitability: not publicly disclosed and not exploited at release, but assessed as "Exploitation More Likely".
- Exchange Online: already fixed on the service side. No customer action needed.
- Delivery: shipped as the September 2026 V2 Exchange Server Security Updates. If you installed the original September update, you still need V2.
The low-privilege, no-interaction profile is what matters. The attacker doesn't need to be an Exchange administrator. They need a mailbox: one phished user, one sprayed password, one contractor account nobody turned off.
Why an "Important" deserves emergency handling
Three things move this up the queue.
Getting authenticated is the easy part
The precondition is a valid account, and valid accounts are the most common way in. Microsoft's own Digital Defense Report this year puts valid accounts among the leading initial access techniques. In most intrusions we see, a working credential for an ordinary user is not the hard part.
It turns one mailbox into all of them
Ordinarily a compromised junior mailbox is a contained incident: reset the password, review the inbox rules, check what was sent. With this flaw the same foothold can reach the finance director's correspondence, the legal team's attachments and the board pack. That changes both the business impact and what a responder has to assume when scoping a breach.
Exchange patches get reverse-engineered
"Exploitation More Likely" is Microsoft telling you it expects a working exploit to be feasible. On-premises Exchange has a long history of researchers and attackers diffing patches to find the fixed code path. The gap between a fix and a public proof of concept has often been measured in weeks. Assume the clock started on 2 October.
Who is affected
The fixed builds, from Microsoft's update guide:
- Exchange Server Subscription Edition RTM: KB5129955, build 15.2.2562.53
- Exchange Server 2019 CU15: KB5129956, build 15.2.1748.53
- Exchange Server 2019 CU14: KB5129957, build 15.2.1544.48
- Exchange Server 2016 CU23: KB5129958, build 15.1.2507.75
Two groups are easy to miss.
Exchange 2016 and 2019 outside the ESU programme. Both versions left support on 14 October 2025. Microsoft describes the 2016 and 2019 packages as Extended Security Update releases, and that period is due to end this month. If you are running either version and are not enrolled, this flaw may stay open on your servers. Treat that as a migration deadline, not a patching task.
The "last Exchange server" in hybrid estates. Many organisations that moved mailboxes to Exchange Online kept an on-premises server for recipient management. It still runs Exchange, it is often forgotten, and Microsoft's guidance is to update all Exchange servers and all servers and workstations running the Exchange Management Tools.
What to do this week
- Inventory every Exchange install, including management-only servers and admin workstations with the Management Tools. The exposure query below helps if your servers are onboarded to Defender for Endpoint.
- Install the September 2026 V2 update for your version and CU. If you are on an older CU, you need to move to a supported CU before the security update will apply.
- Verify with the Exchange Server Health Checker script. It reports the installed security update level and catches the half-installed state that a failed or interrupted update can leave behind. Microsoft lists one known issue: published .ics calendars may return HTTP 500 to calendar applications.
- Turn on mailbox auditing where it is off. On-premises, it is not enabled for every mailbox by default. Without it, the hunt in the next section has nothing to search.
- Close the precursor. The flaw needs a valid account. Review password-spray and anomalous sign-in alerts against OWA, EWS and ActiveSync for the last 30 days, and confirm that legacy authentication is off wherever you can turn it off.
Detection and hunting
Microsoft has not published technical detail of the flaw, so there is no exploit signature to hunt for, and we don't know exactly how exploitation shows up in audit logs. Hunt for the outcome instead: one account reading mailboxes it has no business reading, or touching far more mail than it normally does. The queries below are starting points. Tune the thresholds and exclusions to your estate before you rely on them.
1. Find unpatched servers (Defender Vulnerability Management)
DeviceTvmSoftwareVulnerabilities
| where CveId == "CVE-2026-96940"
| project DeviceName, OSPlatform, SoftwareName, SoftwareVersion,
VulnerabilitySeverityLevel, RecommendedSecurityUpdate
| order by DeviceName ascThis only sees servers onboarded to Defender for Endpoint. Anything absent from the results either isn't vulnerable or isn't being watched, and you need to know which.
2. Non-owner mailbox access (on-premises audit log)
Run from the Exchange Management Shell. It lists access by anyone other than the mailbox owner over the last 30 days:
Get-Mailbox -ResultSize Unlimited |
Search-MailboxAuditLog -LogonTypes Admin,Delegate -ShowDetails `
-StartDate (Get-Date).AddDays(-30) |
Select-Object MailboxOwnerUPN, LogonUserDisplayName, LogonType,
Operation, ClientIPAddress, LastAccessedLook for a single logon user appearing against many different mailboxes, and especially against executive, finance and legal mailboxes. Separate known delegates (assistants, shared mailbox members, migration and backup service accounts) out first, or they will bury the signal.
3. Abnormal client-access volume per user (Microsoft Sentinel)
If you ship Exchange IIS logs to Sentinel, a user whose EWS, MAPI or OWA request volume jumps far above their own baseline is worth a look. Bulk mailbox reading is noisy at the protocol layer, even when it is quiet everywhere else.
let lookback = 14d;
let recent = 1d;
W3CIISLog
| where TimeGenerated > ago(lookback)
| where csUriStem has_any ("/EWS/", "/mapi/", "/owa/")
| where isnotempty(csUserName) and csUserName != "-"
| summarize Recent = countif(TimeGenerated > ago(recent)),
Baseline = countif(TimeGenerated <= ago(recent)) / 13.0,
ClientIPs = make_set(cIP, 10)
by csUserName
| where Recent > 500 and Recent > 5 * Baseline
| order by Recent descExpect service accounts and mobile-sync bursts in the first run. Add them to a watchlist and exclude it, rather than raising the threshold until real activity disappears too.
4. Tie it to how the account was obtained
Any account that turns up in hunts 2 or 3 should be checked for a precursor: a risky Entra ID sign-in, a password-spray hit, a new device, a sign-in from an unfamiliar country. A user who signed in from somewhere new and then read twelve other mailboxes is a different case from a user who read twelve mailboxes on a Tuesday because they are the CFO's assistant.
The bigger picture
CVE-2026-96940 is a good bug to fix and a better prompt to ask why on-premises Exchange is still in your estate. For most organisations that have already moved mail to Exchange Online, what remains on-premises is a management server holding hybrid configuration. It gets patched last, monitored least and shows up in exactly this kind of advisory. Where a server still has to exist, it needs the same patch cadence, auditing and detection coverage as a domain controller, because in practice it carries a similar level of trust.
How a managed SOC helps
Patching is the fix. Detection covers the window before the patch is installed and the possibility that someone got there first. That is where a managed SOC earns its keep:
- Continuous coverage. Our SOCs are manned 24/7, so a mailbox-access anomaly at 02:00 on a Sunday is looked at on Sunday, not on Monday.
- Investigation in minutes, not a queue. CYBERSHIELD AI's Investigation Agent works each alert through to a verdict, averaging 3m 30s, or 7m 50s where the incident needs Advanced Investigation. It links the mailbox access to the sign-in that preceded it, which is the question that decides whether this is a breach.
- A human signs it off. On the managed service, senior analyst sign-off is the default before a verdict reaches you, and whether to close or escalate is decided by policy and your own decision templates, not by the model.
- Built on Microsoft. We have run Microsoft Sentinel since 2019. The hunts above are the kind of thing we turn into tuned, maintained analytics for your environment, not one-off queries.
If you are unsure whether your Exchange estate is fully patched, or whether anyone used this flaw before you patched it, talk to our team.