CVE-2026-42897: Microsoft Exchange Server Zero-Day Exploited in the Wild — No Permanent Patch, CISA Deadline May 29

Sources: Microsoft Exchange Team · The Hacker News · Help Net Security · CISA KEV Catalog · SOCPrime · Senthorus Security Blog · Security Affairs · Messageware · Cryptika | CVE: CVE-2026-42897 | CVSS: 8.1 High | Disclosed: May 14, 2026 | CISA KEV: Added May 15, 2026 | Federal deadline: May 29, 2026 | Permanent patch: Not yet available

Your email server is the attack surface

Email is the most trusted communication channel in any organization. It is also, consistently, one of the most exploited. CVE-2026-42897 combines both of these facts into a single, elegant, actively exploited attack: an adversary sends a specially crafted email to a target. The target opens it in Outlook Web Access. Arbitrary JavaScript — attacker-controlled code — executes inside the victim’s authenticated OWA browser session. No password required. No malware installed. No suspicious attachment to warn them. Just an email and a click.

Microsoft disclosed CVE-2026-42897 on May 14, 2026 — two days after its May Patch Tuesday release that patched 138 other vulnerabilities — with an immediate “Exploitation Detected” tag on the advisory. The flaw surfaced just two days after Microsoft’s Patch Tuesday for May 2026 updates, which patched 138 vulnerabilities. CISA added it to the Known Exploited Vulnerabilities catalog on May 15, giving federal agencies a deadline of May 29 to remediate. A permanent patch is still in development. The temporary mitigation — delivered through Microsoft’s Exchange Emergency Mitigation Service — must be applied manually on servers where the EM Service has been disabled.

The attack in plain English: one email, one click, session hijacked

Cross-site scripting vulnerabilities are sometimes dismissed as lower-severity web issues — the kind of thing that matters for public-facing apps but not enterprise email. CVE-2026-42897 is a reminder of why that dismissal is wrong when the vulnerable application is Microsoft Exchange Server.

Here is the full attack flow as documented by Microsoft and analyzed by Senthorus Security:

1. Attacker crafts a malicious email. The email contains a payload — HTML or script content — specifically designed to exploit how OWA’s web page generation handles and renders incoming email content. The attacker does not need any credentials. They do not need any access to the Exchange server. They need only the ability to send an email to a valid address at the target organization, which any attacker can do from an external email account or a compromised third-party domain.
2. Victim opens the email in Outlook Web Access. This is the critical step. The vulnerability is in OWA specifically — the browser-based interface that employees use to access Exchange email from any device. The vulnerability does not trigger through desktop Outlook clients, Exchange ActiveSync (mobile), or any other Exchange access method. Only OWA. If the organization’s users primarily access email through the desktop Outlook client, the exploitable attack surface is narrower — but any user who accesses OWA at all, including while traveling, working from a personal device, or using OWA as a fallback, is a potential target.
3. “Certain interaction conditions” are met. Microsoft has deliberately not specified what these conditions are — a common practice to avoid providing a public step-by-step exploitation guide before a patch is available. What is known: the conditions are realistic enough that active exploitation has been confirmed in the wild, meaning real attackers have already figured out how to reliably meet them.
4. Arbitrary JavaScript executes in the victim’s browser. An attacker could exploit this issue by sending a specially crafted email to a user. If the user opens the email in Outlook Web Access and certain interaction conditions are met, arbitrary JavaScript can be executed in the browser context. This JavaScript runs with full access to the victim’s authenticated OWA session — the same access the user themselves has. The attacker’s code can read any email in the victim’s inbox, send emails on behalf of the victim, access calendar data and contacts, exfiltrate OWA session cookies, modify email rules to silently forward all future mail to an attacker-controlled address, and pivot to any other web-based system that trusts OWA session cookies or that the victim accesses via the same browser session.

Why Exchange Server zero-days are particularly high-value targets

Exchange Server zero-days are dangerous because they sit at the center of corporate email, one of the most sensitive and widely used systems in any organization. Upon exploiting Microsoft Exchange Server flaws, attackers often get a direct path into internal communications, credentials, and business workflows.

This is not abstract. Consider what lives in an executive’s OWA inbox: merger and acquisition discussions, legal strategy, HR personnel files, financial projections, customer contracts, board communications, credentials reset emails, and authentication codes. An attacker with JavaScript executing in a CFO’s OWA session can read all of it, and send emails that appear to originate from the CFO’s account, without ever touching the Exchange server directly or leaving any footprint on the victim’s device. The Senthorus analysis describes the impact accurately: successful exploitation grants attackers a foothold inside authenticated user sessions — without requiring any credentials of their own.

