Microsoft has confirmed in-the-wild exploitation of a new Exchange Server zero-day tracked as CVE-2026-42897 (CVSS 8.1), a cross-site scripting (XSS) flaw in Outlook Web Access that lets an unauthorized attacker perform spoofing over the network. A booby-trapped email can execute attacker-supplied JavaScript inside a victim's OWA session when opened under certain conditions. No permanent patch exists yet; Microsoft has shipped temporary mitigations and is urging on-premises administrators to apply them without delay.

What the vulnerability is

According to Microsoft's Security Update Guide and the CVE record, CVE-2026-42897 stems from improper neutralization of input during web page generation — the classic root cause of stored/reflected XSS. In Exchange Server's Outlook Web Access component, content that should be treated as inert data is instead rendered as active markup, so an attacker can smuggle script into a page the victim trusts.

The practical attack vector is email itself. An adversary crafts a message whose contents include malicious JavaScript; when the recipient views that message in OWA, the script runs in the context of the victim's authenticated webmail session. Because the payload arrives as an ordinary email and fires in the browser, a single phishing-style message can be enough to run code in the victim's session.

Microsoft has stated it has observed exploitation in the wild but has not published indicators of compromise or details of the campaigns.

Why Exchange zero-days carry outsized risk

Exchange sits at the heart of corporate communications, and a large number of on-premises deployments expose OWA directly to the internet. Once an attacker can run code in a mailbox session, the downstream options are severe: reading mail and attachments, harvesting credentials, resetting passwords, pivoting deeper into the network, and establishing durable footholds through inbox rules or stolen tokens. That combination is why Exchange flaws are repeatedly weaponized in both espionage and ransomware operations.

The timing compounds the concern: the zero-day surfaced just two days after Microsoft's May 2026 Patch Tuesday, which addressed 138 vulnerabilities. The pattern of Exchange weaknesses drawing active abuse is well established — in April, CISA added an earlier Exchange deserialization bug, CVE-2023-21529, to its Known Exploited Vulnerabilities catalog.

Mitigation: the EOMT outbound CSP rule

With no full fix shipped, the interim defense is delivered through the Exchange On-premises Mitigation Tool (EOMT). The mitigation script Security/src/EOMT/Mitigations/CVE-2026-42897.ps1 deploys a Content-Security-Policy header-injection rule — named EOMT OWA CSP - outbound — as an IIS outbound URL Rewrite rule. A restrictive CSP is an effective counter to XSS because it constrains which script sources the browser will execute, blunting injected JavaScript even where the underlying neutralization flaw remains.

Administrators should run the current EOMT against affected on-premises Exchange servers and confirm the outbound CSP rule is present in IIS.

A verification gotcha: Health Checker can't see the mitigation

There's an important caveat for anyone validating mitigation status with Microsoft's Exchange Health Checker. As documented in the atiilla/CVE-2026-42897 write-up — a separate, Medium-severity (CVSS 5.3) issue in the CSS-Exchange HealthChecker diagnostic tool, reported 2026-05-15 — HealthChecker.ps1 audits IIS URL Rewrite rules but only enumerates inbound rules (system.webServer/rewrite/rules) and silently ignores outbound rules (system.webServer/rewrite/outboundRules).

Because the EOMT mitigation is implemented as an outbound rule, Health Checker never reads it. The affected enumeration logic in Diagnostics/HealthChecker/Analyzer/Get-URLRewriteRule.ps1 (lines 49, 72, 97) reads only from .rewrite.rules across three code paths. For example:


$rules = $content.configuration.'system.webServer'.rewrite.rules

Path 2 — applicationHost.config per-location (L72):


$rules = $location.'system.webServer'.rewrite.rules

The net effect: an administrator who relies on Health Checker to confirm that the EOMT mitigation is in place will get a report showing no outbound CSP rule — a false negative that can create either a false sense of exposure or false confidence about mitigation status. Affected files also include Diagnostics/HealthChecker/Analyzer/Invoke-AnalyzerIISInformation.ps1 (lines 442–459). Until that diagnostic is updated, verify the rule directly rather than trusting the Health Checker output.

Detection and mitigation checklist

  • Apply the latest EOMT mitigation for CVE-2026-42897 to all affected on-premises Exchange servers immediately.
  • Do not rely solely on Exchange Health Checker to confirm mitigation status — it does not read IIS outbound rewrite rules and will not surface the EOMT OWA CSP - outbound rule.
  • Verify the outbound CSP rule exists directly in IIS by inspecting the server's outbound URL Rewrite configuration (see the generic example in the next section).
  • Monitor msrc.microsoft.com for the permanent security update and apply it as soon as it is released.

Technical background: how OWA XSS leads to session compromise

(General explanation of this vulnerability class — not incident-specific claims.)

Cross-site scripting occurs when an application embeds attacker-controlled input into an HTML response without correctly encoding it for the output context. In a webmail client like OWA, message bodies, subjects, and headers are rendered into the DOM; if any path fails to sanitize active content (e.g., event handlers,