CVE-2026-62911: Why 85 per cent of on-premises Exchange servers are vulnerable, and the technical reasons behind it

CERT-Bund at BSI published a striking figure at the end of August 2026: around 85 per cent of on-premises Exchange servers in Germany are vulnerable to CVE-2026-62911. Since 14 August, the authority has been notifying the affected network operators. The trigger was a published proof of concept that enables a complete system takeover. Behind the sober 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 course of action.

Anyone who only wants to put the security update of 11 August 2026 into context can find an overview of all seven CVEs, including builds and the OWA Light shutdown, in the article on the August SU. This article examines 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 day. 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 from 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 authentication, it becomes an unauthenticated network attack. The PoC uses precisely this combination.

The core issue: MRSProxy without channel binding

The vulnerable endpoint is called MRSProxy, short for Mailbox Replication Service Proxy. Exchange provides it to enable mailboxes to be moved between servers and, in hybrid environments, between on-premises environments and Exchange Online. MRSProxy accepts Negotiate authentication but does not check so-called channel bindings. That check is exactly at the core of the problem.

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 checks whether this fingerprint matches the connection through which the data arrives. If it does not match, authentication was conducted through a different channel than it claims, and the server rejects it. This mechanism is the technical foundation of Extended Protection for Authentication. If the check is missing, authentication intercepted elsewhere can be forwarded to the endpoint, after which the attacker is treated like 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 protection: it did not enforce the channel binding that other endpoints enforce. The security update closes precisely this gap by making MRSProxy perform the check. 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 components. Each one is known; their interaction is what makes the attack possible.

In the first step, the attacker causes the Exchange server to authenticate on its own initiative. For this, the PetitPotam coercion technique is used via the MS-EFSR print RPC interface: a crafted call causes the server to log 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 login to the MRSProxy endpoint instead of answering it themselves. Because MRSProxy does not check channel binding (step three), Exchange accepts the forwarded login even though it arrived through an entirely different channel. The attacker now acts with the permissions of the server account and can use them in the fourth step to write a file, typically 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 all mailboxes: reading and sending emails, downloading attachments, independently of the 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 security update of 11 August 2026 raises servers to the following builds:

This is the actual reason for the high vulnerability rate. Exchange Server 2016 and 2019 have been outside regular support since October 2025. Their security updates from May to October 2026 are available only to those enrolled in the paid Extended Security Updates programme (Period 2). According to BSI figures, however, only nine Exchange Server 2016/2019 servers in Germany are known to have had a patch installed through this programme. The large remainder simply stays unpatched.

Exchange Online is not affected by the vulnerability; Microsoft has already secured the cloud side. In hybrid environments, the update must nevertheless be installed on every on-premises server, including pure management 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 Exchange servers reachable from the internet. Three figures are central, and they are connected.

First: at the end of October 2025, 92 per cent of around 33,000 on-premises Exchange servers in Germany were running an unsupported version. This is the structural starting point. Second: around 85 per cent 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 programme. The figures paint the same picture from two perspectives. A large proportion of servers are unpatched not because an update was overlooked, but because there is no longer a regular update for the version in use. The actual backlog is not a patch gap, but a migration gap.

No comparable nationwide survey exists for Switzerland. However, the starting position is structurally similar, because Exchange 2016 and 2019 are also widespread there and have likewise been outside support since October 2025. For critical vulnerabilities that are actively exploitable, the NCSC (National Cyber Security Centre) consistently recommends installing updates without delay. Anyone operating on-premises Exchange 2016 or 2019 in Switzerland faces the same decision as German operators: patch through ESU as a temporary 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, publicly available update. For Exchange 2016 and 2019, it requires enrolment in the Period 2 ESU programme; without this enrolment, the patch will not reach you. There is no workaround for this vulnerability through Exchange Emergency Mitigation.

Check whether Extended Protection is enabled and correctly configured on all endpoints. It is the lasting, structural protection against relay attacks of this type and blocks them wherever channel binding applies. The update and Extended Protection do not replace one another: 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 VPN, removes the basis for this attack. This does not replace the update, but it noticeably reduces the attack surface.

And the actual consequence of the BSI figures: plan the migration away from Exchange 2016/2019. The ESU programme is a bridge until October 2026, not a permanent state. Anyone patching through the ESU programme 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 time in which the next vulnerability strikes without an available patch.