Microsoft has confirmed active exploitation of CVE-2026-42897, a cross-site scripting (XSS) flaw in the Outlook Web Access (OWA) interface of on-premises Exchange Server. It carries a CVSS v3.1 score of 8.1 and Microsoft's own assessment flags it as “Exploitation Detected” — real attacks are already under way. The uncomfortable part is the trigger: a user simply has to open a crafted email in OWA for JavaScript to run inside their authenticated session.
The timeline explains why this matters now. Microsoft disclosed the flaw on 14 May 2026 and shipped the permanent security update on 9 June, as part of the June Patch Tuesday (MSRC advisory). CISA added it to the Known Exploited Vulnerabilities (KEV) catalogue and set a remediation deadline for federal agencies. Nearly a month passed between disclosure and patch, a window covered by an automatic mitigation worth understanding properly.
What CVE-2026-42897 actually is
Microsoft's catalogue lists it as a spoofing vulnerability, but the mechanism is an XSS: improper neutralisation of input during the generation of the OWA web page. The technical record sits in the NVD entry and in the Exchange team's own analysis.
The vector is a specially crafted email. When the victim opens it in Outlook Web Access and certain interaction conditions are met, the browser executes arbitrary JavaScript inside the user's authenticated session. The attacker needs no prior privileges or credentials: they ride on the legitimate session of whoever opens the message.
From there, the publicly described consequences include credential theft, session hijacking, email spoofing and actions carried out on behalf of the compromised user (BleepingComputer, SecurityWeek). What it does require is user interaction; it is not a fully automatic exploit that fires without the email being opened.
Why on-premises Exchange remains a priority target
The flaw affects Exchange Server 2016, 2019 and Subscription Edition across all update levels. Exchange Online (Microsoft 365) is not affected. That boundary matters: the problem lives in the infrastructure each organisation runs itself, not in Microsoft's managed service.
Many organisations run hybrid: they moved mail to Microsoft 365 but kept one or more on-premises Exchange servers for management, coexistence or legacy applications. That server usually retains elevated privileges over Active Directory, so compromising it is not an isolated mailbox incident but a potential bridgehead into the directory.
An Exchange server with OWA published to the internet is also an exposed, heavily scanned surface. Efforts such as Shadowserver's vulnerable Exchange server report show daily how many systems remain unpatched and reachable from outside.
Anatomy of the attack, without the recipe
It helps to understand the mechanism without turning it into a manual. The crafted email carries content that OWA fails to neutralise correctly when rendering it; once displayed in the browser, that content is interpreted as script and runs. There is no public proof of concept and no packet-level indicators published by Microsoft, so the description deliberately stays at the conceptual level.
The defensive point is where that script runs: in the already-authenticated OWA session. That gives it the ability to read and write mail, create mailbox rules for forwarding or hiding messages, and — in hybrid environments — attempt to pivot towards other services. The phrase “under certain conditions” is not decoration: the real reach depends on each deployment's configuration.
On attribution, the public information is honest about its limits: Microsoft observed exploitation at disclosure, but no specific group has been publicly linked and the campaign's scale has not been quantified (Help Net Security). Saying more would be speculation.
Why the usual controls are not enough
The first reflex — “I have MFA, I'm covered” — does not apply here. Multi-factor authentication protects the sign-in, but the abuse happens once the OWA session is already authenticated: the script executes inside it. Hardening identity is still necessary, but it does not neutralise this vector on its own.
Email filtering offers no guarantee either: a message engineered for this flaw can look entirely legitimate. And endpoint EDR has little visibility into what happens inside the browser session against the mail server. Effective defence shifts towards Exchange itself: patch, mitigation and reduced exposure.
Detection: what you can and cannot do
Be straight with the team: with no public PoC and no Microsoft IoCs, there is no magic signature. Detection rests on exposure surface, mitigation verification and behaviour monitoring. The Exchange team's documentation describes how to check the mitigation status.
- Inventory on-premises Exchange servers and their real OWA exposure to the internet, as part of continuous attack surface management.
- Verify that the automatic mitigation (EEMS) is applied, using the Exchange Health Checker or the “Viewing Applied Mitigations” guidance.
- Watch for suspicious mailbox rules, automatic forwarding and newly added delegations.
- Review anomalous OWA access: improbable geolocations, odd user agents, bursts of out-of-hours activity.
- Correlate IIS/OWA logs with mailbox telemetry in the SIEM to spot session abuse.
Keeping that watch running continuously is precisely the job of a managed SOC, which correlates these signals without relying on someone reading logs by hand.
Containment and practical defence
- Apply the June 2026 security update: Exchange Subscription Edition, 2019 (CU14/CU15) and 2016 (CU23). Legacy versions receive the patch through the Extended Security Updates (ESU) programme.
- Keep the Exchange Emergency Mitigation service (EEMS) enabled — it is on by default — and confirm that mitigation M2.1.x is active. Microsoft advises not disabling it after installing the patch.
- Reduce OWA exposure: restrict internet access, publish it behind a reverse proxy or Zero Trust access (ZTNA), and apply geofiltering where it makes sense.
- Harden identity with phishing-resistant MFA (FIDO2/passkeys) and review existing mailbox rules, forwarding and delegations for unauthorised changes.
- Reassess the on-premises server's role in Active Directory, segment the network and enforce least privilege to limit lateral movement if a session is compromised.
- Consider decommissioning or migrating on-premises Exchange where viable: every zero-day is a reminder that a surface which no longer exists cannot be exploited.
Prioritising flaws like this — a CVE on the KEV catalogue, with confirmed exploitation — is exactly what a vulnerability management practice that goes beyond running a scanner is for. Frameworks such as KEV, EPSS and SSVC help order that priority.
If signs of compromise appear — strange mailbox rules, exfiltration, impossible logins — activate incident response quickly and preserve evidence before touching the server.
Compliance implications: NIS2, DORA and ENS
For an entity within scope of NIS2, an exposed and unpatched on-premises Exchange is a critical asset carrying a known exploited vulnerability. That triggers vulnerability-management obligations and, where an incident has impact, the notification timelines.
Under DORA, digital operational resilience requires patch-management and ICT risk-control processes that cover exactly these scenarios. And under Spain's ENS framework, update control and exposure management are part of the baseline according to the system's category.
There is a practical nuance: documenting the patch date and the mitigation status is not bureaucracy — it is the evidence that holds up in an audit and that demonstrates diligence if the incident is later reviewed.
What to prioritise now
No three-month plans or endless projects: the urgent work is concrete. Confirm which on-premises Exchange servers exist and which publish OWA, apply the June update, verify that the EEMS mitigation is active, and watch mailboxes for unauthorised rules and forwarding. That closes the immediate exposure; the deeper conversation — how much on-premises Exchange still makes sense — comes afterwards.
For environments where most mail already lives in the cloud, reviewing the combined posture helps: we cover it in Microsoft 365 security, and in related pieces such as Microsoft 365 account takeover and device-code phishing.
For many organisations, on-premises Exchange is technical debt with a security invoice attached. CVE-2026-42897 is neither the first reminder nor the last: while OWA stays published and unmigrated, the question is not whether another flaw will appear, but whether the server will be patched and monitored when it does.