SURIQ
Microsoft scored CVE-2026-62911 an 8.0 and filed it as an elevation-of-privilege bug for an "authorized attacker." That framing is a large part of why, three weeks after the fix shipped, nearly 22,000 Exchange servers are still exposed to it. On September 1 a security researcher published a working proof-of-concept, and it does not read like a second-stage cleanup item. It coerces an Exchange server into authenticating to the attacker, relays that login into an unprotected internal service, and drops a webshell that runs as the server itself. Here is what the score misses, and what to actually do about it.
The relay path, end to end
The weak point is MRSProxy, Exchange's Mailbox Replication Service proxy. It is reachable through two endpoints with different security postures. The IIS-hosted /EWS/MRSProxy.svc path enforces Extended Protection for Authentication. The HTTP.sys-hosted replication proxy endpoint does not validate channel bindings, and that gap is the whole bug. An attacker first coerces an Exchange server's machine account into authenticating to a listener they control, using a Windows coercion technique such as PetitPotam. They then relay that NTLM authentication to the unprotected endpoint. With no channel binding to catch the swap, the service accepts the machine account as a legitimate caller. From there, reporting on the proof-of-concept describes the exploit calling replication methods (IMailbox_Config6 and IMailbox_Connect) to write an .aspx webshell into a web-served directory, after which the attacker runs commands as the Exchange service, which is effectively SYSTEM on the host. According to reporting on the exploit, researcher Nguyen Van Hiep published the code to GitHub on September 1, and the underlying Exchange chain was first demonstrated at Pwn2Own Berlin 2026.
Microsoft shipped the fix in the August 2026 security update, covering Exchange 2016 CU23, Exchange 2019 CU14 and CU15, and the Subscription Edition. Confirm the running build on each host rather than trusting the update history. No in-the-wild exploitation has been confirmed publicly as of this writing, so the honest status line is "public exploit available, mass exposure, not yet reported abused." That is precisely the window a defender wants to act inside, not after.
Why "authorized attacker" is the wrong mental model
Microsoft's own text says the flaw lets an authorized attacker elevate privileges, and the vector lands at 8.0. Read at a glance, that says "the attacker already needs a foothold, so treat this as a follow-on problem." The proof-of-concept says otherwise. The authorization the attacker uses is not a stolen human credential. It is the Exchange server's own machine account, coerced out of it over the network. Any attacker who can reach the server and trigger that coercion can start the chain, which sits far closer to unauthenticated than the label suggests. That distance between the paperwork severity and the real reachability is, I would argue, exactly why 21,899 servers went through a Patch Tuesday untouched. Score a bug like a cleanup item and it gets scheduled like one.
The NTLM relay Exchange never finished closing
Relaying NTLM authentication into Exchange is not a new bug class. It is the same primitive behind the ProxyLogon-era chains, and it is why Microsoft has spent three years pushing Extended Protection for Authentication onto Exchange as a default. CVE-2026-62911 exists because one internal endpoint was left outside that hardening. So the remediation has two halves, and the patch is only the first. Microsoft's guidance is explicit that admins should verify their Extended Protection settings, not merely install the update. If you applied the August fix but never turned Extended Protection on across your Exchange endpoints, confirm it now, because channel binding is the control that actually kills a relay. We made the same argument about this summer's most-exploited bugs: the patch is where the work starts. It holds doubly here, because the exposed surface is Outlook Web Access and its neighbors, the same surfaces the OWAReaper implant, attributed in prior reporting to a Russia-linked actor, was abusing only weeks ago.
How you would know you were hit
A patched server tells you nothing about the window before you patched, and the relay-to-webshell chain leaves specific tracks. Watch for NTLM authentication from an Exchange machine account arriving at the replication service from a host that is not itself an Exchange server; that is the relay in motion. Alert on freshly created .aspx files under the Outlook Web Access, Exchange Control Panel, and IIS web roots, since the webshell has to land somewhere web-served. Treat any replication-service call that originates off-box as suspect. If you find a shell, rebuild and rotate rather than clean in place. A mailbox server you cannot fully trust is not something you scrub and hand back, a point we made when Microsoft's July zero-days shipped already exploited.
Close the exposure now
- Apply the August 2026 security update for your version (Exchange 2016 CU23, Exchange 2019 CU14 or CU15, or the Subscription Edition), then verify the resulting build on the host.
- Turn on and verify Extended Protection for Authentication across every Exchange endpoint. The update closes this one path; Extended Protection is what stops the next relay from working at all.
- Take Exchange off the open internet. Shadowserver is counting 21,899 reachable instances, and the Dutch NCSC's advice to keep Exchange internal-only is the right default for a mail server no outsider should be able to touch.
- Hunt the pre-patch window: machine-account NTLM landing on the replication endpoint, new
.aspxfiles in the web roots, and replication calls coming from off the box. - If you still run Exchange 2016 or 2019 on-premises, price the migration. Both left mainstream support in October 2025, and the Subscription Edition is the only build with a future. A server you cannot count on to receive the next fix is one to move or isolate, not to keep patching by hand.
The uncomfortable read is that the score, not the researchers, set the priority here, and the score was low enough to leave a near-unauthenticated path to SYSTEM sitting on 21,899 servers. Take a vendor's severity as an input, not a verdict, and let the exploit's real reach decide how fast you move. On this one, move today.