Exchange CVE-2026-42897: The OWA Crafted-Email Zero-Day and the SMB Mitigation Playbook

On May 14, 2026, Microsoft disclosed CVE-2026-42897, a cross-site scripting flaw in Outlook Web Access on on-prem Exchange Server that lets an attacker execute attacker-controlled JavaScript inside a victim's authenticated OWA session by sending a single crafted email. Microsoft rated the bug 8.1, tagged it "Exploitation Detected," and shipped no patch. CISA added it to the Known Exploited Vulnerabilities catalog the next day with a federal remediation deadline of May 29, 2026. By the week of May 18, multiple outlets including The Hacker News were running the headline "exploited via crafted email" against confirmed in-the-wild activity. Eight days later, Microsoft is still not shipping a permanent fix outside the Extended Security Updates program.

The affected products are exactly the ones SMBs run because they do not want to move email to the cloud: Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition. Exchange Online is not affected. If your mail server lives in your own rack or your hosting provider's data center, and you still answer mail through /owa, you are inside this story.

This article is the Red Hound playbook for the next 72 hours: verify that Microsoft's automatic URL-rewrite mitigation is actually applied on every server, force the mitigation in the few cases where it is not, hunt for compromise in the eight days the window has been open, and have an answer ready when leadership asks why on-prem Exchange is still in production.

What the bug actually does

CVE-2026-42897 is a stored cross-site scripting flaw in OWA's mail-rendering pipeline. NVD classifies it as CWE-79 with a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. In English: an unauthenticated attacker on the internet sends an email, the email lands in a mailbox on the on-prem Exchange server, and when an authenticated user opens that email through the OWA web client, OWA fails to neutralize the message body and executes the attacker's JavaScript inside the user's browser session.

The exploit chain does not start with a server takeover. The payload is the email itself. The privilege escalation is from "attacker on the internet" to "attacker holding the victim's OWA session." Once that happens, the technical writeups from Senthorus and SOC Prime describe the attacker doing what any compromised browser session can do against a webmail UI: harvest session tokens, read every message in the mailbox, set up forwarding rules to an attacker-controlled address, and send mail as the user. None of that requires a second exploit, a credential, or a malware drop. The whole chain runs inside the browser tab.

Two facts make this worse for SMBs specifically. First, OWA-side mailbox rules persist after the session ends; an attacker can plant a rule that quietly forwards finance correspondence to Gmail and disappear, and the next OWA login will not notice. Second, the bug requires user interaction (opening the message) but does not require a click on a link inside the message. Anti-phishing training does not save you here because the user did not do anything wrong.

Why this is a this-week SMB story

Three reasons the patch-Tuesday reflex of "we will get to it" does not fit this CVE.

There is no patch. Microsoft's May 14 Exchange Team blog post describes a URL-rewrite mitigation, not a fix. The permanent code fix is coming for Exchange Subscription Edition first; Exchange 2016 and 2019 customers only receive it through the paid Extended Security Updates program because mainstream support ended in October 2025. If you let Microsoft's automatic mitigation lapse — for example, because you disabled the Exchange Emergency Mitigation Service after a past EEMS-related outage — you are unpatched.

The CISA deadline is real even if you are not federal. The federal Binding Operational Directive does not apply to private companies, but the downstream pressure does. Cyber insurance underwriters now use KEV deadlines as the floor for "reasonable care" remediation. Government primes flow the deadline through their subcontractor agreements. If your MSP's master services agreement references CISA timelines, your operational deadline matches the federal one. May 29 is one week away from publication of this article.

The exploitation window is already open. The CVE has been live for eight days at the time of writing. BleepingComputer reported Microsoft's "Exploitation Detected" tagging the same day the advisory dropped, and follow-on outlets confirmed crafted-email activity targeting real on-prem deployments. The question is not whether attackers will use this — it is whether they already used it against you between May 14 and the day you finish reading this.

Verify Microsoft's automatic mitigation is actually applied

Exchange 2016, 2019, and Subscription Edition all ship with the Exchange Emergency Mitigation Service enabled by default. When Microsoft publishes a mitigation, EEMS deploys a URL-rewrite rule to IIS automatically. For CVE-2026-42897 that rule is mitigation ID M2.1.x. The right first step is to confirm that M2.1.x is actually in place on every Exchange server in your environment — not just trust that EEMS did its job. The official verification path uses the Exchange Health Checker script.

# Verify EEMS state and M2.1.x mitigation status on every Exchange server.
# Run from an elevated Exchange Management Shell on a management host.

