CVE-2026-62911 (CVSS 8.1): 22,000 Exchange Servers Exposed as Pwn2Own RCE Chain Goes Public — Every Mailbox at Risk

On 2 September 2026, security researchers confirmed that 21,899 Microsoft Exchange servers reachable from the public internet remain unpatched against a high-severity authentication-bypass flaw that hands an attacker the keys to every mailbox on the system. The vulnerability — CVE-2026-62911 — was first demonstrated at Pwn2Own Berlin 2026 as part of a $200,000, three-bug chain that culminated in SYSTEM-level remote code execution. Three weeks after Microsoft shipped its fix, the majority of on-premises Exchange deployments worldwide have still not applied it, and a public proof-of-concept exploit is now in the wild. For CISOs and IT teams in India, where on-premises Exchange remains a compliance staple across banking, government, and enterprise, the window to act is closing fast.

The Pwn2Own Origin: How Orange Tsai Broke Exchange Again

Orange Tsai of Taiwan-based security firm DEVCORE has a long track record of breaking Microsoft Exchange. In 2021 he unveiled ProxyLogon, perhaps the most catastrophically exploited Exchange flaw in history. At Pwn2Own Berlin 2026, Tsai and his team returned with a fresh three-vulnerability chain targeting Exchange Server. The chain earned the team $200,000 and 20 Master-of-Pwn points — the top prize at the competition — and ended with the contest’s judges watching arbitrary code execute with SYSTEM privileges on a fully patched Exchange instance.

The entry point in that chain is now public knowledge: CVE-2026-62911. Microsoft classified it as an elevation of privilege flaw and quietly fixed it in the August 2026 Patch Tuesday rollup. However, within days of the patch shipping, independent researchers reconstructed the attack primitive and posted a working proof-of-concept to GitHub, confirming that the bypass is straightforward to weaponize even without the full Pwn2Own chain.

Technical Deep-Dive: The MRSProxy NTLM Relay

The root cause sits in the Mailbox Replication Service Proxy (MRSProxy), a WCF (Windows Communication Foundation) endpoint Exchange exposes for cross-forest mailbox moves. MRSProxy accepts Negotiate (NTLM/Kerberos) authentication, but — critically — it does not enforce Extended Protection for Authentication (EPA), also known as channel-binding.

Without EPA, an attacker who can intercept or originate an NTLM authentication handshake can relay it to MRSProxy and be accepted as the relayed account. Because the relay victim is typically a machine account or a privileged service account, the attacker arrives inside the service with Exchange-level permissions. From that position, the public PoC exercises two MRSProxy WCF methods:

• IMailbox_Config6 — accepts an arbitrary file path as a configuration parameter.
• IMailbox_Connect — causes Exchange to write attacker-controlled content to that path.

Even without triggering the write primitive, a successful relay alone is sufficient for full mailbox takeover: the attacker inherits the ability to read every message, send email impersonating any user, download attachments, and alter folder permissions — all without possessing a single valid password. For a threat actor performing business email compromise (BEC), espionage, or ransomware pre-positioning, this is a decisive foothold.

The broader Pwn2Own chain layers two additional CVEs on top of the relay to pivot from mailbox access to SYSTEM-level code execution, but the NTLM-relay step alone represents an independent, catastrophic threat to any organisation running on-premises Exchange.

Affected Versions and Patches at a Glance

Exchange Version	Vulnerable Build	Patched Build (SU9)	Notes
Exchange Server 2016 CU23	< 15.1.2507.72	15.1.2507.72	ESU Period 2 required
Exchange Server 2019 CU14	< 15.2.1544.44	15.2.1544.44	—
Exchange Server 2019 CU15	< 15.2.1748.49	15.2.1748.49	—
Exchange Server SE RTM	< 15.2.2562.46	15.2.2562.46	—
Exchange Online	Not affected — Microsoft has already mitigated this on the cloud side.

Scope of the Crisis: 22,000 Servers and a Nation-Level Warning

