21,899 exposed Exchange servers still unpatched against pre-auth RCE chain to SYSTEM

What happened

Roughly 21,899 Exchange servers reachable from the open internet had not been patched against a flaw that allows an unauthenticated attacker to execute code with SYSTEM privileges, according to a dev.to write-up citing Shadowserver scans from September 2026. The vulnerability, tracked as CVE-2026-62911, affects Exchange Server 2016, 2019 and Exchange SE on the 8.0 and 8.1 release lines. The United States and Germany host the largest concentrations of exposed systems.

The exploit chain was originally assembled as a Pwn2Own contest entry by researchers at DEVCORE, the post notes, and a full Python proof of concept has since been published alongside the disclosure.

How the chain works

The starting point is MRSProxy, the Exchange component that supports mailbox moves between Active Directory forests. Per the dev.to analysis, the bug is an authentication bypass: a request that ought to be rejected is instead handled as if it carried valid credentials. Because the endpoint performs privileged operations on behalf of remote callers, the bypass can be extended into code execution running as SYSTEM on the mail server.

What elevates the bug beyond a data-access issue is the position Exchange occupies. The write-up points out that mail servers are routinely granted extensive directory permissions for mailbox work, so SYSTEM-level control of one effectively becomes a domain-wide security problem. The Dutch national cyber security centre reportedly assessed the flaw as undemanding to exploit and low in attack complexity — pointed language from an organisation the post describes as measured in such judgments.

Why patching has stalled

Exchange 2019 and SE received fixes in the August 2026 updates, referenced as KB5121573 through KB5121576, yet thousands of servers were still unpatched weeks later. Exchange 2016 is past end of life, so patches exist only for customers with extended security update agreements — leaving part of the exposed population with no straightforward remediation at all.

The dev.to piece frames this as a familiar cycle for mail infrastructure: the service is business-critical, change windows are limited, and multi-role topologies make updates risky, so the same servers reappear in exposure statistics after every release. A public exploit combined with a low-effort attack path makes the situation urgent regardless of the assigned severity score.

What defenders can do

The write-up lays out a response plan:

• Patch every supported server and verify that the installed build actually contains the fix.
• Where patching lags, contain the endpoint: MRSProxy rarely needs to be reachable from arbitrary internet addresses, so move it behind a VPN or an authenticating, certificate-aware reverse proxy.
• Add detection using logs already on hand — authentication successes with no matching directory logon, MRSProxy requests from sources with no prior mailbox activity, and process creation under the Exchange service account.
• Assume every credential on an exposed server is compromised. SYSTEM-level access discloses all secrets on the host plus whatever the server can read from the directory, so rotate service accounts and review forwarding rules, mailbox delegates and transport rules added during the exposure window.
• Treat migration off end-of-life mail platforms as a long-lead project that starts well before patches stop arriving.

Why it matters

Pre-auth remote code execution as SYSTEM on a domain-connected mail server is close to a worst-case enterprise scenario: no credentials required, full host control, and a natural pivot into identity infrastructure. With exploit code public, tens of thousands of internet-facing hosts still vulnerable, and a subset stranded on an unsupported release, CVE-2026-62911 is an immediate patching priority — and a reminder that exposure clusters wherever critical services age out of vendor support.