Invoke-WebRequest https://aka.ms/ExchangeHealthChecker -OutFile HealthChecker.ps1
.\HealthChecker.ps1 -Server (Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" }).Name

# Open the generated HTML report and scroll to the "Exchange Emergency Mitigations"
# section. For every server you want to see:
#   EM Service: Enabled
#   Last EEMS Check: within the last 24 hours
#   Mitigations: M2.1.x  -  Applied

# Quick inline check without the HTML report:
cd $exinstall\Scripts
.\Get-Mitigations.ps1 | Format-Table Identity, MitigationsApplied -AutoSize

One trap to watch for: the Health Checker output can display "Mitigation invalid for this Exchange version" alongside the M2.1.x status. Microsoft has confirmed this is cosmetic. If the line below reads "Applied," the rewrite rule is in place. The "invalid" message is a display bug, not a deployment failure.

Force the mitigation where EEMS is off or absent

EEMS is on by default, but in our consulting practice we routinely find it disabled on at least one server per estate. The usual reasons: a past EEMS deployment broke a feature, an admin disabled the service during a maintenance window and never re-enabled it, or the server is air-gapped and cannot reach Microsoft's mitigation cloud endpoint. In those environments the manual path is the Exchange On-premises Mitigation Tool.

# Air-gapped or EEMS-disabled servers: pull EOMT and apply M2.1.x manually.

Invoke-WebRequest https://aka.ms/UnifiedEOMT -OutFile EOMT.ps1

# Single server:
.\EOMT.ps1 -CVE "CVE-2026-42897"

# Whole on-prem fleet, skipping Edge transport servers (EOMT does not apply to Edge):
Get-ExchangeServer |
    Where-Object { $_.ServerRole -ne "Edge" } |
    ForEach-Object { Invoke-Command -ComputerName $_.Name -ScriptBlock {
        .\EOMT.ps1 -CVE "CVE-2026-42897"
    } }

# Audit which mitigations EOMT applied without changing state:
.\EOMT.ps1 -ShowMitigationStatus -CVE "CVE-2026-42897"

Before you run EOMT in production, plan around the three known side effects Microsoft has published. OWA Print Calendar will not render correctly while the mitigation is in place; users who rely on it should screenshot the view or print from the Outlook desktop client. Inline images may not render in the OWA reading pane for some message types; the workaround is to deliver images as attachments or to fall back to Outlook desktop. The deprecated ?layout=light OWA mode breaks entirely. None of these are deal-breakers. Document them in the change ticket so help desk does not eat the next 48 hours of "OWA is broken" calls.

Hunt for compromise in the open window

Even if M2.1.x is applied today, the exploitation window has been open since May 14. You owe yourself a backwards-looking hunt before you declare victory. The bug is delivered by email and executed in the browser, so the high-signal log sources are Exchange transport, IIS, and the mailbox itself. Three checks, in priority order.

1. Inbox rules created in the last 14 days

This is the highest-value hunt because OWA session theft almost always ends with a forwarding rule. From an elevated Exchange Management Shell:

# Pull every inbox rule created or modified in the last 14 days
# across the whole org, with attention to external forwarding.

$cutoff = (Get-Date).AddDays(-14)
Get-Mailbox -ResultSize Unlimited |
    ForEach-Object {
        $mbx = $_
        Get-InboxRule -Mailbox $mbx.Identity |
            Where-Object { $_.WhenChanged -gt $cutoff -and ($_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo) } |
            Select-Object @{n='Mailbox';e={$mbx.PrimarySmtpAddress}},
                          Name, WhenChanged, ForwardTo, RedirectTo, Enabled
    } |
    Export-Csv .\suspect-rules.csv -NoTypeInformation

Any external SMTP destination in ForwardTo or RedirectTo that the mailbox owner does not recognize is in-scope for an incident. Treat it as compromise until proven otherwise.

2. IIS logs for OWA POST patterns since May 14

Default IIS logs live under %SystemDrive%\inetpub\logs\LogFiles\W3SVC1\. Grep the last fourteen days of files for OWA endpoints that received POSTs from unusual user agents or accepted unusually large request bodies. Senthorus and SOC Prime both flag suspicious session-token activity and unexpected mail-send actions as the highest-signal indicators in the absence of a public proof-of-concept. Cross-reference IIS log timestamps against your mailbox audit log for the same accounts.

3. Sent Items audit for sent-as-victim activity

If the attacker used the session to send mail, the evidence is in the user's Sent Items folder or in a transport log if the user has Sent Items hidden. Pull Search-MailboxAuditLog for any user whose IIS or inbox-rule timeline looks suspicious. Anything sent at 03:00 local time from a finance mailbox is the kind of thing that turns into a wire-fraud incident, not just a CVE rollout.

Have an answer to the on-prem question

Two adjacent issues will come up in the next leadership meeting and the playbook is incomplete without them.

Exchange 2013 has no path here. If you still run Exchange 2013, the EEMS mitigation does not apply, EOMT will not target the CVE on that version, and the Extended Security Updates window for 2013 closed years ago. The honest answer is that an Exchange 2013 server with OWA exposed to the internet right now is functionally indefensible against this bug. Either pull OWA off the internet today (an IIS rewrite that returns 403 on /owa/* from any source outside your office IP block buys time) or accept that the right move is an emergency migration to Exchange Online or Subscription Edition. Both are uncomfortable conversations. Neither gets easier by waiting.

Subscription Edition gets the patch first. Microsoft's Exchange roadmap spells it out: Exchange SE is the only on-prem product receiving permanent fixes outside the ESU paywall. Exchange 2016 and 2019 customers who do not enroll in ESU live on mitigations indefinitely after October 2025. If your environment is still running 2019 because the SE upgrade was on next quarter's roadmap, this CVE is the trigger to pull that work into this quarter. The mitigation works today, but the strategic answer is to be on a code path that gets actual patches.

The next 72 hours are not about a permanent fix you cannot ship. They are about confirming that the temporary fix Microsoft already pushed is on every server, that the eight-day exploitation window did not already cost you a mailbox, and that the next on-prem zero-day has a shorter response cycle than this one did. Run the Health Checker before lunch. Run the inbox-rule hunt before you go home. Put the SE migration on the calendar before the next CVE.