2026-05-18 · view entry permalink →
CVE-2026-42897 Exchange OWA, EM Service auto-mitigation depends on outbound connectivity to officemitigations.microsoft.com
UPDATE (originally covered 2026-05-15 / deep-dive 2026-05-16): The Microsoft Exchange Team Blog post addressing CVE-2026-42897 was last modified 2026-05-17 to clarify an operational dependency that defenders must verify on every Exchange Mailbox host: the Exchange Emergency Mitigation Service (EM Service / EEMS) (which auto-applies the URL-Rewrite mitigation labelled M2.1.x) only delivers that mitigation when it can reach officemitigations.microsoft.com over outbound HTTPS. Segmented on-premises Exchange 2016 / 2019 / Subscription-Edition deployments that block direct outbound HTTPS from the Mailbox role will therefore not have received the automatic mitigation and remain exposed to the actively-exploited OWA stored-XSS chain.
The CVE remains CISA KEV-listed (added 2026-05-15) with no permanent cumulative-update fix as of 2026-05-18; Microsoft states verbatim "We are working on developing and testing a more permanent fix which we will provide when it meets our quality standards." Exchange Online is unaffected. Operational verification per server: Get-ExchangeDiagnosticInfo -Server <server> -Process EdgeTransport -Component EmergencyMitigation returns Status: Active and rule M2.1.x applied; manual application on hosts that cannot reach the mitigation service: .\EOMT.ps1 -CVE "CVE-2026-42897" from an elevated Exchange Management Shell, or apply the documented URL Rewrite rule by hand.
The Exchange Emergency Mitigation Service will provide mitigation automatically, and is on by default. If it is not already enabled on your Exchange Server, you need to enable Exchange Emergency Mitigation Service.
We are working on developing and testing a more permanent fix which we will provide when it meets our quality standards.
The messages exploit CVE-2026-42897, a vulnerability in Outlook Web Access in which the server does not adequately sanitize HTML in the message body. This allows a loader piece of JavaScript to use the onload= event handler to parse the rest of the message body, assemble a Base64 fragment, and execute it as encoded JavaScript.
This persistent access lives on the server-side and requires deliberate removal from the Exchange server; credential rotation and even full re-imaging of the targeted user's device will not evict the actor.
Installing the July 2026 update does not automatically remove already applied CVE-2026-42897 mitigations.
The May entry tracked CVE-2026-42897 as an Exchange OWA flaw whose interim protection depended on the EM Service auto-mitigation. Two things changed. Proofpoint has now attributed in-the-wild exploitation to a named Russian state-supported actor and published the implant's full mechanics (Proofpoint, 2026-07-29), and the mitigation is no longer the remediation; the July 2026 Security Update is, with the mitigation now something that must be actively torn down (Microsoft Exchange Team Blog, 2026-07-14). NCSC-CH appended the Proofpoint reporting to its own advisory on 2026-07-30 (NCSC Switzerland, 2026-07-30).
The actor is TA488, which Microsoft tracks as Void Blizzard and which this pipeline registers as LAUNDRY BEAR, the same Russian state-supported email-espionage actor a 16-nation joint advisory exposed on 2026-07-23 for its Zimbra campaign. Proofpoint assesses OWAReaper as an evolution of that campaign's ZimReaper payload, citing shared code including an identical invisible-element sizing and error-handling pattern (Proofpoint, 2026-07-29). Campaign activity began 2026-07-22 against government, telecommunications, finance, hospitality and aerospace targets across the US and Europe, using deliberately banal lure subjects with no call to action, Proofpoint reads the unusual breadth as intentional blending with bulk mail. Its stated infrastructure-creation date of March 2026 precedes Microsoft's May disclosure by two months, which is the basis for its assessment that zero-day use is feasible; that is an inference from infrastructure dating, not a confirmed finding.
Execution. The flaw is a failure to sanitise HTML in the message body, so a loader script in an onload= handler reassembles a Base64 fragment from the rest of the message and evaluates it, no link click and no attachment open, only viewing the message in OWA. The exploit and payload fragments are hidden inside the message's social-media icon elements, with next-stage data placed after # fragment markers where the browser's Base64 image parser stops reading, so the payload is not visible to casual inspection of the HTML. On execution OWAReaper first rewrites the delivered message server-side to strip the exploit content and suppresses OWA pop-ups and right-click, then enumerates the victim's address, username and settings.
Credential and token theft. It creates two invisible input elements and waits for the browser's own autofill to populate them with the saved OWA username and password. Separately it enumerates installed Outlook add-ins holding ReadWriteMailbox permission and, where one exists, abuses it to call GetClientAccessToken and obtain OAuth tokens.
Persistence, in three independent layers. Client-side, the implant writes an AES-encrypted copy of itself and a decryption wrapper into browser localStorage under a settings field of the legitimate PageDataPayload.OwaUserDefaultSettings key, which OWA itself evaluates during its own sync-restore flow, so every ordinary OWA tab-open re-launches it with no separate loader. A second client-side layer adds a hidden iframe to messages cached in OWA's offline IndexedDB store, so opening the cached message re-infects an endpoint even after a full re-image. The third is server-side and is the one that matters most: the implant calls UpdateFolder to grant Owner-level permission on every mail folder to the low-privilege "Default" preset alias that exists in every Exchange organisation. Proofpoint is explicit that this "requires deliberate removal from the Exchange server" and that credential rotation and re-imaging will not evict it.
Command and control. Two channels, both over infrastructure defenders generally trust. The implant polls GitHub's public Commit Search API every 24 hours for crafted commit messages containing the target's own email address, decrypting matches to a four-character command header that selects toolkit replacement, C2-domain rotation, or one-off code execution; in parallel it re-parses cached inbound messages every five minutes for the same command structure. Exfiltration runs primarily over HTTPS with encrypted URI paths, either relayed through a set of legitimate image-CDN domains or sent directly to the actor-controlled server when those proxies fail; if the HTTPS method fails altogether, the implant switches to DNS label tunnelling, packing the data into the subdomain labels of ordinary DNS queries for an actor-controlled domain. Notably, Proofpoint states there is no mass mailbox exfiltration here, unlike the Zimbra campaign, which is why this entry maps browser-session and credential-access behaviour rather than bulk email collection.
Patching. The permanent fix is the July 2026 Security Update, available as Exchange SE RTM publicly and for Exchange 2019 CU14/CU15 and Exchange 2016 CU23 only through the Period 2 Extended Security Update programme; organisations that were enrolled only in Period 1, which ended in April 2026, do not receive it (Microsoft Exchange Team Blog, 2026-07-14). Microsoft's own vulnerability record scores the flaw 8.1 and marks it exploited (Microsoft Security Response Center, 2026-07-14). Installing the update does not remove a previously applied mitigation: administrators who used the EM Service must remove the M2.1.0 IIS rules through the documented rollback, and those who ran the downloadable mitigation script must run its rollback. The known operational side effects of the mitigation era (broken OWA calendar printing, inline-image rendering problems, OWA-light failing, and false-unhealthy calendar-proxy health alerts) only clear once both steps are done, so a server left on mitigation-only status keeps them indefinitely (Microsoft Exchange Team Blog, 2026-05-14).
Detection. The highest-value signal is in mailbox audit and Exchange Web Services telemetry: a folder-permission change granting Owner rights to the "Default" alias, applied across many folders of one mailbox in quick succession. Client-side, monitor for writes to the OWA user-default-settings localStorage key outside the browser's own sync flow, and for OWA sessions in which invisible form inputs are created and immediately populated. On the network side, two egress patterns stand out from a mail client's normal behaviour: repeated polling of a public source-code hosting search API on a roughly daily cadence, and DNS queries with the label-length and entropy profile of tunnelled data.
Triage: OWA legitimately reads and writes its own settings keys constantly, so the presence of localStorage activity is not the signal; the discriminator is the specific settings-field path carrying an encrypted blob, and its correlation with a message open. For the server-side artifact the discrimination is cleaner: administrators do grant folder permissions, but they grant them to named users or groups for a specific folder, not Owner rights to the built-in "Default" alias across an entire mailbox. Treat any such grant as compromise until proven otherwise.
This entry now carries a source-reliability rating, which it predates: A1 on the NATO Admiralty scale. The letter reflects Microsoft's own advisory for its own product, the number reflects independent corroboration, since Proofpoint analysed the implant separately from Microsoft's disclosure and NCSC-CH restated that analysis for its own constituency. Nothing in the assessment or the remediation guidance changes; the rating makes explicit what the sourcing already supported.
Builds on: 2026-07-24/laundry-bear-zimbra-zero-click-cve-2025-66376