Microsoft patches Exchange Server zero-day exploited in attacks

What the flaw allows

Microsoft has released a patch for an actively exploited Exchange Server vulnerability that allows attackers to execute arbitrary JavaScript inside the browsers of Outlook Web Access (OWA) users. Tracked as CVE-2026-42897, the high-severity spoofing flaw opens the door to cross-site scripting (XSS) and affects Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition (SE). It can be exploited remotely by an attacker who holds no privileges on the target system.

According to Microsoft's Exchange Team, exploitation begins with a specially crafted email sent to a victim. If the recipient opens the message in Outlook Web Access and a specific combination of interaction conditions is met, attacker-supplied JavaScript runs in the context of the user's browser. The root cause, as described in the CVE.org record and the NVD entry, is the improper neutralization of input during web page generation — a classic XSS condition — that lets an unauthorized attacker abuse the affected server.

Timeline and patch

Microsoft initially blunted the threat in mid-May by automatically pushing a temporary mitigation through the Exchange Emergency Mitigation Service (EEMS). The full fix shipped as part of the June 2026 Security Updates, and Microsoft is urging administrators to deploy those updates as soon as possible while leaving the earlier mitigation enabled for additional protection. The company said it is continuing to harden Exchange against XSS attacks and recommended customers keep the mitigation in place as a safeguard while further improvements are rolled out. Microsoft had not responded to questions about the in-the-wild activity at the time of the original report.

A persistent target

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) marked the bug as exploited in the wild on May 15, added it to its Known Exploited Vulnerabilities (KEV) catalog, and set a two-week remediation deadline of May 29 for federal agencies.

Exchange continues to attract attackers. Over the past five years, CISA has cataloged 20 exploited Exchange Server vulnerabilities, 14 of which have been abused by ransomware groups. The strain on legacy deployments was underscored last October when — just weeks after Exchange 2016 and 2019 reached end of support — CISA and the National Security Agency published guidance on hardening Exchange servers against attack.

Verifying the mitigation: a Health Checker blind spot

A separate finding tied to this CVE highlights a gap in how administrators confirm their servers are protected. As documented in the atiilla/CVE-2026-42897 repository, the Exchange Health Checker diagnostic tool (HealthChecker.ps1) — rated Medium severity (CVSS 5.3) for this specific tooling issue — fails to surface the mitigation that was deployed for CVE-2026-42897.

The Exchange On-premises Mitigation Tool (EOMT) installs the protection as an IIS outbound URL Rewrite rule named EOMT OWA CSP - outbound, which injects a Content-Security-Policy header. However, Health Checker's rule enumeration only reads inbound rules (system.webServer/rewrite/rules) and silently ignores outbound rules (system.webServer/rewrite/outboundRules). Because the tool never inspects outboundRules, the EOMT mitigation rule is completely invisible in its reports.

The practical consequence is a false-negative on mitigation status: an administrator relying on Health Checker to confirm the EOMT mitigation is active will see a report showing no outbound CSP rule, producing either a false sense of exposure or false confidence that no mitigation has been applied when one actually has.

The affected files and locations are:

Diagnostics/HealthChecker/Analyzer/Get-URLRewriteRule.ps1 (L49, L72, L97)
Diagnostics/HealthChecker/Analyzer/Invoke-AnalyzerIISInformation.ps1 (L442–459)
EOMT mitigation script: Security/src/EOMT/Mitigations/CVE-2026-42897.ps1 (L147–254)

Three distinct code paths in Get-URLRewriteRule.ps1 all read exclusively from .rewrite.rules. The first reads from the configuration root:


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

Path 2 reads from the per-location applicationHost.config (L72):


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

In each case the outbound rule collection is never queried, so the CSP mitigation deployed by EOMT does not appear in the audit. The issue was reported on 2026-05-15 and credited to the researcher who originally reported CSS-Exchange issue #2539.

Bottom line

Administrators running Exchange Server 2016, 2019, or SE should apply the June 2026 Security Updates immediately and keep the EEMS mitigation enabled as an added layer. When validating defenses, be aware that Health Checker will not report the EOMT-deployed outbound CSP rule — verify the EOMT OWA CSP - outbound rule directly in the IIS outbound rewrite configuration rather than relying on the diagnostic tool alone.