Beyond data access, OWA session compromise is a reliable pivot point for business email compromise (BEC) attacks — the category of fraud that costs organizations more than any other cybercrime type globally. An attacker with OWA JavaScript execution on a finance team member’s session can initiate fraudulent wire transfer requests that appear to come from that person’s own account, with perfect email metadata, correct signature formatting, and no indication of external origin.

There is also the internet-exposure factor. A key reason they’re high risk is exposure. Many Exchange servers, especially on-premises deployments, are internet-facing. OWA is specifically designed to be internet-accessible — it is the remote access interface. Organizations that have exposed OWA to the internet for legitimate remote work access have also exposed the vulnerable endpoint to any attacker in the world.

What we know — and what Microsoft has not disclosed

Microsoft’s disclosure is deliberately limited in ways that are standard practice for active exploitation scenarios but frustrating for defenders trying to assess their exposure. As of May 18, 2026, no attribution to specific threat actors — APT groups, ransomware operators, or other named clusters — has been made public by Microsoft or CISA.

What is confirmed: active exploitation is occurring. What is not confirmed or disclosed: the identity of the threat actors, the targets they have hit, the scale of exploitation activity, whether the exploitation has been successful in achieving its objectives, and the precise technical conditions required to trigger the vulnerability reliably.

The absence of a public CVE-2026-42897 proof-of-concept is the one moderating factor in this situation. There is no public CVE-2026-42897 poc in the cited sources, and Microsoft has not published packet-level or forensic CVE-2026-42897 iocs. This means less-sophisticated threat actors cannot trivially replicate the exploitation technique — yet. The history of Exchange Server vulnerabilities, however, strongly suggests that working PoC code appears publicly within days to weeks of confirmation of active exploitation. Once public PoC code exists, the attack surface widens dramatically and opportunistic exploitation begins at scale.

This appeared two days after Patch Tuesday — a familiar pattern

The timing of this disclosure is worth noting. Microsoft’s May 2026 Patch Tuesday landed on May 12, patching 138 vulnerabilities. CVE-2026-42897 was disclosed on May 14 — two days later — as a zero-day that was not addressed in that patch cycle. This is a recurring pattern with Exchange Server: critical flaws emerge shortly after Patch Tuesday releases, either because attackers time their public exploitation to coincide with the reduced organizational attention that follows a major patch cycle, or because the vulnerability was discovered independently through analysis of what the latest patches changed.

It also means organizations that completed their May Patch Tuesday deployment, noted the 138 patched vulnerabilities, and moved on — are not protected. CVE-2026-42897 requires a separate, manual action beyond the regular Patch Tuesday update process.

The EEMS mitigation: what it does, how to verify it, and its side effects

Microsoft’s temporary fix for CVE-2026-42897 is delivered through the Exchange Emergency Mitigation Service (EEMS) — an automatic update mechanism introduced in September 2021 that applies URL Rewrite rules to Exchange Server to neutralize actively exploited vulnerabilities without requiring a full cumulative update. For customers who have the Exchange EM Service enabled, Microsoft released the automatic mitigation for Exchange Server 2016, 2019 and SE. The mitigation is already published and is enabled automatically.

If your Exchange servers have EEMS enabled (the default state), the mitigation was applied automatically and no further action is needed beyond verifying that it applied successfully. If EEMS has been disabled — which some organizations do as part of hardening or change control processes — the mitigation must be applied manually using the Exchange On-premises Mitigation Tool (EOMT).

Verify EEMS mitigation status

# Check if EEMS service is running
Get-Service -Name MSExchangeMitigation

# Check applied mitigations — look for CVE-2026-42897 with Status "Applied"
Get-Mitigations.ps1 -ExchangeServerNames $env:COMPUTERNAME

Apply manually if EEMS is disabled

# Download the latest EOMT script from Microsoft
# Run against all non-Edge Exchange servers in your environment
Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .EOMT.ps1 -CVE "CVE-2026-42897"

Microsoft is aware of a known issue where the mitigation shows “Mitigation invalid for this exchange version” in the Description field. “This issue is cosmetic and the mitigation DOES apply successfully if the status is shown as ‘Applied.'” Do not be misled by this cosmetic error message — if the status field says Applied, the mitigation is active.

Known side effects of the mitigation

Microsoft has documented the following known functional impacts once the CVE-2026-42897 mitigation is applied. These are expected and do not indicate a problem with the mitigation:

• OWA Print Calendar functionality may not work. Workaround: copy or screenshot calendar data before printing, or use the desktop Outlook client.
• Inline images may not display correctly in the OWA reading pane. Workaround: send images as email attachments rather than inline, or use the desktop Outlook client.
• OWA light mode (URLs ending in /?layout=light) does not work properly. Note: this feature has been deprecated and is not intended for production use.
• OWACalendar.Proxy healthset may show unhealthy. This can trigger alerts in Exchange monitoring solutions. Microsoft recommends ignoring these alerts while the mitigation is in effect — they are false positives caused by the URL Rewrite rule.

