Exchange CVE-2026-62911 PoC live; 21,899 servers exposed

A public proof-of-concept for Microsoft Exchange flaw CVE-2026-62911 is now on GitHub, and Shadowserver counts 21,899 internet-facing Exchange servers still unpatched and exposed.

Hold both framings at once, because they do not describe the same attacker. Microsoft and CVE.org classify this as an Elevation of Privilege bug, an authentication bypass by capture-replay in which an authorized attacker elevates privileges over the network, with a base score of 8.0 and a vector that requires low privileges and user interaction (PR:L, UI:R).

The PoC author and several wires frame it instead as needing no prior Exchange credentials, marketed as pre-auth remote code execution reached by relaying a machine account. Both framings matter, because flattening CVE-2026-62911 into a single pre-auth RCE bug loses the distinction that decides who can actually reach it.

What Microsoft actually classified

The MSRC advisory names the instrument precisely: Microsoft Exchange Server Elevation of Privilege Vulnerability, weakness type CWE-294 Authentication Bypass by Capture-replay, threat type Elevation of Privilege, severity Critical, CVSS 3.1 base 8.0 with vector AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H. CVE.org carries the same one-line reading: an authorized attacker can elevate privileges over a network, record updated 2026-08-31.

This is not a standalone pre-auth RCE CVE in Microsoft's telling. Per the MSRC FAQ, a successful exploit lets an attacker take over all Exchange user mailboxes, meaning send, read, and download attachments.

The advisory also marked the flaw as not publicly disclosed and not exploited, with exploitation assessed less likely, at the time it shipped; the working PoC that landed on GitHub is what moved today.

The PoC, and why SYSTEM is a chain and not a single bug

The proof-of-concept, published by Nguyen Van Hiep, titles itself as pre-auth RCE that needs no credentials. That is the PoC author's framing, not Microsoft's.

The full path to SYSTEM in the public write-ups is a chain, not this one CVE: coerce the Exchange machine account into NTLM authentication with a PetitPotam-style trigger, relay that to the HTTP.sys MRSProxy endpoint, which unlike the IIS /EWS/MRSProxy.svc path does not enforce Extended Protection for Authentication channel binding, then abuse a WCF mailbox configuration call to write to an arbitrary path and drop an ASPX webshell running as SYSTEM. The bug credited here is the capture-replay auth bypass that makes the relay stick.

Microsoft credits Orange Tsai of DEVCORE with Trend Zero Day Initiative, tracked ZDI-26-538 and ZDI-CAN-31480, from the three-bug Exchange chain demonstrated at Pwn2Own Berlin 2026. The relay-to-SYSTEM idea should read as familiar to anyone who tracked earlier NTLM relay and coercion work against network gear.

Patch to the MSRC build, not the PoC README

Confirm your build against Microsoft's Remediations table, because the PoC README lists some builds one patch lower (for example 15.2.1544.43, 15.2.1748.48, 15.2.2562.45) and those are the wrong target. The fixed builds are Exchange 2016 CU23 at 15.01.2507.072 (KB5121576), Exchange 2019 CU14 at 15.02.1544.044 (KB5121575), Exchange 2019 CU15 at 15.02.1748.049 (KB5121574), and Exchange Server SE RTM at 15.02.2562.046 (KB5121573). Where MSRC and a PoC disagree on the patched build, MSRC wins.

Exposure, and what CISA has and has not done

The exposure number is the operator fact that should move a maintenance window: BleepingComputer, reporting Sergiu Gatlan on 2026-09-01 and citing Shadowserver, puts 21,899 IPs with an Exchange fingerprint still unpatched, the largest concentrations in the United States at roughly 6,200 and Germany at roughly 5,100.

CVE-2026-62911 is not on the CISA Known Exploited Vulnerabilities catalog as of this writing, and there is no evidence of in-the-wild exploitation; do not confuse it with the separate Exchange bug CVE-2026-42897, which was added to KEV. That is a different posture from CVEs that arrived already under active exploitation or straight onto the KEV catalog, and it is the window defenders still have.

The takeaway

If you run Exchange, pull your current build number now and confirm it is at or above the August 2026 security update for your channel, using the KB that matches your CU rather than a number copied from a PoC. Then check whether the HTTP.sys MRSProxy endpoint is reachable and whether Extended Protection is enforced across every Exchange authentication path, because that is the leg of the chain the relay depends on, and it is the one you control before this CVE ever reaches a KEV listing.