Microsoft Exchange CVE-2026-42897: Active Exploitation Without a Patch

Background. On-premises Microsoft Exchange has been a sustained, high-value target for advanced and opportunistic actors for the entire 2021–2026 window. ProxyLogon (CVE-2021-26855 + chain) in March 2021 was exploited at scale by Hafnium and dozens of follow-on clusters before mitigations stuck; ProxyShell (CVE-2021-34473 + chain) repeated the pattern in August 2021 (Microsoft Threat Intelligence, 2021-03-02 · CISA Alert AA21-321A, 2021-11-17). The Exchange Emergency Mitigation Service (EEMS), introduced in Exchange Server 2016 CU22 and 2019 CU11, was Microsoft's explicit response to that pattern: a small auto-update mechanism that ships URL-rewrite rules to live Exchange front-ends in the gap between an in-the-wild zero-day and a permanent CU (Microsoft, 2021-09-28). CVE-2026-42897 is the first 2026 case where EEMS — not a Patch Tuesday CU — is the line of defence against active exploitation; the deep dive that follows is therefore as much about EEMS verification and bypass conditions as about the XSS itself.

Vulnerability mechanics. CVE-2026-42897 is classified by Microsoft as a spoofing vulnerability (impact category) underpinned by CWE-79, improper neutralisation of input during web-page generation, in the Outlook Web Access (OWA) component (Microsoft MSRC, 2026-05-14). The CVSS:3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N describes a network-deliverable XSS that requires the victim to open the malicious message in OWA: no authentication is required of the attacker, only of the recipient. Microsoft assesses severity Critical despite the 8.1 base score — the "Critical" label reflects the impact reach (session-token theft, content tampering in the OWA session, downstream phishing from a now-trusted internal mailbox), not the base metric. Microsoft has not published the precise attacker-controlled fragment that delivers the JavaScript payload — consistent with Exploitation Detected status, the team is withholding payload format pending the permanent SU — but the MSRC FAQ confirms the chain shape: crafted email → OWA render → script execution → spoofing actions taken under the victim's authenticated OWA context. Affected versions are Exchange Server 2016 (all CU levels), Exchange Server 2019 (all CU levels), and Exchange Server Subscription Edition (RTM and current CUs); Exchange Online is unaffected.

Exploitation status and attribution. Microsoft confirmed Exploitation Detected on 2026-05-14 with the published advisory (Microsoft MSRC, 2026-05-14). The NCSC Switzerland Cyber Security Hub independently restated the active-exploitation finding in advisory #12577 on 2026-05-15 (NCSC-CH Security Hub #12577, 2026-05-15). CISA added the CVE to the Known Exploited Vulnerabilities catalog on 2026-05-15 with a federal civilian-branch remediation deadline of 2026-05-29; per PD-13 in this brief series, that deadline has no jurisdictional weight in Switzerland or the EU and is recorded here only as confirmation of the exploitation signal — defenders should drive the remediation timeline off the Microsoft-confirmed active exploitation, not the BOD 22-01 date. No named threat-actor attribution has been published; Microsoft notes the scale and identity of the exploitation activity are not yet detailed publicly (The Hacker News, 2026-05-15).

Attack chain. From the limited disclosure, the operationally credible kill chain is:

1. T1566.001 Phishing: Spearphishing Attachment — attacker delivers a specifically crafted email to a target whose mailbox is hosted on a vulnerable on-premises Exchange Server.
2. T1059.007 Command and Scripting Interpreter: JavaScript — when the target opens the message in OWA, browser-side JavaScript executes in the OWA origin's context.
3. T1185 Browser Session Hijacking — payload reads OWA session cookies / auth tokens and exfiltrates to attacker-controlled infrastructure.
4. T1078 Valid Accounts — attacker re-uses the exfiltrated session material to issue authenticated OWA requests as the victim, with full mailbox read/send privileges.
5. T1534 Internal Spearphishing — onward phishing from the now-trusted internal sender to high-value recipients (executives, finance, identity admins), spreading the access.

