Exchange Server CVE-2026-42897, the OWA XSS session hijacking zero-day confirmed as actively exploited when Microsoft disclosed it on 15 May, enters its second week with no permanent patch available. The EEMS automatic mitigation — which applies a protective filter rule to Exchange Servers — remains the primary defensive measure for organisations that have not disabled OWA access.
This update covers what security teams should focus on in week two of the zero-day disclosure window.
Mitigation Status Check
The most important operational step is verifying that EEMS has correctly applied the protective rule to every Exchange Server in the environment.
Verification command (run on each Exchange Server):
Get-ExchangeDiagnosticInfo -Server $env:COMPUTERNAME -Process EdgeTransport -Component RuleUpdateStatus
The output should show RuleStatus: Active for the CVE-2026-42897 mitigation rule. If EEMS is disabled or the rule shows as NotApplicable or Failed, the server is unprotected.
For Exchange Servers where EEMS is disabled:
Set-ExchangeServer -Identity $env:COMPUTERNAME -MitigationsEnabled $true
Allow up to 30 minutes for the rule to be downloaded and applied after enabling EEMS.
For servers in network-isolated environments (no outbound HTTPS to Microsoft for EEMS): Apply the manual mitigation documented in the MSRC advisory — this involves a URL Rewrite rule applied to the OWA virtual directory in IIS.
Scope of Exploitation in Week One
Microsoft’s threat intelligence updates during the initial disclosure week confirmed active exploitation primarily by nation-state actors targeting government and financial services organisations. However, the session hijacking technique is not technically complex — any attacker who can send email to a target’s Exchange mailbox can attempt the attack if the target opens it in OWA.
The practical exploitation window was widest in the first 24–48 hours after disclosure on 15 May, when EEMS rules were not yet deployed to some servers. Servers that had EEMS disabled or that took time to download the rule may have been exposed during that window.
Retrospective Investigation Actions for Week Two
The threat hunt work from week one focused on identifying active exploitation. Week two’s focus should shift to retrospective investigation: determining whether exploitation occurred during the highest-risk window before EEMS applied.
Key investigation period: 15–17 May 2026 (disclosure date through EEMS rule widespread deployment).
Indicators to investigate retrospectively:
OWA session anomalies: Review IIS logs on Exchange Servers for the period 15–17 May. Look for sessions where:
- Multiple distinct IP addresses accessed the same OWA session within a short window
- A session was established from one IP address and subsequently used from a different country/ASN
- Unusually rapid OWA API calls within a session (bulk
FindItemorGetItemEWS calls) that don’t match the user’s normal behaviour
Inbox forwarding rules created during the window: The first action of many actors after gaining OWA access is to create a forwarding rule for persistent access to future emails, even if the stolen session expires.
Get-MailboxFolderPermission -Identity <user>:\Inbox | Where-Object {$_.AccessRights -ne "None"}
Get-InboxRule -Mailbox <user> | Select-Object Name, ForwardTo, RedirectTo, ForwardAsAttachmentTo | Where-Object {$_.ForwardTo -ne $null -or $_.RedirectTo -ne $null}
Run this for all C-suite, finance, legal, HR, and IT administration mailboxes — the accounts most likely to be primary targets.
Emails sent from OWA sessions during the window: Review sent items for emails the user did not send. Actors sometimes send lateral phishing emails from compromised accounts to extend access within the organisation.
Patch Timing
Microsoft has not communicated a specific patch release date for CVE-2026-42897. Given the active exploitation and the availability of the EEMS mitigation, it is likely that the patch will not be an out-of-band release but will instead be included in the next scheduled Patch Tuesday cycle (9 June 2026) or a security update released before it.
When the patch is available, apply it within 24 hours. The EEMS mitigation reduces exposure but is not a substitute for the patch — mitigations of this type address known exploitation patterns and may not cover all variants.
Share this article