CVE-2026-62911: From a Missing Channel Binding Check to SYSTEM on Exchange

Executive summary

Your Exchange server publishes the same mailbox replication service on two different paths. One of them has sat behind Extended Protection for years. The other one never checked who was knocking.

That gap is CVE-2026-62911, an authentication bypass by capture-replay (CWE-294) in on-premises Exchange. Microsoft scored it 8.0 and shipped the fix on 11 August 2026. It affects Exchange Server 2016 CU23, Exchange Server 2019 CU14 and CU15, and Exchange Server Subscription Edition RTM. Microsoft has not flagged it as exploited in the wild, but working exploit code is public, and on the last weekend of August Shadowserver counted 21,899 exposed servers still unpatched. Germany's BSI puts the national figure at around 85%.

Attack overview

If you run Exchange on your own hardware and it answers on the internet, you are in scope. So is a server that only answers internally, if an attacker already has a foothold on the network.

Before you triage this, settle a disagreement in the scoring. Microsoft's rating assumes an attacker who already holds some privilege and a user who clicks something. The Zero Day Initiative, which handled the disclosure, rates the authentication weakness on its own at 8.1 and says it needs neither. Harder to pull off, in their view, but no victim required. If this dropped to the back of your August queue because it looked like a bug that needed user interaction, move it back up.

The bug came from Orange Tsai of DEVCORE. He demonstrated it at Pwn2Own Berlin in May 2026 as one link in a three-bug chain that ended in code execution as SYSTEM, and the demonstration won $200,000. A working version is now on GitHub.

Root cause

Mailbox moves reach Exchange through a service called MRSProxy, and Exchange publishes it twice. The copy at /EWS/MRSProxy.svc runs as an IIS virtual directory, so it picks up whatever Extended Protection you have set there. The copy at /Microsoft.Exchange.MailboxReplicationService.ProxyService is registered directly with HTTP.sys, and that registration was missing one check.

The missing check is channel binding. It stamps an authentication handshake with a fingerprint of the encrypted connection the handshake was made on. The server then compares the stamp against the connection actually in front of it, so a handshake stolen from somewhere else does not match and gets thrown out. Take the stamp away and there is nothing to compare, so the same handshake works on any connection. That is what makes a relay possible: capture a handshake in one place, replay it in another.

Attack flow

The public exploit runs in five moves.

1. Coerce. The attacker forces a second Exchange host to authenticate outbound, using MS-EFSR, the protocol family behind PetitPotam.
2. Relay. The attacker's listener catches that machine account handshake and forwards it over HTTPS to the target's HTTP.sys endpoint.
3. Walk in. With no stamp to compare, the target accepts the handshake and treats the caller as that server. Authorisation is not a second obstacle, because the ms-Exch-EPI-Token-Serialization right sits on Exchange computer accounts by default.
4. Write. IMailbox_Config6 takes a destination path from the caller and IMailbox_Connect commits the write. Nothing checks where that path points or what the file is called, so it can land in a folder the web server hands out.
5. Execute. Make that file an ASPX page, and a single request to it runs code as the Exchange service account, NT AUTHORITY\SYSTEM.

Impact

Microsoft's own summary is blunt: the attacker takes over the mailboxes of every Exchange user, then reads mail, sends mail and downloads attachments. That alone is a reportable breach in most jurisdictions.

The chained outcome is worse. Running as SYSTEM on an Exchange server gives up the machine that holds every mailbox on the site, along with its certificates and whatever rights the Exchange Servers group carries in Active Directory. In most estates that group holds more than anyone remembers granting it. The blast radius from there is the domain, not the mail platform.

Indicators of Compromise (IoCs)

No campaign has been attributed yet, so there are no attacker IP addresses or malware hashes to load into a blocklist. What you can hunt for is the footprint of the technique.

On disk, look for new .aspx files under FrontEnd\HttpProxy\owa\auth\ or inetpub\wwwroot\aspnet_client\ with a creation time that does not match a cumulative update. In logs, look for two things: requests to /Microsoft.Exchange.MailboxReplicationService.ProxyService from anything that is not another Exchange server, and NTLM authentication where the account is an Exchange computer account but the source address is not that computer.

One signal belongs in your exposure checks rather than your hunt. Request the HTTP.sys path and read the 401 that comes back. A Server header of Microsoft-HTTPAPI/2.0 next to a Negotiate challenge means you have reached the bare listener with no Extended Protection in front of it. That tells you the server is unpatched, not that anyone has been in.

Detection methods

Windows security logs give the cleanest signal. Look for event 4624 with logon type 3 and the NTLM package, where the target is an Exchange machine account. Then check the source workstation against your real Exchange hosts. On domain controllers, event 4776 records the NTLM validation itself. Neither is unusual on its own; what matters is a machine account paired with a source that is not that machine.

IIS and HTTP.sys logs cover the second half of the chain. Any hit on the ProxyService path from outside the Exchange estate deserves investigation, not a filter rule. On the endpoint, watch for w3wp.exe spawning a shell. A webshell dropped into an Exchange virtual directory has to run somewhere, and that is where.

Mitigation and remediation

There is no vendor workaround, so patching is the fix. The August updates are KB5121573 for Subscription Edition RTM, KB5121574 for Exchange 2019 CU15, KB5121575 for Exchange 2019 CU14, and KB5121576 for Exchange 2016 CU23.

Two of those only reach you through the Extended Security Update programme, which ends on 31 October 2026. Exchange 2016 and 2019 went out of support in October 2025. Period 2 of the ESU was the last extension, and Microsoft has said there will not be another. After October there is no patch for the next bug of this kind.

If you cannot patch tonight, shrink the reachable surface. Take Exchange off the public internet. Turn on Extended Protection everywhere Exchange supports it. Restrict who can reach the coercion endpoints. Review what your Exchange machine accounts are entitled to in Active Directory. Then treat any internet-facing server unpatched since 11 August as one you need to check, not one you need to patch.

Lessons learned

Two ways into one service is a warning sign, and one you can look for in your own estate. Inventory endpoints by listener, not by URL. HTTP.sys and IIS are different front doors with different settings, and a baseline written for IIS does not cover both.

A vendor's score describes one bug on its own, not the chain it can end up in. When the research team publishes a different score for the same CVE, read both rather than splitting the difference.

End of support is a security control with a date on it. Anyone still running Exchange 2016 or 2019 has about eight weeks of updates left, and the next flaw of this kind will land on servers that cannot be patched at all.

References

BleepingComputer, Nearly 22,000 Microsoft Exchange servers vulnerable to hijack attacks, Sergiu Gatlan, 1 September 2026. https://www.bleepingcomputer.com/news/security/nearly-22-000-microsoft-exchange-servers-vulnerable-to-hijack-attacks/

Microsoft Security Response Center, CVE-2026-62911: Microsoft Exchange Server Elevation of Privilege Vulnerability, 11 August 2026. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62911

Nationaal Cyber Security Centrum (NCSC-NL), Ernstige kwetsbaarheden in Microsoft Exchange Server, August 2026. https://www.ncsc.nl/alerts/ernstige-kwetsbaarheden-in-microsoft-exchange-server

Microsoft Exchange Team, Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program, 15 April 2026. https://techcommunity.microsoft.com/blog/exchange/announcing-period-2-exchange-20162019-extended-security-update-esu-program/4511603