Exchange Server Zero-Day CVE-2026-42897: What an SMB Should Do Today

Microsoft disclosed an actively exploited zero-day in on-premises Exchange Server yesterday afternoon. The CVE is CVE-2026-42897, the rating is Critical with a CVSS of 8.1, and the bug class is cross-site scripting in Outlook Web Access. As of this morning there is no permanent security update; Microsoft has published a temporary mitigation that the Exchange Emergency Mitigation Service applies automatically on supported builds.

This is the operational version of the post. If you run on-prem Exchange, here is what to verify in the next few hours, what to layer on top of the EEMS mitigation, and what to plan in the next 30 days. If you are on Microsoft 365 for email (the situation for most of the small businesses I work with), you have nothing to do for this CVE; skip to the section at the bottom on why I keep recommending the migration off on-prem Exchange anyway.

What CVE-2026-42897 actually is

The bug class

This is a cross-site scripting (XSS) vulnerability in Outlook Web Access, the browser-based webmail interface that Exchange Server exposes for users who do not have an Outlook desktop client. An attacker sends a specially crafted email; when the recipient opens it inside OWA in the browser, the malicious payload executes JavaScript inside the user's OWA session. From there the attacker can do anything the user can do in OWA: read mail, send mail as that user, set up mail forwarding rules to exfiltrate inbound messages, dump the contact list, and pivot.

The CVSS rating of 8.1 puts it firmly in the "patch fast" bucket but below the cataclysmic 10.0 of a wormable unauthenticated RCE. The vector is "network" but it requires user interaction in OWA. It is not pre-authentication remote code execution on the Exchange server itself, the way ProxyLogon and ProxyShell were. The blast radius per exploitation is one mailbox and the lateral access that grows out of it.

Affected products

• Exchange Server 2016 (all current cumulative updates).
• Exchange Server 2019 (all current cumulative updates).
• Exchange Server Subscription Edition.

Not affected:

• Exchange Online — the mailbox layer of Microsoft 365. If your users open mail at outlook.office.com, this CVE does not touch you.
• Exchange Server 2013 and earlier (out of support; you have other problems if you are running these).

Status as of this morning

• Active exploitation in the wild, confirmed by Microsoft.
• No permanent security update available. Microsoft has not committed to a public patch date as of this writing.
• Temporary mitigation published. Two delivery options: automatic via EEMS (recommended), or manual via a script Microsoft published for environments where EEMS is disabled.
• The threat-intel community has not yet attributed exploitation to a specific named actor, although the on-prem Exchange targeting profile historically maps to nation-state and ransomware-affiliate activity.

The Exchange Emergency Mitigation Service, in plain English

EEMS is the service Microsoft built after the ProxyLogon and ProxyShell incidents, when on-prem Exchange admins were caught flat-footed by zero-days that were being mass-exploited before patches existed. The premise is that Microsoft cannot make on-prem servers patch themselves automatically (people would revolt), but it can ship targeted, conservative mitigations through a built-in service that admins can opt out of if they want to.

How it works in practice: EEMS runs on every supported Exchange build, polls Microsoft's mitigation feed roughly every hour, and when a new mitigation is published for a known issue, the service applies it locally. Mitigations are scoped: they can disable a vulnerable URL, enforce an authentication check, or block a specific request shape. They are not patches. They reduce the attack surface enough to buy time until the real patch ships.

For CVE-2026-42897, the mitigation reportedly blocks the specific exploitation path inside OWA without disabling OWA entirely. Users who use OWA continue to use OWA. The malicious request shape is rejected.

How to verify EEMS is running and the mitigation applied

Open an elevated Exchange Management Shell on the server and run:

Get-Service MSExchangeMitigation

You want to see Status: Running and StartType: Automatic. If it is stopped or disabled, that is the first thing to fix.

Then list the mitigations currently applied to the server:

Get-ExchangeServer | Format-List Name, MitigationsApplied, MitigationsBlocked

The CVE-2026-42897 mitigation should appear in the MitigationsApplied list once EEMS has retrieved it from Microsoft's feed. If you do not see it yet, the polling cycle may not have completed; force a check by restarting the service:

