The Flat Exchange Network Is Dead. CVE-2026-96940 Just Signed the Certificate

The word that stopped me was authenticated.

It sits in the middle of the CVE-2026-96940 summary like a reassurance — weak authorization in Exchange Server, an authenticated attacker can elevate privileges over a network. You read it and some part of your brain files it under “not that bad.” Nobody can walk in off the internet and own the box. They need a credential first.

I spent a morning convincing a client that this was precisely why it was worse than they thought, so let me save you the meeting.

What “authenticated” buys an attacker in a real tenant

Every org I’ve touched with on-prem Exchange has credentials that are, functionally, free. The intern’s mailbox. The service account someone created in 2019 for a scanner and documented in a Word file on a share. The contractor who left but whose account is still enabled because disabling it broke a distribution list once. None of these are privileged. All of them can authenticate to Exchange.

That is the entire precondition for CVE-2026-96940. The flaw is a weak authorization check — Exchange trusts a request it should have rejected — so a plain mailbox identity reaches across the network and comes back wearing a role it was never granted. This is not remote code execution from an unauthenticated stranger. It’s a privilege boundary that doesn’t hold, which in practice means the distance between “phished one low-value user” and “owns the Exchange organization” collapses to a single hop.

If your Exchange servers sit on the same flat network as workstations — and most do, because that’s how Exchange was always deployed — the attacker’s foothold and the target are already in the same room. The vulnerability doesn’t need to open a door. The door was propped open by your network topology years ago.

I’m not going to quote a CVSS number or describe an exploit chain, because Microsoft hasn’t published exploitation details and inventing them helps no one. The MSRC update guide entry is the authority on affected builds and the patch. Read it before you touch anything. What I can tell you is how the triage went, and where I lost time you don’t have to.

First thing: find out what you’re actually running

Microsoft Graph is useless here and I want to be blunt about that, because I watched someone reach for it reflexively. Graph talks to Exchange Online. CVE-2026-96940 is an on-premises Exchange Server bug. There is no Graph call that will audit a box sitting in your own datacentre. You go back to the Exchange Management Shell on-prem, and you use Get-ExchangeServer.

The GUI path, if you prefer eyes-on: Exchange admin center → Servers → Servers, then check the version column against the patched builds listed on the CVE page. Fine for one or two servers. For anything bigger, pull it to a file so you have a record of the before-state:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Run from the Exchange Management Shell on-prem.
# Read-only inventory — no changes made here.
try {
    $servers = Get-ExchangeServer -ErrorAction Stop |
        Where-Object { $_.ServerRole -ne 'Edge' } |
        Select-Object Name, Edition, AdminDisplayVersion, ServerRole, Site
​
    if (-not $servers) {
        Write-Warning 'No mailbox/CAS Exchange servers returned. Check your scope.'
    }
​
    $stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
    $servers | Sort-Object Name |
        Export-Csv -Path ".\exchange-inventory-$stamp.csv" -NoTypeInformation -Encoding UTF8
​
    $servers | Format-Table -AutoSize
}
catch {
    Write-Error "Failed to enumerate Exchange servers: $($_.Exception.Message)"
}

AdminDisplayVersion is the field that matters. It gives you the build number — the CU and SU level — which is the only thing you can honestly compare against Microsoft’s patched-build list. Don’t trust the friendly “Cumulative Update N” label a human typed somewhere. Trust the build string.

Where I lost twenty minutes: I compared against the CU list and declared one server clean because it was on the current CU. It wasn’t clean. The security update — the SU — layers on top of the CU, and this box had the CU and not the SU. Being on the latest CU is necessary and not sufficient. You install the CU your version requires, then the SU for the vulnerability. Miss the second step and you’ve patched nothing while feeling like you patched everything. That’s the worst state to be in.

The hour you can’t patch in, buy with the network

Patching Exchange in production is never “just run the installer.” There’s a maintenance window, a reboot, services that don’t always come back the way you’d like. If you genuinely cannot patch tonight, the stopgap is to make the “network” in “over a network” shrink.

Segmentation first. Exchange client endpoints should not be reachable from workstation VLANs, guest Wi-Fi, or anything an everyday user’s machine lives on. Put the servers behind firewall rules that only permit the client access paths you actually need, from the ranges that actually need them. This is boring, it is 2010-era advice, and it is the single control that would have blunted half the Exchange incidents I’ve worked. The flat network was always the risk; this CVE just makes the bill due.

While you’re in there, review your authentication policies. Not as a fix — it isn’t one — but to shorten the list of identities that can reach Exchange at all. Fewer accounts that can authenticate means fewer footholds that satisfy the precondition.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Run from the Exchange Management Shell on-prem.
# Review authentication policy assignments BEFORE changing anything.
# State-changing step defaults to -WhatIf. Act only on a reviewed CSV.
try {
    Get-AuthenticationPolicy -ErrorAction Stop |
        Select-Object Name, BlockLegacyAuth* |
        Format-Table -AutoSize
}
catch {
    Write-Error "Could not read authentication policies: $($_.Exception.Message)"
}
​
# Example: assign a reviewed restrictive policy to a vetted list of accounts.
# $reviewed = Import-Csv .\accounts-to-restrict.csv   # column: UserPrincipalName
# foreach ($u in $reviewed) {
#     Set-User -Identity $u.UserPrincipalName `
#              -AuthenticationPolicy 'Block-Legacy-And-Basic' `
#              -WhatIf    # drop -WhatIf only after you've read the output
# }

Note what that second block does and doesn’t do. It never pipes a live Get-User straight into Set-User. You review a list, you confirm it, you run it with -WhatIf, you read every line of what it claims it would do, and only then do you remove the safety. Bulk-modifying authentication straight off a query is how you lock out the CEO at 11pm and turn a security fix into an outage. Done that once. Never again.

What I’d tell you if you were about to start

Patch, don’t mitigate, if you have any window at all — segmentation reduces the blast radius but the authorization check is still broken underneath it. Verify the build number, not the CU label, against the MSRC page. Install the CU and the SU, and confirm both landed. And treat every enabled account that can authenticate to Exchange as a potential starting point, because that’s exactly how this one reads from the attacker’s side.

The quiet assumption behind “authenticated attacker” — that getting a credential is the hard part — stopped being true years ago. CVE-2026-96940 just makes you pay for believing it.