CVE-2026-42897 is the third actively exploited Exchange Server zero-day in fourteen months. The specific technical details change each time — this one is an OWA XSS leading to session hijacking, the last one was a SSRF chain, the one before that was an authentication bypass. The pattern is consistent: Exchange is targeted, nation-state actors get there before a patch exists, defenders scramble.
After three iterations, the specific vulnerability has become less interesting than the structural question it keeps raising. Why does Exchange keep producing exploitable zero-days that reach nation-state exploitation before defenders can respond?
Email Infrastructure Receives Less Security Investment Than It Deserves
Compare how most large organisations treat their email infrastructure against how they treat their VPN gateway.
VPN gateways typically: sit behind a WAF, have dedicated network monitoring, get patched within 24 hours of a critical advisory, have their logs sent to SIEM with high-fidelity alerting, and are subject to quarterly penetration testing. This is appropriate — VPN gateways are a known-high-value target, they’re internet-facing, and the consequences of compromise are severe.
Exchange servers in many organisations: sit in a server room or mid-tier cloud tenant, get patched on the standard Patch Tuesday cycle (often weeks after release), have logs flowing to SIEM but with generic “Exchange operational” alert tuning, and are treated as infrastructure rather than a security perimeter. OWA is internet-facing at most organisations but is not always placed behind the same WAF and monitoring stack as the VPN.
The irony is that Exchange processes more untrusted content than any other enterprise system. Every external email is untrusted input delivered by an anonymous party over the internet. Exchange parses that input, renders it in browsers, indexes it for search, and processes its attachments. It is, by volume and by the variety of untrusted sources, the highest-risk inbound processing pipeline in the enterprise. It is not treated that way.
The Session Hijacking Attack Surface Is Growing
CVE-2026-42897’s session hijacking primitive reflects a broader shift in how attackers target email infrastructure. Earlier Exchange exploits were about code execution on the server — ProxyLogon, ProxyShell, and similar chains gave you a shell on the Exchange Server. The XSS-to-session-hijack approach is different: it gives you the ability to read any targeted user’s email without touching the server infrastructure at all.
This matters for defensive architecture. SIEM alerting on Exchange server-side anomalies — unexpected ASPX file creation, PowerShell spawned from IIS, unusual authentication events — misses client-side session theft entirely. The attacker doesn’t need to run anything on the Exchange Server. They need a target to open a malicious email in OWA, and then they have a valid browser session.
The signal this leaves in logs is a browser session that starts accessing email API endpoints at an unusual time or from an unusual location. That’s exactly the kind of signal that conditional access policies and continuous access evaluation are designed to catch — but only if those controls are applied to Exchange OWA sessions, and only if the risk-based re-authentication thresholds are tuned to catch session persistence from unexpected locations.
What Treating Email Infrastructure as an Adversarial Channel Looks Like
The useful reframe is: Exchange OWA is an internet-facing application that processes attacker-controlled input and renders it in authenticated user browsers. It should be treated with the same security posture as any other high-value internet-facing web application — not as internal trusted infrastructure that happens to have an internet-facing port.
That means: WAF in front of OWA with active rule tuning for Exchange-specific attacks. Conditional Access policies that trigger risk-based re-authentication for OWA sessions, not just for VPN access. SIEM alerting tuned to OWA session anomalies — new location, new device, mass inbox API calls, forwarding rule creation. OWA in scope for annual penetration testing. Exchange patch SLA aligned with internet-facing application standards, not server infrastructure standards.
None of this is complicated. It requires treating the threat model consistently — the same logic that drove security investment in VPN gateway protection applies directly to the email infrastructure that receives more untrusted input, is accessible to more external parties, and is more actively targeted by the groups who care about the content it holds.
CVE-2026-42897 will be patched. The next Exchange zero-day will still find organisations whose OWA monitoring lags their VPN monitoring by two years of security investment. The structural gap is what generates the recurring exploitation pattern.
Share this article