Most of the small businesses that still run their own Exchange Server, rather than Microsoft 365 or Google Workspace, do it for a specific reason: compliance requirements, an on-premises data residency rule, or simply a mail system nobody wants to touch because it’s worked for a decade. That decision just got a little more complicated, because of how Microsoft handled the fix for its latest Exchange flaw rather than the flaw itself.
Table of Contents
What CVE-2026-96940 Does
The vulnerability carries an 8.8 CVSS score and comes down to weak authorization. An attacker who already has a valid, authenticated account on your Exchange server, any valid account, not an administrator one, can elevate their own privileges over the network and read other users’ mailboxes within the same organization. That means emails and attachments belonging to colleagues become visible to someone who was only ever supposed to see their own inbox. The flaw doesn’t let anyone cross organizational boundaries into a different company’s tenant, so this isn’t a multi-tenant cloud failure. It’s an internal-boundary failure, inside a single organization’s own mail server.
No user interaction is required to exploit it, which is the detail that usually turns a “someday” patch into an “this week” one. Microsoft discovered the issue through its own internal research rather than from an external report, and as of the disclosure there’s no evidence of active exploitation. Microsoft still rated it “Exploitation More Likely,” its own forward-looking assessment that this category of bug tends to get weaponized once enough detail circulates.
The Part That Trips People Up: Which Patch You Have
Here’s where this gets genuinely confusing, and why it’s worth a second look even if you already patched Exchange in September. Microsoft originally shipped its September 2026 security updates, then reissued them as “V2” releases specifically to add protection against CVE-2026-96940, which wasn’t fully covered in the original September package. If your team installed the first September update and considers Exchange patched for the month, you may not have this specific fix. The safe assumption is: don’t trust the calendar month, check the actual build number and compare it against Microsoft’s current guidance for your version.
Affected versions span a wide range: Exchange Server Subscription Edition RTM, Exchange Server 2019 Cumulative Update 14 and 15, and Exchange Server 2016 Cumulative Update 23. If you’re running any on-premises Exchange install at all, assume you’re in scope until you’ve confirmed otherwise.
If you’re on Exchange Online, you’re already covered
Microsoft pushed a server-side fix to Exchange Online on October 2, 2026, and cloud customers don’t need to do anything. This is purely an on-premises problem. If your business already migrated to Microsoft 365 and kept Exchange Online as the mail backend, this entire story is background reading, not a to-do item. That’s worth confirming for certain if you’re not sure which setup your organization has; “we use Exchange” and “we use Exchange Online” are two very different exposure situations right now.
Why this is relevant even if your business isn’t big enough to employ an Exchange admin
Most AllCloudHost customers aren’t running Exchange, because most small businesses outsourced email to a cloud provider years ago for exactly this reason: patch management for a mail server is a genuinely demanding, ongoing responsibility, and getting it wrong doesn’t just mean downtime, it can mean a colleague reading mail they were never supposed to see. If your business is one of the exceptions still running on-premises Exchange, whether for compliance, legacy integration, or inertia, this is a direct reminder of what that choice costs in attention.
If you’re weighing whether to keep maintaining a self-hosted mail server versus moving to a managed service, this kind of incident is a reasonable data point to weigh it against. A managed email platform absorbs this exact patch-tracking burden on your behalf; a self-hosted one puts it entirely on whoever’s currently in charge of your IT, and that person has to notice when a “V2” reissue quietly changes what counts as patched.
What to do this week if you’re running on-premises Exchange
- Confirm your exact build number against Microsoft’s current security update guide for CVE-2026-96940, don’t assume September’s update covered it.
- If you installed the original September release before the V2 reissue, install the V2 package specifically. It is not automatically superseded by having patched once already.
- Check Exchange admin logs for unusual cross-mailbox access patterns in the weeks before you patch, in case anything happened before the fix landed.
- If your organization has any user accounts that don’t strictly need standard mailbox access, for shared service accounts, integrations, or former employees, review whether they’re still active. A privilege-escalation bug like this one is more dangerous the more accounts exist that didn’t need their current level of access in the first place.
- Document which Exchange version and cumulative update you’re running somewhere your team can find quickly next time. Patch confusion compounds when nobody has a clear record of what was supposed to have been applied.
The pattern worth remembering
A patch existing isn’t the same as a patch landing correctly, and a “fixed in September” label can be wrong if the fix that matters shipped in a quiet reissue two weeks later. That’s not a reason to distrust Microsoft’s patching process specifically, it’s a reason to verify rather than assume, for any critical system where “I think we patched that” is doing a lot of load-bearing work.
Why a privilege-escalation bug matters even before anyone’s seen it exploited
It’s easy to read “no evidence of active exploitation” and mentally file this one as lower priority. That read misses what this specific class of bug is dangerous for.
Exchange has a long history of being a high-value target precisely because it sits at the center of an organization’s internal trust: once someone has a foothold, even a low-privilege one, from a phished employee account, a leaked password, or a compromised contractor login, a privilege-escalation flaw like this is exactly the tool that turns “we got into one mailbox” into “we can read everyone’s mail.” The absence of in-the-wild exploitation today says nothing about next month, and Exchange’s own track record with this exact pattern, a boring-sounding authorization bug that later becomes the pivot point in a real breach, is long enough that “Exploitation More Likely” from Microsoft is a label worth taking at face value.
How to Check Your Build Number
If you manage Exchange directly, the fastest way to confirm your real patch level is the Exchange Management Shell command Get-ExchangeServer | Format-List Name,AdminDisplayVersion, or more simply, checking Get-Command ExSetup | ForEach {$_.FileVersionInfo} from an elevated shell on the server itself, then comparing the version number against Microsoft’s current Exchange Server servicing guidance page for your release.
Don’t rely on memory of what got installed, and don’t rely on a generic patch-management dashboard that just shows “Windows Update: up to date,” since Exchange’s own cumulative updates and security patches are tracked separately from general OS patching. If a build number doesn’t match what’s currently listed as the V2-patched release for your version, you’re not protected yet regardless of what got installed in September.
The total cost of “we’ll just keep running our own Exchange server”
None of this is an argument that self-hosting Exchange is inherently wrong. Some businesses have real compliance or data-residency reasons to keep mail infrastructure on-premises. But it’s worth pricing this kind of event into the actual cost of that decision, not just the server hardware and the Windows Server license.
Someone on your team needs to track Microsoft’s security advisories specifically for Exchange, understand the difference between an original release and a reissue, verify build numbers rather than trusting update logs, and do all of this promptly enough that a privilege-escalation window doesn’t stay open for weeks. That’s a recurring, specialized cost that a managed email platform absorbs on your behalf as part of the subscription price.
If the person currently responsible for your Exchange patching also has four other jobs, this is worth a frank conversation about whether on-premises email is still the right tradeoff for your business specifically, rather than the setup that was right when it was first chosen.
Key Takeaways on CVE-2026-96940
- CVE-2026-96940 lets an authenticated Exchange user read other mailboxes.
- Microsoft reissued the CVE-2026-96940 patch as a V2 update, so check which build you have.
- Only some servers need to reinstall the CVE-2026-96940 fix, which is why checking first matters.
Related reading: CVE-2026-19478: What to Do If You’re Running GitLab on Your Own VPS and GitLab’s Critical AI Gateway Flaw: What Self-Hosted Admins Must Know.
Further reading: Microsoft Security Update Guide.