New Zero-Day on Microsoft Exchange: Just one email can steal an entire OWA login session.
Risk summary
Recently, a particularly severe vulnerability was discovered, causing significant concern within the security community. Just a single carefully crafted email is enough to execute malicious JavaScript directly in the browser of Microsoft Exchange On-Prem users. Alarmingly, this vulnerability was exploited in the wild before many organizations realized they were at risk. However, the most notable issue isn't the potential to hijack an Outlook Web Access (OWA) session. The real problem is that even Microsoft's official security check tool is "overlooking" the system's protection status. Health Checker might report that the server is secure while the mitigation isn't functioning properly—creating an extremely dangerous false sense of security for administrators.
Background and history of the attack
Microsoft Exchange On-Premises has long been a key target for APT and ransomware operators because it is considered a central enterprise email system, often exposed to the Internet via OWA/ECP, and contains credentials and sensitive data. This is not the first time Microsoft Exchange On-Premises has been actively exploited; in the past, there have been numerous high-risk campaigns recorded.
Campaign | Year recorded | CVE | Affected version | Type of vulnerability |
ProxyLogon | 2021 | CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 | Microsoft Exchange Server 2013–2019 | Remote code execution (RCE) via unauthenticated access |
ProxyShell | 2021 | CVE-2021-34473, CVE-2021-34523, CVE-2021-31207 | Microsoft Exchange Server (on-premises) | Remote code execution (RCE) via unauthenticated access |
OWASSRF | 2022 | CVE-2022-41040 and CVE-2022-41082 | Microsoft Exchange Server 2013, 2016, 2019 | Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE) |
CVE-2026-42897 continues to highlight the current cybersecurity reality that Exchange On-Premises remains a significant attack surface. The OWA browser context is an attractive target, and email-based exploitation is still effective despite the presence of many modern defense layers. Unlike ProxyLogon/ProxyShell, which focus on server-side RCE, CVE-2026-42897 exploits client-side browser execution, session hijacking, identity abuse, and browser trust exploitation.
Information vulnerability
| Attribute | Value |
|---|---|
| CVE | CVE-2026-42897 |
| Severity | High |
| CVSS | 8.1 |
| CWE | CWE-79 – Cross-Site Scripting |
| Affected Component | Outlook Web Access (OWA) |
| Affected Products | Exchange Server 2016 / 2019 / SE |
| Attack Vector | Network |
| User Interaction | Required |
| Exploitation | Confirmed In-The-Wild |
Event timeline
| Event timeline | Event |
|---|---|
| 14/05/2026 | Microsoft announces CVE-2026-42897 |
| 14/05/2026 | Confirmed active exploitation |
| 15/05/2026 | The Hacker News and several security firms issued warnings. |
| 15–17/05/2026 | Microsoft released a temporary mitigation through EEMS. |
| Hiện tại | Currently, there is no complete permanent security patch available. |
Technical mechanism
Exploitation conditions
To successfully carry out the campaign, the attacker first sends a crafted email, then the user opens the email using OWA, and the JavaScript payload executes in the browser context. The attacker's payload can: read the DOM, send requests on behalf of the user, steal tokens, and perform spoofing actions.
Related Architecture and Root Cause
To understand why CVE-2026-42897 is dangerous even though it is not a traditional Remote Code Execution (RCE) vulnerability, we need to look at how Microsoft Exchange On-Premise handles email through Outlook Web Access (OWA).
In the typical operation model, users access OWA via a web browser. The request goes through IIS and the Exchange Frontend before connecting to the Mailbox Service to retrieve email content. Then, the OWA Rendering Engine converts the email into HTML content and returns it for the user's browser to display.
The issue with CVE-2026-42897 lies precisely in this content rendering step. When an email containing HTML is sent to the Exchange system, OWA parses the MIME content, reconstructs the HTML content, and renders it directly in the browser. By design, HTML email is considered valid "rich content" to support a modern webmail experience. However, the input data sanitization process did not completely remove dangerous elements controlled by the attacker. This creates a Stored XSS within the context of OWA.
In other words, the attacker doesn't need to exploit the operating system or execute code on the Exchange server. Instead, they just need to send a crafted email containing specially designed HTML/JavaScript payload. When the victim opens the email using OWA, the browser will render this content as a legitimate part of the Exchange webpage, and the malicious JavaScript will execute directly within the user's session.
This means the malicious script will run under the same origin as OWA, for example:
When the browser trusts this origin, JavaScript can perform a range of dangerous actions such as reading the DOM, sending requests on behalf of the user, manipulating the mailbox, creating mailbox rules, or stealing session/authentication tokens. This is why CVE-2026-42897, although "just" an XSS, has an impact very close to a complete account compromise.
Detailed technique
To successfully exploit this vulnerability, the attacker needs to go through four different stages, from reconnaissance to extracting critical data, with each stage serving as a stepping stone for subsequent attacks.
Stage 1 – The attacker sends a crafted email
The first step of the attack chain is extremely simple. The attacker just needs to send an email containing a specially crafted HTML or JavaScript payload to an internal user.
Stage 2 – Exchange processes the email
When the email reaches the mailbox, Exchange performs several steps: saving the email to the database, parsing the MIME structure, converting the email into web content, and rendering it in OWA. As mentioned, this process is the root cause of the vulnerability. OWA believes the HTML email is "valid rich content," so it tries to retain as much formatting as possible to give users an experience similar to Outlook desktop. However, during the HTML rebuild, some attacker-controlled content is not completely removed. Simply put, when the attacker sends "spoofed HTML," OWA inadvertently turns it into "valid HTML," and the browser executes it as trusted content. This technique is known as Stored XSS.
Stage 3 – The user opens the email using OWA
As soon as the victim logs into https://mail.company.com/owa/ and opens the malicious email, the browser will render the email content directly within the OWA website. The crucial point here is that the browser trusts mail.company.com since it is the legitimate company website. Because the JavaScript is executed under the same origin as OWA, the attacker can read the mailbox content, send authenticated requests, access the current session, and manipulate the mailbox on behalf of the user.
Stage 4 – JavaScript begins to operate
Once the payload runs successfully, the attacker can perform many dangerous actions right within the victim's browser session. For example, they can: read emails, send internal emails, create mailbox forwarding rules, steal authentication tokens, automatically conduct internal phishing, or even more dangerously, download additional payloads from an external server. The frightening aspect is that all these actions occur under the legitimate session of the real user. From the system's perspective: Exchange sees the request as valid, the browser sees the JavaScript as valid, EDR doesn't detect a malware process, and SOC struggles to immediately identify any anomalies.
MITRE ATT&CK Mapping
| Tactic | Technique | Mô tả |
|---|---|---|
| Initial Access | T1566.001 | Spearphishing Attachment/Email |
| Execution | T1059.007 | JavaScript Execution |
| Credential Access | T1539 | Steal Web Session Cookie |
| Collection | T1114 | Email Collection |
| Persistence | T1137 | Office Application Startup/Rules |
| Defense Evasion | T1036 | Masquerading/Spoofing |
| Lateral Movement | T1021 | Remote Services via hijacked account |
Assessment
Although the CVSS score of 8.1 accurately reflects the severity of the risk of widespread mailbox takeover, the biggest challenge in the CVE-2026-42897 event lies more in security operations (SecOps) than in the exploitation technique itself. In Vietnam, many organizations in the financial sector, government agencies, and large enterprises still operate Microsoft Exchange On-Premise systems as a critical infrastructure. In reality, many administrative teams rely almost entirely on the results from Microsoft's Health Checker script to assess patch status and report directly to leadership.
When this tool shows a "false negative"—indicating the system is unprotected even though mitigation has been applied—the consequences extend beyond technical issues. It can create significant operational pressure on the SOC and infrastructure team, leading to wasted time on repeated verification and investigation, unnecessary internal alerts, confusion during response efforts, and, more seriously, prompting engineers to make uncontrolled configuration changes or reapply mitigation, inadvertently increasing the risk of system discrepancies or service disruptions.
Recommended actions
Verify the exact status of mitigation
Do not rely solely on results from the Health Checker or any single tool to conclude that the system is secure.
Verify mitigation at both the configuration and actual behavior levels.
Save configuration snapshots before and after applying mitigation.
Standardize the verification checklist for the SOC and operations team.
Check the status of the Exchange Emergency Mitigation Service (EEMS)
Ensure:
EEMS is enabled.
The server can connect to the Microsoft Office Config Service.
The latest mitigation has been successfully downloaded and applied.
Check:
Get-ExchangeServer | Format-List MitigationsEnabled
Check applied mitigation:
Get-Mitigations
Monitor related Event IDs: 1005, 1006, 1008
Review all Exchange Internet-facing
Limit OWA access using VPN or Conditional Access,
Apply Geo-IP filtering,
Allow only whitelisted IPs for the admin portal,
Separate administrative access from public access.
Enhance monitoring for OWA
Track anomalies in IIS Logs
Monitor mailbox activity
Track unusual session/token activity
Strengthen user-side protection
Enforce MFA for OWA
Limit browser risk
Enhance user awareness
Do not open suspicious HTML emails,
Do not trust unusual internal emails,
Check for unusual outbound email
Focus on:
Sudden increase in sending volume,
Mass internal sending,
Sending to unknown domains.
Refer
On-Prem Microsoft Exchange Server CVE-2026-42897 Exploited via Crafted Email
Addressing Exchange Server May 2026 vulnerability CVE-2026-42897 | Microsoft Community Hub
