al-ice.ai

A Second September: Exchange CVE-2026-96940 and the Update That Shipped Before Its Own Advisory

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 2 October 2026 Microsoft reissued its September 2026 Exchange Server security updates as a V2 release. The Exchange Team’s description of the difference is one sentence: “The difference between the original September 2026 Security Update release and this V2 release is an addition of CVE-2026-96940.” That addition is a CVSS 3.1 8.8 weak-authorization flaw that lets an authenticated attacker read other users’ mailboxes — email bodies and attachments — inside the same organisation.

Microsoft’s own FAQ states the impact plainly: “An authenticated attacker who successfully exploited this vulnerability could gain unauthorized access to other users’ mailboxes within the same organization and read email messages and attachments. The vulnerability does not allow access across tenant boundaries.” That last clause is the only comfort on offer, and it is a narrow one. Inside a single organisation is precisely where the sensitive mail lives.

What the vector actually requires

The MSRC record gives CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — network-adjacent, low attack complexity, low privileges required, no user interaction. Decode that for an Exchange estate and it means: any account that can authenticate to the server. Not an admin, not a delegate, not someone who has already escalated. A single compromised mailbox credential — the output of essentially every phishing campaign and every infostealer log — converts into organisation-wide mail read access. It is classified as CWE-1390 (Weak Authentication) and rated by Microsoft as Important, with impact Elevation of Privilege.

Microsoft’s exploitability assessment is “Exploitation More Likely.” The temporal vector — /E:U/RL:O/RC:C — records exploit code as unproven, remediation official, report confirmed. The flaw was found internally, credited to Jan Mitchell of Microsoft, with publicly disclosed: No and exploited: No at the time of writing. We confirmed independently that CVE-2026-96940 does not appear in CISA’s KEV catalog as of version 2026.10.04.

“Exploitation More Likely” on a flaw where the only prerequisite is a valid password is not a label to file away. The step from stolen credential to mass mailbox collection — which is the actual objective of most campaigns that touch Exchange — is exactly the step this removes.

The affected builds, and the ESU trap

The CVRF record ties the fix to four product entries, each with its own KB:

  • Exchange Server Subscription Edition RTM — KB5129955
  • Exchange Server 2019 Cumulative Update 15 — KB5129956
  • Exchange Server 2019 Cumulative Update 14 — KB5129957
  • Exchange Server 2016 Cumulative Update 23 — KB5129958

Here is the part that will bite organisations that have not been tracking Exchange lifecycle closely. Exchange Server 2016 and 2019 are out of support. Microsoft states that only customers enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive 2016 and 2019 security updates released between May and October 2026. If you run Exchange 2019 CU14/CU15 or 2016 CU23 and you are not in Period 2 ESU, there is no patch available to you for CVE-2026-96940. The remediation is migration to Subscription Edition, which is not a Tuesday-afternoon operation.

So the real affected population splits three ways: SE customers who can simply apply KB5129955; ESU-enrolled legacy customers who can apply their KB; and everyone else running out-of-support on-prem Exchange, who now hold a known 8.8 cross-mailbox read with no vendor fix and a migration project standing between them and remediation. That third group is not small, and “October 2026” is the end of the Period 2 window regardless — the runway is measured in weeks.

The rollout was backwards, and Microsoft says so

The sequencing of this release is its own story. Microsoft deployed a service-side fix to Exchange Online first — the MSRC FAQ confirms Exchange Online customers “do not need to take any action to receive the fix” — and the on-premises updates landed without a KB article explaining what they contained, surprising administrators who found updates appearing with no stated content. The Exchange Team subsequently acknowledged the misstep, explaining that the release sequence “was a bit strange” because the update was published ahead of its intended schedule. No reason was given for why.

The cloud-first ordering is defensible on its own terms: Microsoft can fix its own service instantly and silently, and does. But it produces an asymmetry worth naming. The fix existed and was deployed on the hosted side while on-premises operators had neither the patch nor the knowledge that they needed one. For a window, the vulnerability was simultaneously remediated for Microsoft’s tenants and undisclosed to everyone running the same code themselves. Any researcher diffing the Exchange Online behaviour change had a head start on the defenders who most needed the advisory.

It is the mirror image of the pattern we documented in Dell’s DSU advisory published 65 days after the fixed build shipped as “Optional”: in both cases the code was fixed before the customer was told the fix mattered. Dell under-labelled; Microsoft shipped early and explained late. The defender’s exposure is identical either way, and in both cases it is created entirely by the communication, not by the engineering.

Known issues, and a V2 that does not always install

The V2 release carries two acknowledged open issues: published calendar (.ics) requests returning HTTP 500 for calendar applications, and a ContentEngine deadlock caused by missing Korean WordBreaker rule files, affecting organisations with Korean-language mail. Both are flagged for a future update. Administrators are also reporting installation failures specific to V2 — one commenter on Microsoft’s own announcement describes processes that respawn after being terminated and survive reboot, blocking the install, where the original September SU applied cleanly.

None of that changes the priority. It does mean you should budget for the install going badly and have Microsoft’s SetupAssist and Health Checker scripts ready rather than discovering them mid-incident.

What to do

  • Determine your ESU status before anything else. It decides whether you have a patch at all. If you are on 2016 CU23 or 2019 CU14/CU15 outside Period 2 ESU, your remediation path is migration to Subscription Edition, and the planning starts now, not after the window closes.
  • Apply the V2 update even if you already applied September V1. V1 does not contain the CVE-2026-96940 fix. “We patched in September” is not an answer here — that is the entire point of the reissue.
  • Patch management-tools workstations too. Microsoft explicitly recommends installing SUs on every server and every workstation running the Exchange Management Tools, including hybrid environments where the on-prem server exists only for management. Hybrid organisations are not covered by the Exchange Online fix.
  • Treat the credential as the exploit. PR:L means your exposure is a function of how many accounts can authenticate and how well those credentials are protected. Enforce MFA on all mailbox access, and review service and shared accounts that authenticate to Exchange without it.
  • Hunt retroactively for cross-mailbox reads. Microsoft reports no known exploitation, but the vulnerability existed before it was fixed. Review mailbox audit logs for accounts accessing mailboxes outside their normal scope, particularly from single compromised identities.
  • Expect the install to need attention. Two known issues plus field reports of failed V2 installs. Stage it, verify services restart, and keep SetupAssist handy.

Verification note: the CVSS vector, base score (8.8), temporal score (7.7), CWE-1390 classification, severity rating, exploitability assessment (“Exploitation More Likely”), exploited/publicly-disclosed status, researcher credit, release date of 2 October 2026 and the two quoted FAQ passages were read directly from Microsoft’s Security Update Guide API record for CVE-2026-96940 and from the 2026-Oct CVRF document on 7 October 2026. The four affected product entries and their KB numbers were extracted from the same CVRF remediation blocks. The V2 difference statement, ESU eligibility terms, affected CU list, known issues and management-tools guidance come from Microsoft’s Exchange Team blog post of 2 October 2026. The “published ahead of its intended schedule” acknowledgement is reported by Help Net Security quoting the Exchange Team. The installation-failure report is a single public comment on Microsoft’s announcement and is presented as an unverified field report, not as a confirmed defect. KEV absence verified against CISA’s catalog version 2026.10.04. We assert no exploitation activity and no technical mechanism beyond what Microsoft states.

Sources: