19 May 2026 Vulnerability

CVE-2026-42897: Microsoft Exchange OWA Zero-Day Is Being Exploited With No Patch — What Australian Organisations Must Do Now

Microsoft disclosed a zero-day vulnerability in on-premise Exchange Server's Outlook Web Access interface on 14 May 2026. Tracked as CVE-2026-42897 and rated CVSS 8.1, the flaw is being actively exploited in the wild and was added to CISA's Known Exploited Vulnerabilities catalogue the following day. No patch has been released. Australian organisations running Exchange Server 2016, 2019, or Subscription Edition should apply Microsoft's temporary mitigations immediately — and those who haven't yet are currently exposed.

Disclosure: This post contains affiliate links. We only recommend tools we've researched and trust. If you purchase through our links, we may earn a commission at no extra cost to you.

What Microsoft Disclosed on 14 May 2026

On 14 May 2026, Microsoft published details of CVE-2026-42897, a vulnerability affecting the Outlook Web Access (OWA) component of on-premise Microsoft Exchange Server. The vulnerability is officially classified as a spoofing flaw with a cross-site scripting (XSS) mechanism, carrying a CVSS 3.1 score of 8.1. Unlike many vulnerability disclosures that are made prior to known exploitation, Microsoft confirmed from the outset that CVE-2026-42897 was already being actively exploited in the wild at the time of disclosure.

The following day, 15 May 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-42897 to its Known Exploited Vulnerabilities (KEV) catalogue, which tracks flaws with confirmed active exploitation. Under the binding operational directive that governs US federal agencies, civilian federal entities are required to remediate KEV-listed vulnerabilities by 29 May 2026. While that directive applies specifically to US federal agencies, inclusion in the KEV catalogue is a reliable signal that exploitation is real, widespread, and not theoretical.

As of the date of this article (19 May 2026), Microsoft has not released a permanent patch for CVE-2026-42897. The company has instead made two temporary mitigations available:

Exchange Emergency Mitigation Service (EM Service): An automatic mitigation that ships as part of Exchange Server 2016 CU23+, 2019 CU13+, and Exchange SE. When enabled (which it is by default in supported versions), the EM Service downloaded and applied a mitigation for CVE-2026-42897 automatically. Administrators should verify the service is running and that the mitigation has been applied.
Exchange On-premises Mitigation Tool (EOMT): A PowerShell script that organisations can download and run manually if the EM Service is not in use or if they want to confirm the mitigation state. Microsoft has updated the EOMT to address CVE-2026-42897 and recommends administrators run it as an additional verification step.

CVE-2026-42897 affects Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition. Exchange Online — the cloud version of Exchange used by Microsoft 365 subscribers — is not affected. Organisations that have fully migrated to Exchange Online have no exposure to this specific vulnerability.

Why This Matters for Australian Organisations Still on On-Premise Exchange

Exchange Online migration has been accelerating in Australia since Microsoft introduced commercial pressure to move away from on-premise licensing, but a substantial portion of Australian organisations have not completed that transition. Legal practices, medical clinics, accounting firms, local government councils, schools, universities, and professional services firms across Australia continue to operate Exchange Server 2016 or 2019 on their own hardware or in a hosted data centre. In many cases, this is a deliberate choice: data sovereignty concerns, regulatory requirements, integration dependencies, or simply budget constraints have kept on-prem Exchange in place.

The Australian Cyber Security Centre (ACSC) has published Exchange Server security best practices and issued specific guidance on strengthening Exchange deployments. That guidance reflects an ongoing operational reality: on-prem Exchange remains a significant part of the Australian IT landscape and continues to be a high-value target for threat actors. Exchange servers hold the organisation's email history, calendar data, contacts, and — through mail-enabled applications — transactional records, sensitive attachments, and communications with clients, suppliers, and regulators.

The Notifiable Data Breaches (NDB) scheme administered by the Office of the Australian Information Commissioner (OAIC) requires organisations with annual turnover above AUD 3 million (and all health service providers regardless of size) to report eligible breaches. An OWA compromise that gives an attacker access to employee email accounts would almost certainly trigger NDB obligations: email inboxes routinely contain personal information about customers, patients, and employees — names, contact details, financial information, health information — all categories covered by the Privacy Act 1988. A failure to notify within 30 days carries civil penalty exposure.