Full remediation steps

1. Immediately verify EEMS mitigation status on every on-premises Exchange server. Run Get-Mitigations.ps1 and confirm CVE-2026-42897 shows status “Applied.” Do this on every Exchange 2016, 2019, and SE server in your environment — the mitigation must be verified per-server, not just at the organization level.
2. If EEMS is disabled on any server, apply the EOMT script manually immediately. Do not wait. Download the latest EOMT from Microsoft’s GitHub repository (microsoft/CSS-Exchange) and run it as shown above. EEMS being disabled is surprisingly common in environments that have applied Exchange hardening guides or have strict change control processes around automatic updates.
3. Audit OWA access logs for suspicious activity since May 14, 2026. Look for users accessing OWA from unfamiliar IP addresses or geolocations, unusual email rule creation events (particularly rules that forward to external addresses or auto-delete messages), and mass email access or download events in short windows. Use Exchange’s built-in audit logging: Search-MailboxAuditLog and Get-MailboxAuditLog are the starting points.
4. Check for malicious inbox rules created on high-value accounts. Silent email forwarding rules are a primary post-exploitation persistence mechanism for OWA compromises. Run Get-InboxRule -Mailbox [username] on executive, finance, legal, and HR mailboxes and audit any rule that forwards externally, auto-deletes, or moves messages to obscure folders.
5. Review OWA-exposed attack surface. If OWA is internet-facing and not all users need external OWA access, consider restricting OWA to specific IP ranges (VPN exits, corporate egress) via Exchange’s IP restriction features or a reverse proxy/WAF in front of OWA. This does not patch the vulnerability but significantly reduces the exploitable attack surface.
6. Apply the permanent fix as soon as Microsoft releases it. Do not treat the EEMS mitigation as a long-term solution. The URL Rewrite workaround has functional side effects and is specifically a stopgap. When the permanent cumulative update is released, apply it within 24 hours on all affected Exchange servers. Enable EEMS on any server where it was disabled, so future automatic mitigations can be applied without manual intervention.
7. Federal agencies: document compliance with BOD 22-01 by May 29, 2026. CISA’s federal remediation deadline is firm. Ensure remediation records are documented and available for compliance reporting.

Exchange Server zero-days: a recurring and accelerating threat

CVE-2026-42897 follows a long and painful history of Exchange Server zero-days being exploited before patches are available. ProxyLogon (2021), ProxyShell (2021), ProxyNotShell (2022), and multiple subsequent Exchange vulnerabilities have all followed the same pattern: disclosure, immediate exploitation, emergency mitigations, delayed permanent patches, and organizations scrambling to apply workarounds that break functionality while waiting for a real fix.

The persistent pattern raises a question that is uncomfortable but important: why does on-premises Exchange Server continue to generate exploitable zero-days at this rate? The answer is architectural. Exchange Server is an extraordinarily complex piece of software — it handles email parsing, web rendering, calendar processing, authentication, and dozens of other functions across millions of lines of code. OWA in particular is a full web application running inside the Exchange security boundary, rendering arbitrary email content in a browser context. Every email that OWA renders is potential attacker-controlled input. That is an enormous attack surface that has proven resistant to fully securing despite years of effort.

The most durable protection against Exchange Server zero-days is migration to Exchange Online, which is not affected by CVE-2026-42897 or the majority of previous Exchange zero-days. Organizations still running on-premises Exchange — particularly those that have not yet applied the EEMS mitigation for CVE-2026-42897 — should treat this incident as renewed urgency for their cloud migration timeline.

Sources and further reading

• Microsoft Exchange Team — Addressing Exchange Server May 2026 Vulnerability CVE-2026-42897 (official)
• The Hacker News — On-Prem Microsoft Exchange Server CVE-2026-42897 Exploited via Crafted Email
• Help Net Security — Unpatched Microsoft Exchange Server Vulnerability Exploited (CVE-2026-42897)
• SOCPrime — CVE-2026-42897: Exchange OWA Spoofing Flaw Deep Dive
• Senthorus — Deep Dive: CVE-2026-42897 Spoofing Vulnerability in Microsoft Exchange OWA
• Security Affairs — CVE-2026-42897: Microsoft Confirms Active Exploitation of Exchange Server Zero-Day
• CISA — Known Exploited Vulnerabilities Catalog (CVE-2026-42897 entry)

DataWater publishes a daily cybersecurity threat brief. Article #14 — May 19, 2026. Previous: MiniPlasma Windows zero-day (May 19) · Fragnesia CVE-2026-46300 (May 18) · CVE-2026-20182 Cisco SD-WAN CVSS 10.0 (May 16) · NGINX Rift CVE-2026-42945 (May 14) · Dead.Letter CVE-2026-45185 (May 13) · Copy Fail CVE-2026-31431 (May 7).