CVE-2026-62911: Why 85 Percent of On-Premises Exchange Servers Are Vulnerable and What Is Technically Behind It

At the end of August 2026, the BSI’s CERT-Bund published a figure that should raise eyebrows: Around 85 percent of on-premises Exchange servers in Germany are vulnerable to CVE-2026-62911. Since August 14, the agency has been notifying affected network operators. The trigger was a published proof of concept that enables a complete system takeover. Behind the matter-of-fact CVE number lies one of the more interesting Exchange vulnerabilities of recent years: a relay attack via an endpoint that most administrators do not have on their radar. This article explains the mechanism, puts the BSI figures into context, and describes the specific steps to take.

Anyone who only wants to understand the August 11, 2026 security update will find an overview of all seven CVEs, including builds and the OWA Light shutdown, in the article on the August SU. Here, the focus is on the one critical vulnerability in detail.

What CVE-2026-62911 Really Is

Microsoft classifies CVE-2026-62911 as an Elevation of Privilege vulnerability with a CVSS score of 8.0 and rates it as the only Critical vulnerability of the August Patch Tuesday. The CWE category provides the more precise description: CWE-294, “Authentication Bypass by Capture-Replay.” The attacker does not bypass authentication by guessing a password, but by intercepting a valid authentication from another account and reusing it against a target endpoint. In practice, this is a classic NTLM relay attack.

The vulnerability was discovered by Orange Tsai of the DEVCORE research team. He demonstrated it at the Pwn2Own Berlin 2026 competition, as part of a chain of three vulnerabilities that together allowed remote code execution with SYSTEM privileges on the Exchange server. This exact combination explains the apparent contradiction in many reports: on its own, CVE-2026-62911 is a privilege escalation that requires an already authenticated context. Combined with a coercion technique that first forces the authentication, it becomes an unauthenticated network attack. The PoC uses precisely this combination.

The Core: MRSProxy Without Channel Binding

The vulnerable endpoint is called MRSProxy, short for Mailbox Replication Service Proxy. Exchange provides it to allow mailboxes to be moved between servers and, in hybrid environments, between on-premises servers and Exchange Online. MRSProxy accepts Negotiate authentication but does not verify so-called Channel Bindings. That verification is at the heart of the issue.

Channel Binding ties authentication to the underlying TLS channel. Put simply, the client writes a cryptographic fingerprint of the TLS connection into the authentication data. The server verifies whether that fingerprint matches the connection over which the data arrives. If it does not match, the authentication was performed over a different channel than it claims, and the server rejects it. This process is the technical foundation of Extended Protection for Authentication. Without the verification, authentication intercepted elsewhere can be forwarded to the endpoint, and the attacker is then treated as the original account.

The key operational point is that this vulnerability existed even though Extended Protection has long been enabled by default in current Exchange versions. The MRSProxy endpoint was an exception in the security hardening: it did not enforce the Channel Binding that other endpoints enforce. The security update closes precisely this gap by making MRSProxy perform the verification. This is also why there is no workaround through Exchange Emergency Mitigation: the August update is the fix.

How the Attack Works

The published proof of concept combines four building blocks. Each one is known; their interaction is what makes the attack.

In the first step, the attacker causes the Exchange server to authenticate on its own initiative. The PetitPotam coercion technique over the MS-EFSR RPC interface is used for this purpose: a crafted call causes the server to sign in to the attacker using its own machine account. This account has extensive privileges on the Exchange system. In the second step, the attacker immediately forwards this sign-in to the MRSProxy endpoint instead of responding to it directly. Because MRSProxy does not verify Channel Binding (step three), Exchange accepts the forwarded sign-in even though it arrived over an entirely different channel. The attacker now operates with the server account’s privileges and can use them in the fourth step to write a file, usually an ASPX web shell, and execute arbitrary code as SYSTEM through it.

The result is a complete server takeover. For those affected, this means access to every mailbox: reading and sending email, downloading attachments, independently of any individual user. An Exchange server is therefore no longer an isolated mail system, but a foot in the door to the Active Directory behind it.

Affected Versions and Patches

All supported on-premises builds are affected. The August 11, 2026 security update raises servers to the following builds:

This is where the actual cause of the high vulnerability rate lies. Exchange Server 2016 and 2019 have been out of regular support since October 2025. Their security updates from May through October 2026 are available only to organizations enrolled in the paid Extended Security Updates program (Period 2). According to the BSI, only nine Exchange Server 2016/2019 servers in Germany are known to have a patch installed through this program. The vast majority simply remains unpatched.

Exchange Online is not affected by the vulnerability; Microsoft has already secured the cloud side. In hybrid environments, however, the update must still be installed on every on-premises server, including management-only servers and machines with only the Exchange Management Tools installed.

Reading the BSI Figures Correctly

The data comes from CERT-Bund, which uses its own scans and partner data to determine the patch status of internet-accessible Exchange servers. Three figures are central, and they are connected.

First, by the end of October 2025, 92 percent of the approximately 33,000 on-premises Exchange servers in Germany were running an unsupported version. This is the structural starting point. Second, around 85 percent of these servers are vulnerable to CVE-2026-62911 because they lack the August patch. Third, only nine servers are demonstrably patched through the Period 2 ESU program. The figures paint the same picture from two perspectives. A large proportion of servers are not unpatched because an update was overlooked, but because there is simply no regular update available for the deployed version anymore. The real backlog is not a patch gap, but a migration gap.

No comparable comprehensive survey is available for Switzerland. However, the situation is structurally similar, as Exchange 2016 and 2019 are also widespread there and have likewise been out of support since October 2025. For critical vulnerabilities that are actively exploitable, the NCSC (National Cyber Security Centre) consistently recommends installing updates immediately. Anyone operating on-premises Exchange 2016 or 2019 in Switzerland faces the same decision as German operators: patch through ESU as an interim measure, then migrate.

What to Do Now

The measures are clear and make sense in this order.

Install the August security update on all Exchange servers. For Exchange SE, it is a regular public update. For Exchange 2016 and 2019, it requires enrollment in the Period 2 ESU program; without that enrollment, you will not receive the patch. No workaround through Exchange Emergency Mitigation exists for this vulnerability.

Check whether Extended Protection is enabled and correctly configured on all endpoints. It is the permanent, structural protection against relay attacks of this kind and blocks them where Channel Binding applies. The update and Extended Protection do not replace each other: the patch closes the specific MRSProxy vulnerability, while Extended Protection hardens authentication overall. Both belong together.

Restrict internet access to web-based Exchange services. A server whose management and replication endpoints are not openly reachable from the internet, for example because they are accessible only through a VPN, removes the basis for this attack. This does not replace the update, but it noticeably reduces the attack surface.

And the real conclusion to draw from the BSI figures: plan the migration away from Exchange 2016/2019. The ESU program is a bridge until October 2026, not a permanent state. Anyone patching through the ESU program today is buying time for an orderly move to Exchange SE or Exchange Online, nothing more. Every additional month on an unsupported version extends the period in which the next vulnerability may hit without an available patch.