Beyond regulatory consequences, email account access is frequently the precursor to further compromise. An attacker with access to an executive's OWA account can intercept password reset emails, business email compromise (BEC) fraud attempts, supplier invoice notifications, and internal communications that reveal network topology or credential patterns. The initial XSS exploit in CVE-2026-42897 is the foot in the door; what happens next depends on what the attacker finds once they're inside.

How CVE-2026-42897 Works: Crafted Emails and OWA Session Hijacking

The attack chain

The vulnerability follows a client-side attack pattern that is common to web application XSS but unusual in the context of an email server. An attacker sends a specially crafted email to a target who uses Outlook Web Access to read their email. When the recipient opens the message in OWA through a browser, the crafted content triggers execution of attacker-controlled JavaScript in the context of the OWA domain. The "certain interaction conditions" Microsoft references in its advisory are the browser rendering of OWA combined with specific message structure — the exact details of which have not been fully disclosed to prevent immediate weaponisation.

What attackers can do with OWA JavaScript execution

Running JavaScript within the OWA domain gives an attacker significant capabilities, because the browser treats the script as originating from the Exchange server itself. Documented and expected consequences of this class of XSS include:

Session cookie theft: If OWA session cookies are not flagged as HttpOnly (a configuration that limits their accessibility to JavaScript), the attacker's script can exfiltrate the victim's session token to an external server. With that token, the attacker can authenticate to OWA as the victim from a different machine, with full access to email, contacts, and calendar.
Inbox rule creation: OWA's API is accessible from within a browser session. A malicious script can silently create inbox rules — for example, forwarding all emails matching certain criteria to an attacker-controlled address, or automatically deleting security alerts before the user sees them. This kind of rule persistence survives even after the initial email is deleted.
Credential harvesting via fake prompts: The spoofing dimension of the vulnerability means the injected JavaScript can display fake OWA login dialogs or MFA prompts that appear genuine, capturing credentials that the attacker then uses directly.
Pivoting via email-initiated actions: With session access, an attacker can send emails from the victim's account — impersonating them to finance teams to authorise wire transfers (BEC fraud), to IT staff to request password resets, or to external parties to conduct phishing on behalf of the victim's trusted identity.

Why the OWA attack surface is particularly sensitive

Exchange Server administrators sometimes restrict direct email client (MAPI/IMAP) access while leaving OWA exposed on the internet, reasoning that OWA's browser-based interface is lower-risk than full protocol access. CVE-2026-42897 demonstrates the flaw in that assumption: OWA is itself a web application with its own attack surface. The combination of email delivery (which attackers can do from anywhere) and a browser-side execution vector means that an attacker does not need network access to the Exchange server itself — they only need the target to open an email in a browser.

Immediate Actions: Applying Microsoft's Mitigations Before a Patch Arrives

Because no permanent patch exists for CVE-2026-42897, the priority is confirming that the available temporary mitigations are in place on every Exchange Server in your environment. Microsoft's official advisory on the Microsoft Community Hub should be your primary technical reference; the steps below are a summary of the current guidance.

Step 1 — Verify the Exchange Emergency Mitigation Service (EM Service) is running. On affected Exchange Server versions, open the Exchange Admin Center or run Get-ExchangeDiagnosticInfo -Server <ServerName> -Process EdgeTransport -Component EmergencyMitigation in Exchange Management Shell. The output should confirm the service is running and that a mitigation for CVE-2026-42897 has been applied. If the service is disabled — a configuration sometimes set by administrators who prefer manual control — re-enable it or apply the mitigation manually using the EOMT.

Step 2 — Download and run the updated Exchange On-premises Mitigation Tool (EOMT). Microsoft updated the EOMT to include the CVE-2026-42897 mitigation. Even if you believe the EM Service has applied the fix automatically, running EOMT provides an explicit confirmation and applies any mitigations that may have been missed. The EOMT is a signed PowerShell script available from Microsoft's GitHub repository; refer to the advisory link above for the current download path and run it with administrator privileges on each affected Exchange Server.

Step 3 — Review and restrict OWA access where feasible. If OWA is only used by employees connecting from known networks (office IP ranges, a corporate VPN), consider implementing IP allowlisting at the network perimeter or web application firewall level for OWA's path (/owa). This does not eliminate the vulnerability but significantly reduces the attacker's ability to deliver a crafted email to a target and then observe the JavaScript execution outcome in real time.

