Exchange OWA CVE-2026-42897 Mitigation Guide

Microsoft has confirmed exploitation in the wild for CVE-2026-42897, a spoofing vulnerability in on-premises Microsoft Exchange Server triggered through Outlook Web Access (OWA). A permanent security update is still pending. The work this week is to prove the Exchange Emergency Mitigation Service (EEMS) is doing its job, fall back to the Exchange On-premises Mitigation Tool (EOMT) where it cannot, and cut residual OWA risk before the patch lands.

What should Exchange admins do about CVE-2026-42897 today?

Confirm OWA exposure. Inventory every on-premises Exchange Server 2016, 2019, and Subscription Edition (SE) host, including hybrid and “forgotten” management servers, and identify which ones publish OWA externally.
Verify EEMS coverage. Use Get-Mitigation and the Exchange Health Checker to confirm the CVE-2026-42897 mitigation is in Applied state on every in-scope server (Microsoft Exchange Team guidance).
Run EOMT in disconnected environments. For air-gapped or proxy-restricted Exchange hosts that cannot reach the EEMS service, run EOMT.ps1 -CVE "CVE-2026-42897" in a controlled change window (Microsoft Exchange Team guidance).
Reduce residual risk. Restrict OWA exposure, retire Internet Explorer Mode access to OWA, enforce MFA, and hunt for mailbox-rule and session-abuse patterns while waiting for the permanent update (Microsoft Security Response Center).

If you already worked through our earlier Exchange CVE-2026-42897 KEV verification post, this guide goes one layer deeper into the OWA-specific mitigation mechanics, EEMS verification, EOMT runbook, and residual-risk controls.

What is CVE-2026-42897 in Exchange OWA?

CVE-2026-42897 is described by NIST’s National Vulnerability Database as an improper neutralization of input during web page generation (cross-site scripting) issue in Microsoft Exchange Server that can allow an attacker to perform spoofing over a network (NVD CVE-2026-42897).

Microsoft’s Exchange Team explains the practical trigger: an attacker sends a specially crafted email, and when a user opens that message in OWA and certain interaction conditions are met, JavaScript can execute inside the user’s authenticated webmail session (Microsoft Exchange Team guidance). Microsoft’s MSRC advisory marks the issue as Exploitation Detected and recommends enabling EEMS where it is disabled (Microsoft Security Response Center).

This is not server-side remote code execution on the Exchange host. The initial execution happens in the user’s browser, which is why the mitigation relies on Content Security Policy (CSP) headers served by OWA, and why follow-on hunting needs to look at identity and mailbox activity, not just Exchange process behavior.

Which Exchange versions are in scope?

Microsoft lists the following on-premises Exchange versions as affected at any update level (Microsoft Exchange Team guidance):

Exchange Server 2016 — future security updates are planned for CU23 customers enrolled in the applicable Period 2 Exchange Server ESU program.
Exchange Server 2019 — future security updates are planned for CU14 and CU15 customers enrolled in the applicable Period 2 Exchange Server ESU program.
Exchange Server Subscription Edition (SE) — an update is planned for SE RTM.

Microsoft confirms Exchange Online is not impacted (Microsoft Exchange Team guidance). For hybrid tenants, the operational risk sits on whatever on-premises Exchange roles remain — including legacy boxes kept around for management, recipient administration, or mail flow.

The default path: Exchange Emergency Mitigation Service (EEMS)

Microsoft’s preferred mitigation path is the Exchange Emergency Mitigation Service. EEMS is enabled by default and applies emergency mitigations automatically when Microsoft publishes them, including the mitigation for CVE-2026-42897 (Microsoft Exchange Team guidance) (Microsoft Security Response Center).

For the security team, the question is not “is EEMS on.” The question is “can we show, per server, that the CVE-2026-42897 mitigation is applied and current.”

EEMS prerequisites

Server must be running a March 2023 or newer Exchange Server cumulative update or SU baseline to check for new mitigations (Microsoft Exchange Team guidance).
The Exchange host needs outbound connectivity to the EEMS service so it can fetch and apply mitigations.
EEMS must be enabled (the default). If it has been disabled in your environment, Microsoft recommends re-enabling it (Microsoft Security Response Center).

How to verify the mitigation is applied

Microsoft documents two verification methods that produce evidence security and audit teams can keep (Microsoft Exchange Team guidance):

