Microsoft Exchange CVE-2026-42897 OWA XSS Is Being Exploited

Microsoft has disclosed CVE-2026-42897, a critical Microsoft Exchange Server spoofing vulnerability that is already marked as exploited. The bug affects on-premises Exchange deployments and can be triggered when a user opens a specially crafted message in Outlook Web Access, under the interaction conditions described by Microsoft.^[1]

This is not a conventional Exchange remote-code-execution alert, and that distinction matters. Microsoft describes the root cause as cross-site scripting during web page generation: attacker-controlled JavaScript can run in the victim browser context, which puts OWA sessions, mailbox actions, and trusted webmail workflows in scope.^[1] If your organization still exposes OWA to the internet, treat the mitigation check as urgent rather than waiting for a normal security update cycle.

Cartoon showing Exchange OWA XSS mitigation with EEMS and EOMT — The permanent patch is still being tailored, so the emergency toolbox gets the first call.

Who is affected and what admins should check now

The affected list is narrow but important: Exchange Server Subscription Edition RTM, Exchange Server 2019 CU14/CU15, and Exchange Server 2016 CU23 are listed in Microsoft’s affected-product data, with CVSS 8.1 and “Exploitation Detected” status.^[1] Independent coverage also notes that Exchange Online is not affected by this specific on-premises OWA flaw.^[2]

Environment	Status to verify
Exchange Server SE RTM	Affected; verify emergency mitigation and watch for the permanent update.
Exchange Server 2019 CU14/CU15	Affected; Exchange 2019 fixes are expected through the eligible update/ESU path.
Exchange Server 2016 CU23	Affected; Microsoft lists customer action as required.
Exchange Online	Not listed as affected in public reporting on this CVE.

Microsoft says a full security update is still being developed and tested. In the meantime, the company is using the Exchange Emergency Mitigation Service, which is enabled by default on supported Exchange servers, to apply temporary protection automatically. Servers where EEMS was disabled, cannot reach Microsoft mitigation services, or are isolated from the internet need an explicit check. Microsoft also points admins to the Exchange On-premises Mitigation Tool (EOMT) path for environments that cannot rely on automatic mitigation.^[1]

For a first pass, confirm that every internet-facing Exchange server has received the CVE-2026-42897 mitigation, verify the Exchange build/CU level, and make sure OWA exposure is intentional. Then review IIS and OWA logs for unusual requests, suspicious mailbox activity, anomalous sign-ins, and users who opened unexpected messages shortly before odd account behavior. The attacker still needs a user to open the crafted email in OWA, but user interaction should not make defenders relaxed; browser-context execution can still abuse trusted sessions and user-visible mailbox actions.

This is also a good moment to revisit older Exchange incident lessons. Microsoft’s emergency mitigation model became familiar during the ProxyNotShell wave, and howtofix.guide previously covered both the Exchange emergency mitigation guidance and earlier Exchange zero-day exploitation. The common thread is simple: Exchange is too valuable to leave on “we think the mitigation ran.” Prove the mitigation state, record it, and keep the permanent patch task open until Microsoft ships the final update.

Because CVE-2026-42897 sits in OWA, defenders should also connect it to the wider session-abuse pattern seen in phishing and token-theft campaigns. An XSS bug is a different class of weakness than an AiTM phishing kit, but both can turn a trusted browser session into the useful object. Our earlier coverage of Microsoft’s AiTM phishing campaign warning is a useful reminder that mailbox and session telemetry deserve the same attention as server patch status.

The practical response is therefore short but strict: enable or re-enable EEMS where possible, run EOMT where automatic mitigation is not available, reduce unnecessary external OWA exposure, review admin and user activity, and prepare for the permanent Exchange update. Do not count a dashboard “seen” state as closure unless you can show the mitigation was applied on each relevant server.