Restart-Service MSExchangeMitigation

Then re-check the applied list. If it still does not show after an hour, your server may be on a cumulative update that does not yet ship the mitigation, and you will need the manual script from the Exchange Team blog.

If EEMS is disabled in your environment

Some organizations turn EEMS off because they want change control over their Exchange servers and do not want Microsoft applying mitigations without explicit approval. That position is defensible in a managed enterprise; in a small business it is usually a misunderstanding. If EEMS is off in your environment, today is the day to either turn it on or apply the manual mitigation script Microsoft published. The script is the same logic EEMS would apply, just executed by you. Microsoft's Exchange Team blog post (Addressing Exchange Server May 2026 vulnerability CVE-2026-42897) has the script and the prerequisites.

Defensive layers to add on top of the mitigation

The EEMS mitigation is good. It is also temporary, untested at scale, and built on the assumption that the bug class is fully understood. Until the permanent patch ships, layer additional controls:

Block external OWA from the firewall

If your users primarily use the Outlook desktop client and only occasionally use OWA from outside the office, the lowest-cost extra control is to block external access to OWA at the firewall and require users to come in through the VPN to reach it. Internal users keep using Outlook normally. External users hit one extra step. The exploit goes from "someone sends a malicious email to your CFO and waits" to "someone has to compromise your VPN first."

The exact path is firewall-specific. For most SOHO firewalls, you create a rule that blocks inbound TCP 443 to the Exchange server's external IP from anything except your VPN ranges and known third-party services that need OWA (mobile device management, ActiveSync clients if you do not also block those, integration partners). If you do block external OWA, communicate it to users before lunch so the help desk does not get flooded.

Force MFA on every Exchange-touching account if you can

On-prem Exchange MFA is harder than Microsoft 365 MFA, but it is not impossible. ADFS, third-party MFA proxies (Duo for example), and Microsoft's own MFA Server (deprecated but still in use) all add a second factor in front of OWA. If you have any of these in place, verify they are enforcing on OWA today. If you do not, a malicious script that can do things in the user's session is also a script that can read MFA tokens out of the page in some configurations. MFA is not a complete defense for an XSS exploit but it raises the cost for the attacker.

Watch for the post-exploitation tells

The thing the attacker is most likely to do after a successful exploitation is set up an inbox rule that auto-forwards inbound mail to an external address, or that auto-deletes specific senders so the user never sees the attacker's pivots. Pull a report of inbox rules created in the last 72 hours and review anything new, especially rules that forward externally or delete based on subject keywords. PowerShell:

Get-Mailbox |
  Get-InboxRule |
  Where-Object { $_.WhenCreated -gt (Get-Date).AddDays(-3) } |
  Select-Object MailboxOwnerId, Name, ForwardTo, RedirectTo, DeleteMessage

Anything that looks unusual, especially auto-forwards to free webmail or to a domain you do not recognize, is worth a deeper look.

Why this is the post that should make you migrate off on-prem Exchange

I want to be careful here, because I know not every small business can or wants to move to Exchange Online. There are real reasons to keep an on-prem mailstore: regulatory requirements, integration with line-of-business apps that expect local SMTP, or a simple preference for owning the box. None of those is wrong on its own. But the math has been quietly shifting for years, and CVE-2026-42897 is one more data point on the same curve.

Look at the on-prem Exchange zero-day history just from the last five years:

• 2021: ProxyLogon (CVE-2021-26855 and friends). Mass exploitation. Tens of thousands of small business Exchange servers compromised inside a week.
• 2021 again: ProxyShell (CVE-2021-34473 and friends). Same pattern, different bug class.
• 2022: ProxyNotShell (CVE-2022-41040 and 41082). Another emergency mitigation cycle.
• 2023-2024: a steady drumbeat of Exchange CVEs, several with public PoC inside hours of disclosure.
• 2026: CVE-2026-42897.

Every one of these required an Exchange admin (or an MSP managing one for a small business) to drop everything, validate mitigations, apply patches, and scan for compromise. The total cost in admin hours over five years, on a typical 25-user on-prem Exchange deployment, is now meaningfully more than the Microsoft 365 license cost would have been over the same period. And the operational risk is one-sided: every time the cycle repeats, the chance of being the small business that did not patch in time grows a little.

