Microsoft Shipped Exchange CVE-2026-42897 Without a Patch. The DDQ Should Ask Whether Your Mailbox Tier's Emergency Mitigation Service Is Still Running.
On May 14, 2026, Microsoft disclosed CVE-2026-42897, a CVSS 8.1 cross-site scripting vulnerability in on-premises Exchange Server's Outlook Web Access that allows attackers to spoof identity by executing arbitrary JavaScript in a victim's browser when a crafted email is opened. The vulnerability affects Exchange Server Subscription Edition, Exchange 2019, and Exchange 2016; Exchange Online is not affected. Microsoft tagged the advisory "Exploitation Detected," credited an anonymous researcher, and CISA added the CVE to the Known Exploited Vulnerabilities catalog on May 15, with a BOD 22-01 remediation deadline of May 29, 2026 for federal civilian agencies.
No security update was shipped. The advisory is a mitigation, not a patch.
This is the fourth quadrant of a vendor-disclosure pattern I have been tracking across recent posts on incomplete patches, pre-exploit patches, and silent server-side fixes that arrived before the disclosure they required: mitigation-only. The risk does not get fixed at the vendor; it gets delegated to a customer-side default that the vendor itself recommends re-enabling, in language that presumes administrators have turned it off. The procurement instrument that should catch this delegation has no row for it, just as the questionnaire that should have preceded Mistral's MAI-2026-002 advisory was missing the supplier-attestation row.
The Failure
Microsoft's recommended mitigation is M2.1.x, an IIS URL rewrite rule applied by the Exchange Emergency Mitigation Service (EMS), a component integrated into Exchange since September 2021. The Microsoft Exchange Team's own blog post, quoted by BleepingComputer, makes the dependency explicit: "Using EM Service is the best way for your organization to mitigate this vulnerability right away. If you have EM Service currently disabled, we recommend you enable it right away." For air-gapped servers or environments where EMS has been disabled, administrators are directed to run the Exchange On-premises Mitigation Tool (EOMT) manually.
EOMT.ps1 runs locally on each Mailbox-role server; to apply it across an entire deployment in one shot, wrap the local invocation in Invoke-Command against the filtered server list:
Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | ForEach-Object {
Invoke-Command -ComputerName $_.Name -ScriptBlock {
Set-Location -Path "$env:ExchangeInstallPath\Scripts"
.\EOMT.ps1 -CVE "CVE-2026-42897"
}
}
Microsoft's description of the attack chain, quoted in Help Net Security, contains an explicit information withhold: "arbitrary JavaScript code to be executed in the context of the web browser" upon opening an email through OWA under "certain interaction conditions," with Microsoft declining to specify which interaction conditions enable successful exploitation. Defenders are told enough to apply the mitigation but not enough to write a high-fidelity detection.
The Architecture
EMS is enabled by default on supported Exchange builds, and that default is the load-bearing assumption underneath this disclosure. Microsoft's documentation describes EMS as an opt-out service: it ships on, it polls Microsoft's Office Config Service for new mitigations, and it applies IIS URL rewrite rules at the site, vDir, or server level when a CVE warrants it. Administrators can deactivate EMS via PowerShell, and Microsoft documents how; the feature is, by design, customer-controllable.
The broader architectural premise is reasonable in the abstract. A long-lived on-premises platform needs a way to push emergency mitigations to customers who cannot or will not patch on Microsoft's cadence, and EMS is that mechanism. The premise becomes load-bearing in a specific way for CVE-2026-42897, however, because Microsoft has chosen not to ship a security update at all. Where EMS would normally buy time until the next monthly Cumulative Update, it is now the entire remediation for non-Subscription Edition customers; the rewrite rule is the fix. Across five Fortinet zero-days in five months, the patch treadmill at least produced patches; this disclosure produces a mitigation that breaks features instead.
That shift matters because of who is covered by Microsoft's eventual permanent patch. The Register reported that when the durable fix ships, only Extended Security Update Period 2 enrollees of Exchange 2016 and 2019 will receive it; Exchange Server Subscription Edition will receive a public patch. For Exchange 2016 and 2019 customers who declined ESU Period 2, M2.1.x is not a temporary measure. It is the permanent remediation for the lifetime of those servers in their environment, fragmenting the patched and unpatched populations in the same way a single vendor's monoculture fragmented the Dutch hospital regulator's view of cyber resilience.
Where the Assumptions Break
EMS-as-default holds only if administrators leave EMS enabled, and Microsoft's own documentation acknowledges that they often do not. The reason is functional: the M2.1.x rewrite rule breaks specific OWA features that some user populations depend on. The Register's reporting on the side effects is concrete: OWA Print Calendar stops working, inline images in the OWA reading pane may not display, and OWA Light becomes entirely non-functional. Each of those breakages is a help-desk ticket, and each ticket creates pressure to disable the mitigation. EMS-disabled environments are common enough that Microsoft writes documentation for them by default.
A second assumption breaks at the verification layer. Microsoft has confirmed a cosmetic status bug in which the Exchange Health Checker or Get-Mitigations.ps1 output displays "Mitigation invalid for this exchange version" even when M2.1.x is in fact in the 'Applied' state; 'Applied' is the source of truth, but the warning text gives an administrator a defensible reason to roll the mitigation back. The control's operating effectiveness, in audit terms, is monitored by an output that lies about itself.
The third assumption breaks at the ESU paywall. For Exchange 2016 and 2019 customers not enrolled in ESU Period 2, there will be no security update, ever. The mitigation is the architecture going forward, which means the OWA feature regressions are also permanent. A buyer doing diligence on a vendor's Exchange-dependent SaaS product is now asking a question that the vendor's existing attestations do not answer: is your mailbox tier carrying a functionality-breaking emergency mitigation as its permanent compensating control, and have you verified it on every Mailbox-role server?
What the DDQ Should Ask
Current vendor due-diligence questionnaires, including SIG, CAIQ, and HECVAT, ask about patch management SLAs, vulnerability scanning cadence, and KEV remediation timelines. None of them, to my reading of the public 2026 templates, ask whether the Exchange Emergency Mitigation Service is in a running state on every Mailbox-role server, or whether mitigation M2.1.x is in 'Applied' state on each of those servers as of a given date. That is the gap CVE-2026-42897 creates, and it is a copy-paste row.
A concrete row buyers can add to their next questionnaire revision:
Exchange Emergency Mitigation Service state (Microsoft Exchange Server only). For each on-premises Microsoft Exchange Server in scope for this engagement, confirm in writing: (1) the Exchange Emergency Mitigation Service is enabled and in a running state; (2) mitigation M2.1.x for CVE-2026-42897 is in 'Applied' state on every Mailbox-role server, as verified by the most recent Exchange Health Checker or Get-Mitigations.ps1 output, with attached evidence dated within the last seven days; (3) if EMS is disabled for operational reasons, attach the EOMT execution record showing the equivalent IIS URL rewrite rules were applied to every Mailbox-role server; (4) describe the change-control process that would alert the buyer if EMS state changes or if a future Cumulative Update is observed to remove the M2.1.x rule.
The verification artifact matters because the cosmetic status bug breaks the assumption that a single command's output is trustworthy. The buyer should request the actual Get-Mitigations.ps1 stdout for each server, not a summary attestation; the 'Applied' state field is what carries the truth.
The row also closes the ESU question by implication. A vendor running Exchange 2016 or 2019 without ESU Period 2 enrollment is committing to M2.1.x as a permanent control, and the buyer is now on notice that the vendor's OWA-dependent features are degraded by design. That is a material fact about the service the buyer is purchasing.
What To Do This Week
If you operate Microsoft Exchange Server on-premises in any of the affected versions, run the EOMT command above against every non-Edge server today, regardless of EMS state, and capture the Get-Mitigations.ps1 output showing M2.1.x in 'Applied' status on each Mailbox-role server. Store that output as your evidence artifact. If you have disabled EMS for reasons related to the OWA Print Calendar, inline image, or OWA Light regressions, document the decision and the compensating controls in writing before May 29, 2026, the CISA BOD 22-01 deadline.
If you are a buyer of an Exchange-dependent SaaS product or a managed service that fronts on-premises Exchange, send the four-part question above to the vendor with a seven-day evidence deadline. The CVE has been on CISA's KEV list since May 15, 2026, and the vendor either has the artifact or does not. The artifact is the answer.