The Shadowserver Foundation, which runs daily internet-wide scans against the Exchange version fingerprint, counted 21,899 unique IP addresses hosting vulnerable Exchange installations as of 31 August 2026. That number had barely moved since the patch shipped three weeks earlier — suggesting that a large proportion of on-premises Exchange administrators either do not have an automated patching process or are waiting for the next quarterly maintenance window.

The situation is not just a global statistic. Germany’s Federal Office for Information Security (BSI) published a warning on 28 August 2026, estimating that approximately 85 % of on-premises Exchange servers in Germany remain unpatched. The Netherlands’ NCSC-NL separately confirmed that a working exploit for CVE-2026-62911 is actively circulating. These are major, mature cybersecurity ecosystems — if they are struggling to achieve widespread patching, the challenge for other regions, including South Asia, is likely even more pronounced.

India is home to thousands of on-premises Exchange deployments, particularly among regulated sectors including banking and financial services, the public sector, and manufacturing. Many of these operate Exchange 2016 or 2019 on extended support cycles, precisely the versions most exposed here. For this cohort, CVE-2026-62911 is not an abstract threat — it is a live, weaponised attack surface with a public PoC and nation-state-level actor attention.

Why This Is Harder to Patch Than It Looks

Several factors conspire against quick remediation. First, Exchange Server updates are notoriously complex — they are large packages that require the service to be restarted and sometimes take hours to apply, making weekend downtime scheduling necessary. Second, many organisations are on Exchange 2016, which reached mainstream end-of-support in October 2025 and now requires a paid Extended Security Update (ESU) subscription (Period 2, May–October 2026) even to be eligible for the SU9 patch. Third, the SU9 package alone does not fully mitigate the vulnerability: administrators must also manually enable Extended Protection for Authentication via the provided script, a step that many SU deployment guides bury or overlook.

This combination of extended change-control cycles, ESU licensing barriers, and multi-step remediation explains why the Shadowserver count is barely moving — and why the window for attackers is still wide open.

What You Should Do — Sanjay Seth’s Expert Action Plan

Across my work helping enterprises in Delhi NCR and across India harden their perimeters and adopt zero-trust architectures, email infrastructure consistently ranks as one of the highest-value and least-hardened assets. Here is what every on-premises Exchange operator needs to do this week:

1. Identify your Exchange build immediately. Open Exchange Admin Center → Servers → look at the version column, or run Get-ExchangeDiagnosticInfo -Server <name> -Process EdgeTransport -Component ResourceThrottling | Select-Object *Version* in Exchange Management Shell. If you are below the SU9 build numbers in the table above, you are exposed.
2. Apply SU9 (KB5121573) during your next available maintenance window — do not wait for the next quarterly cycle. For Exchange 2016, ensure your ESU Period 2 licence is active before attempting installation. Download directly from the Microsoft Exchange Update Centre.
3. Enable Extended Protection for Authentication (EPA) after patching. Microsoft provides a script (ExchangeExtendedProtectionManagement.ps1) in the SU9 package. EPA is not enabled automatically — you must run this script explicitly. Without EPA, the NTLM relay vector remains partially open even after SU9.
4. Audit MRSProxy exposure. If you do not run cross-forest mailbox moves, consider disabling the MRSProxy endpoint entirely: Set-WebServicesVirtualDirectory -MRSProxyEnabled $false. This removes the attack surface at the cost of cross-organisation move capability.
5. Rotate service-account and machine-account credentials. If patching is delayed, assume the relay could already have been attempted against your environment. Rotate machine account passwords and service account credentials, and inspect Windows Security event logs for anomalous NTLM relaying (Event ID 4624 with logon type 3 from unexpected source IPs against Exchange service accounts).
6. Layer micro-segmentation at the perimeter. Ensure that MRSProxy (HTTPS/443) is not reachable from arbitrary internal subnets. IP-restrict access to known migration server ranges. This is a core zero-trust principle: even internal trust must be conditional and scoped. For organisations with FortiGate next-generation firewall deployments, tighten inbound firewall policies to Exchange ports so lateral NTLM relay from compromised workstations is blocked at the network level, not just the application level.
7. Monitor for exploitation indicators. Add detection for: HTTP POST requests to /EWS/MRSProxy.svc with NTLM Negotiate headers from untrusted subnets; unexpected IMailbox_Config6 WCF method invocations in IIS logs; mail-flow anomalies (unexpected send-on-behalf-of activity); and file-system writes to unusual paths from the Exchange worker process.