The realistic Exchange Online migration for a 5-to-50 mailbox business is a 2-to-4 week project. Provision Microsoft 365, set up the tenant identity (overlap with the identity hardening post), do a hybrid or cutover migration of mailboxes, retire the on-prem server. Net cost for a clean cutover is typically $3,000 to $8,000 in professional services for a small business, plus the ongoing per-user license. The thing it removes from your environment is a permanent emergency-patch obligation. Every time another Exchange zero-day drops, you read the headline and keep working.

If you want help with that conversation, that is exactly what we do for small businesses across Salinas, Monterey, Santa Cruz, and the rest of the Central Coast. The cloud services page covers the migration scope; the cybersecurity services page covers the program around it.

Where this fits with the rest of the week

This is the second emergency patching event in 48 hours. It pairs with:

• The May Patch Tuesday post from yesterday: 120 fixes, 17 critical, no zero-days at the time. CVE-2026-42897 is the zero-day that broke that streak the next morning.
• The Claude Mythos post on the patch-cadence shift: this is exactly the rate of disclosure I was describing.
• The identity hardening post: account takeover via OWA hits less hard in environments with phishing-resistant MFA and Conditional Access.
• The ransomware post: on-prem Exchange has been the entry point in a meaningful share of the small business ransomware cases I have written about.

The honest take is unchanged. Vulnerability management at the 2026 pace is an operations function, not a side duty. If you do not have someone whose job is to wake up to a Microsoft advisory and translate it into a punch list within the same day, that is the seat to fill. We do that for our clients and we are happy to do it for yours.

FAQs about CVE-2026-42897

Am I affected by CVE-2026-42897?

Only if you run on-premises Microsoft Exchange Server 2016, 2019, or Subscription Edition. Exchange Online (the mailboxes inside Microsoft 365) is not affected. If your business uses Microsoft 365 for email, you have nothing to do for this CVE. If you have an Exchange server in your office or co-location, you have work to do today.

Has Microsoft released a patch?

Not as of May 15, 2026. Microsoft has published a temporary mitigation that the Exchange Emergency Mitigation Service (EEMS) auto-applies on supported builds. EEMS is enabled by default. If yours is running, the mitigation has likely already been applied to your server. A permanent security update is in development. We will update this post when the patch ships.

How do I check if the Exchange Emergency Mitigation Service is running?

On the Exchange server, open the Services console and confirm "Microsoft Exchange Emergency Mitigation Service" is set to Automatic and is Running. From PowerShell, run Get-Service MSExchangeMitigation. To list applied mitigations, run Get-ExchangeServer | Format-List Name, MitigationsApplied. The CVE-2026-42897 mitigation should appear in the list once EEMS has retrieved and applied it.

What does an attacker get if they exploit this?

The flaw is a cross-site scripting bug in Outlook Web Access. An attacker who lands a successful exploit can execute JavaScript in the user's OWA browser session, which means they can read mail, send mail as that user, modify mailbox rules, exfiltrate contacts, and pivot from there. It is not direct remote code execution on the server. It is account takeover for any user who opens the malicious email in OWA.

Should I migrate off on-prem Exchange?

For most small businesses, yes. On-premises Exchange has been the source of multiple internet-wide zero-day events over the past five years (ProxyLogon, ProxyShell, ProxyNotShell, and now this). Each one has required emergency patching of an internet-reachable server, often on a weekend. The total cost of running Exchange on-prem, when you account for these emergency patch cycles, has been higher than Exchange Online for most SMBs for several years now. If on-prem Exchange is hosting fewer than 100 mailboxes for your business, the migration to Exchange Online is the project to plan.

Is there any sign of who is exploiting this?

Microsoft confirmed active exploitation but has not publicly attributed it to a specific named threat actor as of this writing. The historical pattern for on-prem Exchange zero-days is rapid adoption by both nation-state operators (initial disclosure phase) and ransomware affiliates (within weeks). Plan defenses for both.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501.