Step 4 — Enforce multi-factor authentication on OWA. MFA does not prevent the initial XSS execution (that happens when the email is opened, before authentication is relevant), but it does limit the attacker's ability to reuse a stolen session token from a separate device — because the Exchange server can be configured to require step-up authentication when a session appears to originate from a new device or IP. Check whether your Exchange deployment supports and has enabled MFA for OWA via Active Directory Federation Services, Azure AD application proxy, or a third-party identity provider.

Step 5 — Alert users about suspicious email behaviour. Brief OWA users (particularly executives and finance staff, who are highest-value BEC targets) to be alert to unexpected login prompts appearing while reading email, emails they did not send appearing in their Sent Items, and unexpected inbox rules. These are the observable signs of a successful exploit.

Step 6 — Monitor OWA audit logs. Exchange Server records OWA logon events and mailbox access in its audit log. Review logs for unusual access patterns — logons from unfamiliar geographic locations or IP addresses, after-hours access, or access immediately followed by large volumes of email reads or exports. The ACSC's guidance on Exchange Server hardening includes audit logging recommendations as part of its broader Exchange security best practices.

Longer-Term: Exchange Hardening and Whether On-Premise Is Still the Right Choice

CVE-2026-42897 is not Exchange Server's first serious vulnerability. The platform has accumulated a significant track record of high-severity flaws — ProxyLogon (2021, CVSS 9.8), ProxyShell (2021), ProxyNotShell (2022), and a succession of Exchange-specific issues that have appeared in every subsequent Patch Tuesday cycle. Each time, the pattern is the same: disclosure, active exploitation, mitigation, eventual patch. For organisations running on-prem Exchange, this pattern means a recurring obligation to respond urgently to each new disclosure.

Following ACSC's Essential Eight for patch management

The ACSC's Essential Eight framework lists "patch applications" and "patch operating systems" as two of the eight baseline mitigation strategies for Australian organisations. The framework recommends that internet-facing services — of which Exchange with OWA is a clear example — be patched within 48 hours of a critical vulnerability being disclosed. CVE-2026-42897 presents a complication: there is no patch to apply, only a mitigation. The spirit of the Essential Eight's urgency requirement still applies: the mitigation should be confirmed within 48 hours of disclosure, which means having a clear process for checking EM Service status and running EOMT when new Exchange advisories are published.

Hardening steps to reduce ongoing exposure

While waiting for a permanent patch, several hardening measures reduce the attack surface beyond the specific CVE-2026-42897 mitigations:

Disable OWA if unused. If your organisation does not rely on browser-based email access, OWA can be disabled at the virtual directory level without affecting Outlook clients or mobile device ActiveSync. This is the most effective defence against OWA-specific vulnerabilities.
Apply all available Cumulative Updates (CUs). Exchange Server's patch delivery model uses CUs that bundle security and feature changes. Running Exchange Server 2016 below CU23 or 2019 below CU13 means the EM Service is unavailable and the server may be missing years of security updates. Check your Exchange version against Microsoft's current supported CU list.
Restrict outbound connections from Exchange. A successful XSS exploit often relies on the victim's browser making outbound connections to attacker-controlled infrastructure to exfiltrate session tokens. Web proxy rules or endpoint firewall policies that limit what OWA's browser sessions can connect to externally can reduce the data exfiltration step of the attack.
Subscribe to the Microsoft Security Response Center (MSRC) advisory feed. The MSRC publishes new advisories as they are disclosed. An RSS subscription or email alert from the MSRC ensures you hear about new Exchange vulnerabilities at the same time as the security community, rather than days later when coverage reaches mainstream IT press.

Is it time to consider migrating to Exchange Online?

The frequency and severity of on-prem Exchange vulnerabilities is prompting many Australian organisations to reconsider whether the operational overhead of maintaining on-prem Exchange is justified. Exchange Online — Microsoft's cloud-hosted email service included in Microsoft 365 Business and Enterprise subscriptions — was not affected by CVE-2026-42897, and has not been the subject of the XSS-via-email attack pattern that characterises many recent Exchange Server flaws. Microsoft is responsible for patching Exchange Online, and customers have no mitigation steps to apply when new vulnerabilities emerge.

Migration carries its own costs and complexity, and is not always feasible — regulatory, sovereignty, and integration constraints sometimes require on-prem deployments. But for Australian SMBs running Exchange Server primarily for business email with no compelling on-prem requirement, the accumulating security maintenance burden of on-prem Exchange is a genuine consideration in the next licensing review cycle.