21,899 exposed Exchange servers and a certified pre-auth route to SYSTEM
Opening
A chain demonstrated during a Pwn2Own contest and later published with proof-of-concept code turned an authentication bypass in Exchange's MRSProxy endpoint into SYSTEM-level remote code execution. CVE-2026-62911 affects Exchange Server 2016, 2019 and SE on the 8.0 and 8.1 release lines. Shadowserver counted roughly 21,899 internet-facing Exchange servers still unpatched in September 2026, with the largest concentrations in the United States and Germany.
Technical context
MRSProxy is the component that supports cross-forest mailbox moves. Its endpoint performs a privileged operation on behalf of a remote caller, and the flaw is an authentication bypass that allows a request to be treated as though it were correctly authenticated. From there the chain reaches SYSTEM through a sequence of steps that was originally assembled as a contest entry by researchers from DEVCORE.
The combination is what raises the severity. An authentication bypass alone would permit data access. An authentication bypass that reaches code execution as SYSTEM on a mail server that trusts identity infrastructure is a domain-level problem, because Exchange servers are commonly granted directory permissions that support mailbox operations and those permissions are extensive.
The Dutch national cyber security centre described the flaw as easy to weaponise and low in complexity, which is a notable statement about an Exchange vulnerability from an organisation that does not use that language casually. Public exploit code exists, and a full Python proof of concept accompanied the disclosure.
The patching problem
Exchange 2016 is past end of life. Update paths for it exist only for customers with extended security updates, which means a meaningful fraction of the exposed population has no straightforward fix. The 2019 and SE lines received fixes in the August 2026 update, referenced as KB5121573 through KB5121576, but the population of unpatched servers remained large weeks later.
This is the recurring shape of mail server vulnerability management. The service is business critical, change windows are constrained, extended topologies with multiple roles are common, and the same servers keep appearing in exposure statistics release after release. High exposure combined with a published exploit and a low-complexity attack path produces urgent risk regardless of the severity score.
Defensive implications
Patch wherever a supported path exists and verify the build. For deployments that cannot be patched on the supported schedule, the priority shifts to containment: remove direct internet reachability for the MRSProxy endpoint, which is rarely required from arbitrary source addresses, and place access behind a certificate-aware proxy or VPN with authentication.
Add detection around the endpoint. Authentication successes that lack a corresponding directory logon, MRSProxy requests from source addresses with no prior mailbox activity, and process creation under the Exchange service account are all worth alerting on. Exchange's own logs plus Windows security events give enough signal to build this without additional tooling.
Assume credentials on exposed servers are compromised. Exchange holds service account secrets and access to mailbox data; a SYSTEM-level compromise means every secret on the host is disclosed, along with anything the server can read from the directory. Rotate service accounts, review for forwarding rules and mailbox delegates that were added during the exposure window, and check for new or modified transport rules.
Maintain a deliberate plan for end-of-life mail platforms. The 2016 case shows that the boundary between supported and unsupported is where exposure accumulates, and migrating that workload is a project that needs to start long before the patch stops arriving.
Top comments (0)