Viewing Applied Mitigations. Use the Exchange documentation procedure to list applied mitigations per server, and confirm the CVE-2026-42897 mitigation ID appears in Applied state. Microsoft notes the mitigation ID prefix associated with this issue is M2.1.
Exchange Health Checker. Run the Health Checker script and review the EEMS-related sections of the report. The report aggregates EEMS state, last-checked time, and applied mitigations into one artifact you can store in the change ticket.

Two cosmetic gotchas Microsoft has called out:

Some servers may show a “Mitigation invalid for this exchange version” message while the status still shows Applied. Microsoft describes this as cosmetic; the mitigation is in effect (Microsoft Exchange Team guidance).
Healthset alerts such as OWACalendar.Proxy may fire as a side effect of the mitigation. Treat as expected noise, but document the suppression decision so the next on-call shift does not chase it (Microsoft Exchange Team guidance).

When EEMS cannot reach the server: EOMT in disconnected environments

EEMS is not always available. Air-gapped Exchange deployments, hosts behind restrictive egress proxies, and servers running older CUs that pre-date the March 2023 baseline cannot fetch the mitigation automatically. For those cases, Microsoft provides the Exchange On-premises Mitigation Tool (EOMT), a PowerShell script that applies the CVE-specific mitigation locally (Microsoft Exchange Team guidance).

A controlled-change runbook for EOMT

Microsoft documents EOMT invocation patterns for CVE-2026-42897, including a single-server form and a per-server pipeline that excludes Edge transport (Microsoft Exchange Team guidance):

Single server: .\EOMT.ps1 -CVE "CVE-2026-42897"
All Exchange servers excluding Edge: Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Treat those commands as operational guidance, not a copy-paste invitation. An EOMT run that holds up in a change-control review usually looks like this:

Download EOMT from a known-good Microsoft source and stage it on the Exchange host. Capture the file hash before execution.
Open a change ticket per server with rollback steps, mail-flow checkpoints, and the named Exchange administrator running the script.
Snapshot or back up the Exchange host (or at minimum capture IIS configuration and OWA virtual directory settings) before running EOMT.
Run EOMT during a defined window and capture the script output (stdout, transcript, and the EOMT log).
Re-verify with Get-Mitigation and Health Checker after EOMT completes so the evidence artifact is consistent with the EEMS-managed servers.
Record exceptions. If any server cannot run EOMT (for example, an Edge role or an unsupported CU), document the compensating control and the path to bring it back into supported scope.

A subtle gotcha: Internet Explorer Mode for OWA

The mitigation relies on Content Security Policy headers, which are not supported by Internet Explorer or Microsoft Edge in Internet Explorer Mode (Microsoft Security Response Center). Users still accessing OWA through IE Mode do not benefit from the CSP-based mitigation, even after EEMS or EOMT reports Applied.

If your estate still has legacy workflows pinned to IE Mode for OWA:

Identify those users with browser telemetry, conditional access logs, or OWA HTTP logs.
Migrate them off IE Mode for OWA. If they must stay temporarily, restrict their OWA access to a controlled network path and accelerate the work to retire IE Mode.
Document this as a known residual-risk exception in the same evidence package that holds the EEMS/EOMT verification.

Residual risk controls while waiting for the permanent update

Microsoft describes the current measures as temporary mitigation and says it is working on a future security update (Microsoft Security Response Center) (Microsoft Exchange Team guidance). Use the gap to shrink residual risk along three axes.

1) Reduce OWA exposure

Restrict OWA to trusted networks or VPN/ZTNA where business workflows allow.
Put a modern reverse proxy or WAF in front of OWA with end-to-end logging.
Validate that the OWA endpoint is the only Exchange surface published externally. Retire stray management interfaces.

2) Tighten identity for webmail

Enforce MFA for OWA, including for service and shared mailboxes where feasible.
Reduce legacy authentication exceptions that still permit basic auth or token replay against OWA.
Tune conditional access for risky sign-in patterns (impossible travel, new device, atypical user agent).

3) Hunt for post-exploitation patterns

Because the initial execution happens in the user’s authenticated OWA session, the most useful detection ideas focus on what an attacker would do after the script runs:

Inbox rules: new forwarding, redirect, or delete rules — especially rules that move attacker-relevant terms to RSS Feeds or Deleted Items.
Mailbox audit: unusual reads of high-value mailboxes, delegate changes, or out-of-band message access.
Sign-in telemetry: new IPs, new user agents, impossible travel, or unexpected MFA prompts for OWA users.
Outbound activity: message sends from high-value mailboxes that do not match the user’s normal pattern.
OWA HTTP logs: abnormal request paths or script-like parameters reaching OWA, reviewed against a known baseline.

