Why Exchange SYSTEM RCE Bypasses Conditional Access and MFA: The Authentication Architecture Problem

The Exchange SYSTEM RCE chain demonstrated by DEVCORE at Pwn2Own Berlin 2026 achieves code execution at the operating system level, bypassing all identity controls including Conditional Access policies, MFA requirements, and Azure AD authentication entirely. Understanding why server-side RCE renders identity controls irrelevant is essential for accurate risk assessment.

4 min read
#exchange#identity#conditional-access#mfa#authentication#server-side-rce#pwn2own#zero-trust

When DEVCORE’s Orange Tsai demonstrated three-bug Exchange SYSTEM RCE at Pwn2Own Berlin 2026, some of the most common questions from security and IT teams were: “Does Conditional Access protect us? Does MFA prevent this? Can Zero Trust architecture reduce the risk?”

The answers illuminate an important architectural boundary that is sometimes misunderstood in enterprise security planning.

What SYSTEM RCE Means for the Identity Layer

The Exchange SYSTEM RCE chain achieves code execution on the Exchange Server operating system at SYSTEM privilege — the highest privilege level in Windows. This execution happens in the operating system process space on the server, not in the context of an authenticated user session.

Conditional Access policies, MFA requirements, and Azure AD authentication apply to user authentication events — the moment a user (or application acting as a user) presents credentials to gain access to a service. These controls are evaluated when a network client attempts to establish an authenticated session.

An RCE exploit does not establish an authenticated session through the identity layer. It exploits a vulnerability in the server-side code to execute arbitrary code directly on the server, outside the authentication flow entirely. From the perspective of Entra ID and Conditional Access, no authentication event has occurred. There is nothing to evaluate, block, or challenge.

Once the attacker has SYSTEM-level code execution on the Exchange Server, every authenticated user session and every piece of data that has ever passed through that server is accessible. They can read the Exchange database directly. They can impersonate any account by manipulating the running Exchange service. They can install tools that intercept future authentication events — which now do pass through the identity layer, processed by an Exchange Server whose operating system is under the attacker’s control.

The Zero Trust Boundary Shift

The Zero Trust model’s central principle is “never trust, always verify” — and its practical implementation typically focuses on network access: segment the network, require authentication for every resource, use short-lived tokens, evaluate context on every request. This is a significant improvement over perimeter-based security.

Zero Trust does not make servers immune to RCE. It makes network-level lateral movement harder after a server is compromised, and it limits the scope of damage from credential theft. But a server-side RCE attack does not use the network path that Zero Trust monitors. It uses the vulnerability in the application code.

The boundary that matters for Exchange SYSTEM RCE is not the identity boundary — it is the network access boundary to the Exchange Server’s internet-facing port (443 for OWA/EAC). Restricting who can reach port 443 of your Exchange Server matters. Applying a WAF that can detect anomalous Exchange Server request patterns matters. Monitoring for anomalous server-side processes and outbound network connections from Exchange matters.

These are network and endpoint controls, not identity controls. Identity controls matter enormously for credential theft prevention, session hijacking defence, and east-west lateral movement restriction — all of which are relevant to the Exchange threat landscape generally. But they do not address the server-side RCE layer.

Practical Implications for Risk Assessment

When briefing executive leadership or completing risk assessments on the DEVCORE Exchange chain, accurate framing matters:

What MFA and Conditional Access protect against: Credential-based access to Exchange — password spray, phishing-captured credentials, token theft attacks like CVE-2026-42897. These controls prevent a large class of Exchange compromise. They are essential and correct investments.

What MFA and Conditional Access do not protect against: Server-side RCE that achieves code execution without an authentication event. Once a threat actor has SYSTEM on Exchange, they operate at a layer below identity controls.

The correct defensive layer: Network access restriction (limit Exchange exposure to intended audiences only), web application firewall (detect anomalous Exchange request patterns), endpoint monitoring on the Exchange Server (detect unexpected processes, services, and outbound connections), rapid patching (close the server-side vulnerability window before exploitation). These controls address the server-side RCE threat model.

Zero Trust as defence in depth: Zero Trust architecture limits the damage radius after Exchange Server compromise — lateral movement from the compromised Exchange Server is harder in a well-segmented Zero Trust network. This is genuine and valuable. But it does not prevent the initial server compromise. The controls operate at different layers.

A security architecture that has invested heavily in Conditional Access and MFA while deprioritising Exchange patch velocity has made a common risk-prioritisation error that the DEVCORE chain exposes directly.

Share this article