The broader lesson here is one we see repeatedly: NTLM relay attacks succeed because services trust authentication without verifying that the transport channel binding matches the authenticated identity. EPA is the server-side enforcement of that binding. This same class of attack also appears in the credential-relay chains used by APT29 against OAuth and MFA flows. The architecture of trust — not just individual patches — must be reviewed.

Frequently Asked Questions

Does CVE-2026-62911 require the attacker to be on the same network as the Exchange server?

Not necessarily. Classic NTLM relay typically requires the attacker to be in a man-in-the-middle position on the same subnet. However, the PoC circulating for CVE-2026-62911 uses reflection — relaying an Exchange machine account’s own outbound NTLM authentication back to MRSProxy. This can be triggered remotely if the attacker can coerce Exchange’s machine account to authenticate outbound to an attacker-controlled server (via techniques like PrintSpooler coercion, PetitPotam, or the MSExchangeMailboxReplication service’s built-in callback mechanisms). This makes the attack viable over the internet, not just the LAN, for servers reachable from untrusted addresses.

We are on Exchange Online (Microsoft 365). Are we at risk?

No. Microsoft has confirmed that Exchange Online is not affected by CVE-2026-62911. The vulnerability is specific to on-premises Exchange Server deployments where administrators manage the underlying Windows Server and Exchange software. If you have a hybrid deployment with on-premises Exchange servers acting as hybrid connectors, those on-premises nodes are still in scope and must be patched.

What is the realistic threat timeline — how soon could we see mass exploitation?

The public PoC has been live since late August 2026. NCSC-NL has already flagged active exploit circulation. Historical patterns from previous high-profile Exchange CVEs (CVE-2021-26855 ProxyLogon, CVE-2022-41082 ProxyNotShell) show that mass, automated exploitation typically follows within one to three weeks of a public PoC. Given that we are already in that window and 22,000 servers remain unpatched, mass exploitation activity is a near-term certainty, not a hypothetical.

Can endpoint or email security tools detect exploitation after the fact?

Endpoint Detection and Response (EDR) tools can detect post-exploitation activity (process injection, credential dumping, lateral movement) but may not have visibility into the MRSProxy relay itself, which occurs at the IIS/WCF layer. The most reliable detection is network-layer logging of NTLM Negotiate headers on the MRSProxy endpoint, combined with IIS log analysis for MRSProxy.svc calls from unexpected source IPs. If you have a SIEM, build a rule on Exchange IIS logs filtering for POST /EWS/MRSProxy.svc with status 200 from IPs outside your known migration server ranges.

---

Protect Your Exchange Environment Before the Next Attack Wave

CVE-2026-62911 is a stark reminder that on-premises email infrastructure — long treated as a stable, set-and-forget asset — is in the crosshairs of sophisticated adversaries armed with Pwn2Own-grade research and public exploit code. With 22,000 servers still vulnerable and mass exploitation likely imminent, the time to act is now.

If your team needs help rapidly assessing Exchange patch status, enabling EPA, micro-segmenting Exchange traffic with FortiGate, or designing a zero-trust email access model that reduces your NTLM attack surface, I can help. Reach out for a no-obligation security assessment and let’s close this gap before the attackers do it for you.

Sources: BleepingComputer · Help Net Security · Shadowserver Foundation · CybersecurityNews · FrankysWeb · GBHackers