Keep hunting evidence-based. Microsoft has not published attacker infrastructure for CVE-2026-42897 in its public guidance, so resist the urge to fabricate IoCs. Record the scope, the timeframe reviewed, and the result — that is the audit artifact.

What evidence to retain

For a CVE this active, the evidence package matters as much as the technical action. Recommended artifacts per Exchange server:

Inventory entry: hostname, role, version, CU/SU level, OWA exposure status, business owner.
Mitigation record: EEMS status snapshot or EOMT execution evidence with timestamps, log path, and operator.
Exception record: servers that could not be mitigated, with compensating controls and a target return-to-supported date.
Monitoring record: OWA, authentication, mailbox audit, EDR, and proxy logs reviewed; scope and timeframe of the hunt; result.
Patch-readiness record: ESU eligibility, maintenance window, rollback plan, and named owner for applying Microsoft’s permanent update when released.

Public timeline

May 14, 2026: Microsoft publishes Exchange Team guidance for CVE-2026-42897 and NVD publishes the CVE entry (Microsoft Exchange Team guidance) (NVD CVE-2026-42897).
May 15, 2026: CVE-2026-42897 added to the CISA Known Exploited Vulnerabilities catalog; due date May 29, 2026 for federal civilian agencies under BOD 22-01 (NVD CVE-2026-42897) (CISA KEV catalog).
Ongoing: Microsoft updates the Exchange Team blog and MSRC advisory as guidance evolves, with a permanent security update still pending at time of writing (Microsoft Security Response Center).

Frequently asked questions about CVE-2026-42897 OWA mitigation

How do I verify that EEMS applied the CVE-2026-42897 mitigation?

Use Microsoft’s “Viewing Applied Mitigations” procedure to confirm the mitigation ID (prefix M2.1) is in Applied state per server, and run the Exchange Health Checker to capture EEMS state in a single report. Store both as the evidence artifact (Microsoft Exchange Team guidance).

When should I use EOMT instead of EEMS?

Use EOMT for Exchange hosts that cannot reach the EEMS service — air-gapped environments, hosts with restrictive egress, and servers below the March 2023 cumulative update baseline that EEMS requires. Run EOMT inside a change window with a backup, capture the script log, then re-verify with Get-Mitigation so the evidence matches your EEMS-managed servers (Microsoft Exchange Team guidance).

Does the mitigation protect users on Internet Explorer Mode?

No. The mitigation uses Content Security Policy, which is not supported in Internet Explorer or Microsoft Edge in IE Mode. Users still accessing OWA through IE Mode do not benefit from the CSP-based mitigation and should be migrated off IE Mode for OWA (Microsoft Security Response Center).

Is Exchange Online affected by CVE-2026-42897?

No. Microsoft confirms Exchange Online is not impacted. The vulnerability affects on-premises Exchange Server 2016, 2019, and Subscription Edition (Microsoft Exchange Team guidance).

Is there a permanent patch yet?

No. Microsoft describes the EEMS/EOMT measures as temporary mitigation and says it is working on a future security update with planned update paths for Exchange Server SE RTM, Exchange Server 2019 CU14/CU15 under ESU, and Exchange Server 2016 CU23 under ESU (Microsoft Security Response Center) (Microsoft Exchange Team guidance).

Are there known side effects from the mitigation?

Yes. Microsoft documents possible OWA Print Calendar impact, inline image display issues, OWA Light issues, OWACalendar.Proxy healthset alerts, and a cosmetic “Mitigation invalid for this exchange version” message while status still shows Applied. Document these in the change ticket so the next on-call shift does not treat them as new incidents (Microsoft Exchange Team guidance).

Why does KEV matter if we are not a federal agency?

KEV listing reflects evidence of active exploitation. Private-sector organizations should treat it as a high-confidence prioritization signal even where BOD 22-01 does not apply. NVD records CVE-2026-42897 as listed in KEV with the required action to apply vendor mitigations (NVD CVE-2026-42897).

References

Cyberuptive runs a 24/7 follow-the-sun SOC staffed by U.S.-based analysts, headquartered in Honolulu and serving customers across Asia-Pacific and the U.S. mainland. We help mid-market organizations, MSPs, and Pacific defense subcontractors verify Exchange mitigations, hunt for post-exploitation activity in OWA and identity logs, and produce the patch governance record regulators and auditors expect.

Read our vulnerability scanning services, our patch management services overview, our Microsoft 365 and Azure security services, and our SOC-as-a-Service overview, or talk to us about a no-obligation Exchange OWA mitigation review.

Exchange OWA CVE-2026-42897: Mitigation and Verification Guide