A Patch Runbook for CVE-2026-62911 in Microsoft Exchange Server

CVE-2026-62911 is a privilege elevation vulnerability in Microsoft Exchange Server, classified as CWE-294 authentication bypass by capture-replay with a CVSS 3.1 base score of 8.0. Microsoft shipped the fix on 11 August 2026. This is a runbook for getting the fix deployed in order.

Step one: identify the line and the target build

Exchange has four in-scope product lines for this CVE. Each has its own fixed build, so the first task is to establish which line each server runs and what the target build is.
| Product | Affected from | Fixed below |
| --- | --- | --- |
| Exchange Server 2016 Cumulative Update 23 | 15.01.0.0 | 15.01.2507.072 |
| Exchange Server 2019 Cumulative Update 14 | 15.02.0.0 | 15.02.1544.044 |
| Exchange Server 2019 Cumulative Update 15 | 15.02.0.0 | 15.02.1748.049 |
| Exchange Server Subscription Edition RTM | 15.02.0.0 | 15.02.2562.046 |

Step two: sequence the work

Patch internet-facing servers first, because those are the ones an attacker can reach. Within that group, patch the servers that terminate authentication traffic before the ones behind them. In a database availability group, the update sequence and the failover plan have to be agreed before any change window opens.

Step three: decide the interim control

If a server cannot be patched inside the exposure window, the NCSC-NL guidance reported by CSIRT.CZ is to take it off direct internet exposure and keep it internal. A reverse proxy that does not preserve the capturable exchange changes the attack surface, and so does restricting which clients may authenticate externally.

Step four: verify the build after deployment

A successful installer run is not evidence of a patched build. Confirm the build number on each host after the update, then re-scan the external footprint. Verification is the step that most often gets skipped under time pressure.

Step five: check the population numbers

CSIRT.CZ reported roughly 22,000 internet-reachable Exchange servers that remained unpatched, with about 300 vulnerable unique IP addresses tracked in Czechia. A ZoomEye query on app="Microsoft Exchange" returns 569453 matching assets globally. Those figures describe the exposed population rather than the vulnerable count, and the vul.cve="CVE-2026-62911" filter returned 0 because the identifier is not yet indexed.

Step six: keep the record

The runbook produces evidence: the build inventory, the exposure scan before and after, the change tickets and the interim control decisions. That record matters if the vulnerability is exploited later, because it establishes what was known and when. It matters at the next audit as well.

The part that is not technical

Someone has to own the decision to accept risk on a server that cannot be patched. That decision belongs in writing, with a review date and with the exposure control attached to it.

Comments

[Francisco Grandón]

Structuring the remediation order around internet-facing, auth-terminating nodes first—rather than treating every Exchange host as equal priority—makes this a genuinely practical runbook.

Because CVE-2026-62911 maps to CWE-294 (Authentication Bypass by Capture-Replay), one step worth appending right after verifying the target build numbers (15.02.1748.049 / 15.02.2562.046) is invalidating active session cookies/tokens and auditing Exchange HttpProxy logs for replayed authentication payloads predating the maintenance window. Installing the CU closes the replay vector going forward, but any session minted via a replayed handshake before the reboot can still linger until explicitly revoked.

At this point, keeping an on-prem Exchange Server off ZoomEye's radar feels less like routine patch management and more like defusing a bomb that also happens to store the CEO's calendar invites.