EEMS — what it does, when it doesn't apply. The Exchange Emergency Mitigation Service is a small Windows service installed by the Exchange setup process on Exchange 2016 CU22 / Exchange 2019 CU11 and later; it polls a Microsoft-hosted Office Config Service endpoint hourly for new mitigation rules and applies URL-rewrite rules to the IIS configuration when one matches the server's installed Exchange version. For CVE-2026-42897, Microsoft has published Mitigation M2, which rewrites the specific request format the in-the-wild exploit uses to deliver the XSS payload — the mitigation does not require an Exchange restart and applies automatically on any internet-connected, EEMS-enabled Exchange server (Microsoft Exchange Team, 2026-05-14). EEMS does not apply automatically in the following operationally common configurations: (a) Exchange Server 2013, on which EEMS is not available; (b) Exchange servers with no outbound HTTPS connectivity to officeclient.microsoft.com (air-gapped networks, segmented DMZs, environments with strict egress controls); (c) Exchange servers where EEMS has been manually disabled (Set-OrganizationConfig -MitigationsEnabled $false, Set-Server -MitigationsEnabled $false, or via Group Policy); (d) Exchange servers that have been hardened with custom IIS rewrite rules that conflict with the EEMS rule placement. For all four cases, operators must run the Exchange On-Premises Mitigation Tool (EOMT) — downloadable from aka.ms/UnifiedEOMT — via the Exchange Management Shell as Administrator, which applies the same URL-rewrite Mitigation M2 manually.

EEMS verification — what to actually run on every Exchange server. The canonical check is:

• Get-ExchangeDiagnosticInfo -Server <server> -Process MSExchangeHMWorker -Component EemsMitigation -SettingName MitigationsApplied and confirm the Mitigation M2 identifier published in the MSRC advisory appears in the output.
• Get-OrganizationConfig | Select-Object MitigationsEnabled and Get-Server <server> | Select-Object MitigationsEnabled should both return True.
• IIS Manager → Default Web Site → URL Rewrite should show the EEMS-injected rewrite rule corresponding to CVE-2026-42897.

If any check fails, run EOMT immediately; do not wait for the next EEMS poll cycle.

Permanent-patch availability — the Period 2 ESU constraint. Microsoft has signalled that the permanent fix will ship as a CU for Exchange Server Subscription Edition (publicly available SU) and as a security update for Exchange 2016 CU23 and Exchange 2019 CU14 / CU15 — but the Exchange 2016 / 2019 updates will only be distributed to organisations enrolled in the Period 2 Exchange Server Extended Security Update programme (Microsoft Exchange Team, 2026-05-14). Any Swiss or European public-sector organisation running Exchange 2016 / 2019 in production today should verify ESU enrolment status with its Microsoft licensing partner before relying on the permanent update path; organisations that are not enrolled face a structural constraint where EEMS Mitigation M2 is the permanent operational mitigation, not the bridge.

Hunt and detection concepts. The mitigation prevents future exploitation; it does not retroactively detect or remediate prior exploitation. Defenders should look back to 2026-05-09 (a generous overlap window prior to public disclosure):

• IIS access logs (front-end Exchange role) — /owa/ URLs with <script>, javascript:, or HTML-encoded equivalents in query strings; OWA URLs with anomalous referrer headers from external mail-rendering paths.
• Exchange transport logs — emails with HTML bodies that embed encoded JavaScript fragments delivered to mailboxes whose owners are OWA users (cross-correlate with Get-CASMailbox -OWAEnabled $true).
• EDR telemetry on Exchange front-end servers — w3wp.exe (IIS worker process, Exchange app pool) spawning unexpected children (cmd.exe, powershell.exe, cscript.exe, browser launchers) is the post-exploitation tell of XSS-to-execution chains observed in prior Exchange compromises.
• Exchange Application Event Log EID 4 (MSExchange Management) — for EEMS mitigation-state changes; flag any disable / re-enable cycle that does not correspond to a documented change.
• OWA session anomalies — Get-MailboxAuditLog for unusual mailbox-folder reads or message-send activity from sessions whose source IP differs from the user's established pattern.

Hardening and mitigation. The non-negotiable immediate action is verifying EEMS Mitigation M2 is applied on every Exchange Server 2016, 2019, and SE in the estate and applying EOMT where it is not. Beyond that, defenders should: (a) confirm Period 2 ESU enrolment for any Exchange 2016 / 2019 production deployment that is not on a migration path to SE or Online; (b) restrict OWA access at the perimeter to users behind Conditional Access compliant-device policy where possible, reducing the population of XSS-deliverable mailboxes; (c) plan migration to Exchange Server SE or Exchange Online — repeated EEMS-only mitigations across the 2021–2026 Exchange CVE history are the operational signal that on-premises Exchange has become structurally expensive to defend on the 2016 / 2019 codebases.