The Exchange Incident You Thought You Closed Is Probably Still Open
Where the Standard Advisory Guidance Falls Short
The standard advisory guidance is consistent across every source published since May 14: enable EEMS, await the permanent patch. That guidance is accurate. It is also incomplete in three specific ways that matter operationally.
EEMS blocks future exploitation. It does not address what happened before it was applied. CISA added CVE-2026-42897 to the Known Exploited Vulnerabilities catalog on May 15, the day after public disclosure, confirming exploitation was active at or before that disclosure date (CISA 2026; Microsoft Tech Community 2026b). Every environment carries a pre-mitigation exposure window. Enabling the mitigation does not close it.
EEMS does not protect all users. Clients running Internet Explorer, or Edge in Internet Explorer Mode, do not support the Content Security Policy component of the mitigation. Those users remain exposed after EEMS shows as applied (Microsoft Tech Community 2026a). If any part of the user base runs these clients, mitigation coverage is partial.
EEMS applied does not always mean EEMS active. At least one production environment recorded a duplicate entry written to owa/web.config by EEMS, which caused IIS to reject the configuration entirely. OWA went offline. The Health Checker reported "Applied." The rewrite rule was not active (Frankys Web 2026). The gap between reported status and actual protection state is not an edge case worth ignoring.
The correct response sequence runs in the opposite direction from what most teams are following: retrospective audit first, mitigation verification second, patch path determination third.
Three Response Failures and What to Do About Them
1. The Pre-Mitigation Exposure Window Is Not Being Investigated
The CISA KEV designation within 24 hours of disclosure is an operational signal: exploitation was already underway before the advisory was public (CISA 2026). Any user who opened a crafted email in OWA before EEMS was applied in their specific environment may have had their session compromised during that window.
This persists for a structural reason. Every advisory frames EEMS as a mitigation, and security teams treat mitigation as resolution. The persistence mechanism is not prominently surfaced in Microsoft's own communications. Forwarding rules created before EEMS was applied continue operating silently until removed (Byteiota 2026). Forwarding rule creation is a confirmed post-exploitation mechanism following OWA session compromise (1337skills 2026). If a mailbox has been forwarding to an external address since May 14, that forwarding continues today.
The mailbox rule audit is the first action, not an optional hygiene step. Cover the period from approximately May 10 to the date EEMS was applied in the specific environment. Scope all mailboxes. Filter on external forwarding and redirect rules, and check creation timestamps.
Get-Mailbox -ResultSize Unlimited | Get-InboxRule | Where-Object {$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo}
In organisations with large mailbox counts, reviewing the results requires human judgement and resourcing, not just running the command.
2. ESU Eligibility Determines Whether a Permanent Patch Exists in Your Environment
Media coverage universally states the permanent patch is coming. That is accurate for some organisations. The permanent patch for Exchange Server 2016 and 2019 will be delivered only through the Extended Security Update programme, specifically Period 2. Period 1 ESU ended in April 2026 (Microsoft Tech Community 2026b). Organisations that did not enrol in Period 2 before that deadline will not receive the permanent patch through any standard channel.
This is documented in the advisory update notes, not in the headline advisory itself. Security managers planning a patch rollout may be planning for a patch that will not arrive in their environment.
Three distinct populations exist, each with a different decision path:
Exchange SE: permanent patch available through the standard update channel. Apply when released.
Exchange 2016 or 2019, Period 2 ESU enrolled: permanent patch available. Verify ESU enrolment status now and confirm the update channel is functional.
Exchange 2016 or 2019, not enrolled in Period 2 ESU, or enrolled in Period 1 only: no permanent patch path exists through standard channels. A decision is required now.
Determine which population applies before planning anything else. For organisations in the third population, the options are: pursue emergency ESU enrolment directly with Microsoft, migrate to Exchange SE or Exchange Online before the next disclosure, or formally document residual risk with compensating controls for board-level sign-off. Migration under time pressure carries its own operational risk and is not a trivial alternative.
3. EEMS Verification Cannot Be Taken at Face Value
Running the Health Checker script and seeing "Applied" is the standard verification step. It is necessary. It is not sufficient. Two documented failure modes undermine confidence in that output in specific environments, and both appear only in Microsoft's comment update threads and practitioner-level technical reports, not in the main advisory or media coverage.
Failure Mode A: EEMS deploys a Content Security Policy header as part of the mitigation. Internet Explorer does not support Content Security Policy. Microsoft Edge running in Internet Explorer Compatibility Mode does not support it either (Microsoft Tech Community 2026a). In organisations with browser compatibility requirements that mandate IE-Mode, a subset of OWA users remains exposed despite EEMS showing as applied. Regulated industries and local government environments with legacy application dependencies frequently operate under IE-Mode requirements. This is not a theoretical edge case.
Failure Mode B: At least one production environment experienced EEMS writing a duplicate entry to owa/web.config. IIS rejected the configuration. OWA became non-functional. The Health Checker still returned "Applied." The rewrite rule was not active (Frankys Web 2026). This failure mode is not detectable from the Health Checker output alone.
Verification requires two steps, not one. Run the Health Checker. Then independently test OWA functionality from a standard browser and, if IE-Mode is in use, from an IE-Mode client. Confirm the IIS rewrite rule is active by checking owa/web.config directly for duplicate entries. If a duplicate entry is present, remove it manually and restart IIS before re-running the Health Checker.
Response Sequence: What to Do, in Order
The following distils the three failure points above into a sequenced checklist, ordered by urgency. The analysis behind each step is in the preceding section; this section is designed to be acted on.
As Soon as Practical
Determine which ESU population applies to the environment before scheduling any patch rollout. This check takes minutes and changes every subsequent decision.
Conduct a mailbox forwarding rule audit for the period from approximately 10 May through the date EEMS was applied. Scope all mailboxes and identify any external forwarding or redirect rules, filtering results based on the rule creation timestamp.
In environments with large mailbox counts, reviewing the results requires human judgement and resourcing.
Verify EEMS using the Health Checker, then independently confirm OWA is functional. Test from a standard browser and, if IE-Mode is in use, from an IE-Mode client. Check owa/web.config directly for duplicate IIS rewrite entries. If one is present, remove it manually and restart IIS before re-running the Health Checker.
For Exchange servers without connectivity to Microsoft's Office Configuration Service, EEMS cannot download automatically (Hive Security 2026). Deploy the mitigation manually using the Exchange On-premises Mitigation Tool on each affected server. This requires per-server execution.
Preserve IIS logs covering the pre-mitigation window from approximately May 10 to the date EEMS was applied. These are the only forensic record of whether malicious emails were delivered and whether OWA sessions interacted with them. Preserve them explicitly before any system changes are made.
Before the Patch Release
Organisations without a permanent patch path must prepare board-level residual risk documentation before June 10. When the patch ships and the environment does not receive it, the absence of documentation becomes an audit and governance problem. That documentation must address the compensating controls in place, the reason a permanent patch is unavailable, and the decision made about the path forward.
Where business processes allow, restrict OWA access to internal network addresses only. This eliminates the external delivery vector. Many organisations expose OWA externally for legitimate remote access; this control is not universally applicable, and that constraint should be assessed directly rather than assumed away.
Establish ongoing monitoring for new mailbox forwarding rules. This is a detection control, not a prevention control, and it requires a defined review process rather than a technical alert alone. The retrospective audit addresses the exposure window. This addresses what follows.
Is the Incident Actually Closed?
Three questions determine whether the response to CVE-2026-42897 is complete.
Has EEMS been verified as functionally active, not just confirmed as "Applied" in the Health Checker output (Microsoft Tech Community 2026a)? Has the organisation confirmed which ESU population it belongs to, and therefore whether a permanent patch will actually be delivered to its environment (Microsoft Tech Community 2026b)? Knowing the patch is coming is not the same as knowing it is coming to you. Has a retrospective mailbox rule audit been completed, covering approximately May 10 to the date EEMS was applied, for all mailboxes (Byteiota 2026)? EEMS stops the next attack. The mailbox audit finds the last one.
If the answer to any of these questions is "no" or "unknown," the response is not complete. The residual risk posture is unresolved.
There is a material difference between "we applied the mitigation" and "we have closed the exposure." The first describes a process step. The second describes an outcome. A security manager who conflates them in a leadership briefing is misrepresenting the organisation's actual risk posture.
Forward Risk
The June 10 patch release resolves the exposure for organisations on a patch path. Apply it immediately upon release and do not defer it into a standard review cycle (Byteiota 2026). A confirmed exploitation history removes any defensible case for deferral under the Essential Eight Patch Applications control at Maturity Level 2 or above (Australian Signals Directorate 2023). For organisations without Period 2 ESU enrolment, nothing that ships on June 10 changes their position (Microsoft Tech Community 2026b).
Exchange has a documented pattern of renewed scanning activity in the weeks following major disclosures. ProxyLogon was exploited en masse in March 2021 and ProxyShell exploitation accelerated in August 2021 (Rapid7 2021). F5 Labs honeynet data recorded a sharp increase in ProxyShell scanning as recently as April 2026, confirming the follow-on pattern persists for older vulnerabilities (F5 Labs 2026). Organisations that have not yet verified mitigation status or completed the retrospective mailbox audit are operating in an active risk window.
Attribution for current CVE-2026-42897 exploitation remains unconfirmed. The observed tactics are consistent with both targeted operations and opportunistic activity (Rescana 2026). Monitoring threat intelligence feeds for CVE-2026-42897-specific indicators of compromise is the most actionable forward step once immediate response is complete (1337skills 2026). If attribution is confirmed to an actor with a documented history in a specific sector, organisations in that sector should treat their exposure as active regardless of mitigation status.
The ESU eligibility gap is not a CVE-2026-42897 problem. It is a programme management problem. Organisations without a patch path for this incident are without a patch path for the next one.
Special thanks to Coursera for supporting today’s content.
Brought to by the CyOps Consulting Team.
CVE-2026-42897 is a cross-site scripting vulnerability in Outlook Web Access. Opening a crafted email in OWA triggers JavaScript in the context of the authenticated session. That JavaScript can create inbox rules, including forwarding rules that copy all incoming mail to an external address, without any further user interaction. The session token, not the password, is what the attacker needs. A password reset after exploitation leaves the forwarding rule intact.
Security In Practice | CyOps Consulting Team
An email forwarding rule planted in a mailbox before May 14 may still be running today. EEMS stops new exploitation; it does not remove persistence mechanisms already in place (Byteiota 2026). Exploitation was confirmed at or before public disclosure, with CISA adding CVE-2026-42897 to the Known Exploited Vulnerabilities Catalog on May 15, one day after disclosure (CISA 2026). That timing materially affects incident response priorities.
If the affected user has already reset their password, the forwarding rule does not care. It continues operating silently until someone finds it and removes it (Fortbridge 2026).
This article is intended for teams that have reviewed the advisory, applied the mitigation, and closed the associated ticket. There are three aspects of that process that warrant further review. Before addressing those items however, a brief refresher for those who may not have read the advisory:
Effective cybersecurity isn't built on the latest tools. It's built on principles. This guide cuts through the noise to show you how seasoned professionals think, plan, and lead in an environment where the threat landscape shifts daily.
Authored by Alec Sklepic, a CISSP-certified cybersecurity advisor, ISO/IEC 27001 Lead Auditor, and ASD-endorsed IRAP Assessor with more than 25 years' experience advising government and defence organisations, including the ASD, this book delivers practical, real-world guidance you can apply from day one.
Whether you're stepping into a leadership role or sharpening your strategic edge, this is the resource you'll return to. Secure your copy today and start leading with confidence.
Essential Eight Relevance
For Australian organisations operating under the Essential Eight framework, CVE-2026-42897 is not just a patching incident — it is a live test of two specific controls.
This incident is a direct test of application patching maturity for internet-facing services. The Australian Signals Directorate Essential Eight Patch Applications control at Maturity Level 3 requires internet-facing services to be patched within 48 hours of a patch becoming available (Australian Signals Directorate 2023). The ESU eligibility gap exposes a structural failure in that model: the 48-hour clock cannot start if the patch is never delivered to the environment. Organisations that assumed patch availability without verifying ESU eligibility have a gap in their patching programme that predates this incident.
The Restrict Administrative Privileges control applies directly to the scope of this incident. Delegated mailbox access and shared executive mailbox access amplify the consequence of a compromised OWA session (Fortbridge 2026). A forwarding rule planted on a delegated mailbox, or one accessible to multiple users, expands the scope of exfiltration beyond a single account. Review delegated mailbox access as part of the incident scope, not as a separate hygiene exercise.
References
Australian Signals Directorate. 2023. "Essential Eight Maturity Model." Australian Cyber Security Centre. https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight/essential-eight-maturity-model.
Byteiota. 2026. "Exchange Zero-Day CVE-2026-42897: One Email Owns Your OWA." May 2026. https://byteiota.com/exchange-zero-day-cve-2026-42897-owa-mitigation/.
CISA (Cybersecurity and Infrastructure Security Agency). 2026. "Known Exploited Vulnerabilities Catalog." May 15, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog.
F5 Labs. 2026. "Microsoft Exchange ProxyShell Scanning Doubles in April 2026 as Two Distinct Campaign Clusters Emerge." April 2026. https://www.f5.com/labs/articles/microsoft-exchange-proxyshell-scanning-doubles-in-april-2026-as-two-distinct-campaign-clusters.
Fortbridge (Bogdan Tiron). 2026. Analysis cited in TechTimes. "Exchange Server OWA Zero-Day CVE-2026-42897 Exploited With No Permanent Patch and New Mitigation Gaps." May 19, 2026. https://www.techtimes.com/articles/316860/20260519/exchange-server-owa-zero-day-cve-2026-42897-exploited-no-permanent-patch-new-mitigation-gaps.htm.
Frankys Web. 2026. "CVE-2026-42897 EEMS Production Deployment Incident." May 2026. https://www.frankysweb.de/en/vulnerability-in-exchange-owa-cve-2026-42897-may-2026/
Hive Security. 2026. "Exchange Server Zero-Day Executes JavaScript Through Your Inbox." May 2026. https://hivesecurity.gitlab.io/blog/cve-2026-42897-exchange-server-owa-xss-zero-day/.
1337skills. 2026. "Microsoft Exchange CVE-2026-42897: Unpatched OWA Zero-Day Under Active Exploitation." May 16, 2026. https://1337skills.com/blog/2026-05-16-microsoft-exchange-cve-2026-42897-owa-zero-day-xss/.
Microsoft Tech Community. 2026a. "Released: May 2026 Exchange Server Security Updates." May 14, 2026 update note. https://techcommunity.microsoft.com.
Microsoft Tech Community. 2026b. "Addressing Exchange Server May 2026 vulnerability CVE-2026-42897." May 2026. https://techcommunity.microsoft.com/blog/exchange/addressing-exchange-server-may-2026-vulnerability-cve-2026-42897/4518498.
Rapid7. 2021. "ProxyShell: More Widespread Exploitation of Microsoft Exchange Servers." Rapid7 Blog. August 12, 2021. https://www.rapid7.com/blog/post/2021/08/12/proxyshell-more-widespread-exploitation-of-microsoft-exchange-servers/.
Rescana. 2026. "CVE-2026-42897 Zero-Day Analysis: Microsoft Exchange Server OWA XSS Vulnerability Exploited in the Wild." May 2026. https://www.rescana.com/post/cve-2026-42897-zero-day-analysis-microsoft-exchange-server-owa-xss-vulnerability-exploited-in-the-wild.
CyOps Consulting – Trusted Advice. Proven Expertise. Practical Solutions.
Get in touch today to strengthen your cyber security posture with confidence.
© 2026 CyOps Consulting. All rights reserved.