Vulnerabilities
Exchange CVE-2026-96940: install the V2 update again
An Exchange Server flaw lets any signed-in user read other mailboxes. Microsoft fixed it in re-released September updates. Builds, checks and audit logs.
On October 2, Microsoft re-released its September 2026 security updates for on-premises Exchange Server as "V2" packages. The only change is a fix for CVE-2026-96940, a weak authorization flaw rated CVSS 8.8. An attacker who holds any valid account in the organization can open other users' mailboxes and read their messages and attachments. Affected builds are Exchange Server Subscription Edition (SE) RTM, Exchange Server 2019 CU14 and CU15, and Exchange Server 2016 CU23.
The trap is that servers patched in September still look current. The September 8 security update (SU) does not contain this fix, so every on-premises server needs the V2 package on top. Exchange Online customers are already covered: Microsoft fixed the service on its side and they have nothing to do. Microsoft found the flaw internally and knows of no attacks, but it rates exploitation as more likely, and a phished mailbox password is all an attacker needs to start.
How it works
Exchange normally makes two decisions on every mailbox request. Authentication establishes who the caller is. Authorization then checks whether that caller has rights on the target mailbox: ownership, Full Access, folder permissions or delegation. Microsoft's description of CVE-2026-96940 is "weak authorization": the first check works, the second does not hold for some path, so a signed-in user can reach mailboxes they were never granted.
Microsoft classes it as elevation of privilege because the attacker ends up with rights they should not have. In practice the impact is confidentiality. A standard user can read the CEO's inbox, the finance team's invoices or the legal team's attachments. Microsoft says access stays inside the organization and does not cross tenant boundaries.
Microsoft has not said which protocol or endpoint is affected (Outlook on the web, Exchange Web Services, MAPI over HTTP or something else), and no researcher has published a technical analysis or proof of concept. That limits what defenders can hunt for, and it is why the update is the only reliable control here.
What attackers are doing
Nothing confirmed so far. Microsoft says it is not aware of exploitation and gives the flaw an "Exploitation More Likely" assessment. It is not in CISA's Known Exploited Vulnerabilities (KEV) catalog.
The rollout itself was unusual. Several Exchange administrators in Germany noticed the V2 packages arriving through Windows Update and WSUS on October 2 before any documentation existed. Microsoft published the CVE entry, the support articles and its Exchange Team blog post late that evening. Since then the fixed binaries have been public, and anyone can compare them with the September builds to find the authorization check that changed.
What to do
1. Install the V2 update on every server
The V1 builds from September 8 end in .49 (SE), .51 (2019 CU15), .46 (2019 CU14) and .73 (2016 CU23). Any server on those, or on anything older, is exposed. The V2 packages are cumulative for their CU, so a server on an older SU can go straight to V2. Run the installer from an elevated command prompt, then reboot and confirm all Exchange services started.
Exchange 2016 and 2019 reached end of support in October 2025. Their V2 packages are available only to organizations enrolled in the Period 2 Extended Security Update (ESU) program, which Microsoft's support article says runs through October 2026. Without ESU, there is no fix for those versions, and the path is an in-place upgrade from 2019 CU14 or CU15 to Exchange SE.
None of Microsoft's documents lists a mitigation or configuration workaround. If a server cannot be updated today, the useful interim steps are general ones: reset passwords and enforce multifactor authentication for any account showing signs of phishing, and treat every mailbox on that server as readable by every user until it is patched.
2. Check the build you actually have
Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion lists every server, but Microsoft's build numbers page notes that AdminDisplayVersion reflects the CU, not the installed SU. To see the SU, run this on each server:
Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}
The product version must match the V2 build in the table above, for example 15.02.1748.053 for Exchange 2019 CU15. Microsoft's Exchange HealthChecker script (https://aka.ms/exchangehealthchecker) reports the same build per server and flags any that lag, which is quicker for larger estates.
3. Look for unexpected mailbox access
Mailbox audit logging in Exchange Server is set per mailbox. Check which mailboxes have it with Get-Mailbox -ResultSize Unlimited | Format-Table Name,AuditEnabled. Where it is on, Exchange records FolderBind (a folder was opened) for administrator and delegate logons by default, and keeps entries for 90 days.
For sensitive mailboxes such as executives, finance, HR and legal, run:
Search-MailboxAuditLog -Identity <mailbox> -LogonTypes Admin,Delegate -ShowDetails -StartDate 09/01/2026
Compare LogonUserDisplayName and ClientIPAddress in each entry with the people who hold real permissions, from Get-MailboxPermission <mailbox>. Access by someone who has no Full Access or folder permission is the pattern this bug would produce. Two caveats: delegate FolderBind entries are consolidated to one per folder per 24 hours, and Microsoft has not confirmed that exploitation of this flaw shows up as a delegate logon at all, so a clean result is not proof.
The MailItemsAccessed audit action, which logs individual message reads, exists only in Exchange Online (with E5 or E5 Compliance licensing). It is not available for mailboxes on your own servers, and Search-UnifiedAuditLog searches the Microsoft 365 audit log, so it only helps for mailboxes already in Exchange Online. On-premises Exchange also no longer logs MessageBind, the per-item read action.
4. Afterwards
Turn on auditing for any mailbox that had it off with Set-Mailbox <mailbox> -AuditEnabled $true, and raise AuditLogAgeLimit if 90 days is too short for your investigations. If the audit search shows access you cannot explain, reset that account's password and treat the exposed mailbox contents as disclosed.
The wider lesson
Re-released updates break the usual patch reporting. A compliance dashboard that marks September as "installed" will show these servers as green while they stay exposed. Track Exchange by exact build number, not by month or KB family, and run HealthChecker after every SU so a V2 release cannot slip past.
Our safeguarding and hardening work covers Exchange build hygiene, audit configuration and the move off Exchange 2016 and 2019, and our security operations team can run the audit searches above across your estate. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Microsoft Exchange Team blog, MSRC CVE-2026-96940, Microsoft KB5129956, Exchange Server build numbers, Mailbox audit logging in Exchange Server, Search-MailboxAuditLog, The Hacker News, Born's Tech and Windows World, Grams IT, Windows FAQ, Frankys Web.