{"id":24791,"date":"2026-06-23T10:19:08","date_gmt":"2026-06-23T03:19:08","guid":{"rendered":"https:\/\/fpt-is.com\/en\/?post_type=goc_nhin_so&p=24791"},"modified":"2026-06-26T02:20:49","modified_gmt":"2026-06-25T19:20:49","slug":"new-zero-day-on-microsoft-exchange-just-one-email-can-steal-an-entire-owa-login-session","status":"publish","type":"goc_nhin_so","link":"https:\/\/fpt-is.com\/en\/insights\/new-zero-day-on-microsoft-exchange-just-one-email-can-steal-an-entire-owa-login-session\/","title":{"rendered":"New Zero-Day on Microsoft Exchange: Just one email can steal an entire OWA login session"},"content":{"rendered":"

Risk summary<\/span><\/h2>\n

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.<\/span><\/p>\n

 <\/p>\n

Background and history of the attack<\/span><\/h2>\n

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.<\/span><\/p>\n\n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n
Campaign<\/span><\/td>\nYear recorded<\/span><\/td>\nCVE<\/span><\/td>\nAffected version<\/span><\/td>\nType of vulnerability<\/span><\/td>\n<\/tr>\n
ProxyLogon<\/span><\/td>\n2021<\/span><\/td>\nCVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065<\/span><\/td>\nMicrosoft Exchange Server 2013-2019<\/span><\/td>\nRemote code execution (RCE) via unauthenticated access<\/span><\/td>\n<\/tr>\n
ProxyShell<\/span><\/td>\n2021<\/span><\/td>\nCVE-2021-34473, CVE-2021-34523, CVE-2021-31207<\/span><\/td>\nMicrosoft Exchange Server (on-premises)<\/span><\/td>\nRemote code execution (RCE) via unauthenticated access<\/span><\/td>\n<\/tr>\n
OWASSRF<\/span><\/td>\n2022<\/span><\/td>\nCVE-2022-41040 and CVE-2022-41082<\/span><\/td>\nMicrosoft Exchange Server 2013, 2016, 2019<\/span><\/td>\nServer-Side Request Forgery (SSRF) and Remote Code Execution (RCE)<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/span><\/p>\n

 <\/p>\n

Information vulnerability<\/span><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Attribute<\/span><\/th>\nValue<\/span><\/th>\n<\/tr>\n<\/thead>\n
CVE<\/span><\/td>\nCVE-2026-42897<\/span><\/td>\n<\/tr>\n
Severity<\/span><\/td>\nHigh<\/span><\/td>\n<\/tr>\n
CVSS<\/span><\/td>\n8.1<\/span><\/td>\n<\/tr>\n
CWE<\/span><\/td>\nCWE-79 – Cross-Site Scripting<\/span><\/td>\n<\/tr>\n
Affected Component<\/span><\/td>\nOutlook Web Access (OWA)<\/span><\/td>\n<\/tr>\n
Affected Products<\/span><\/td>\nExchange Server 2016 \/ 2019 \/ SE<\/span><\/td>\n<\/tr>\n
Attack Vector<\/span><\/td>\nNetwork<\/span><\/td>\n<\/tr>\n
User Interaction<\/span><\/td>\nRequired<\/span><\/td>\n<\/tr>\n
Exploitation<\/span><\/td>\nConfirmed In-The-Wild<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Event timeline<\/span><\/h2>\n\n\n\n\n\n\n\n\n\n
Event timeline<\/span><\/th>\nEvent<\/span><\/th>\n<\/tr>\n<\/thead>\n
14\/05\/2026<\/span><\/td>\nMicrosoft announces CVE-2026-42897<\/span><\/td>\n<\/tr>\n
14\/05\/2026<\/span><\/td>\nConfirmed active exploitation<\/span><\/td>\n<\/tr>\n
15\/05\/2026<\/span><\/td>\nThe Hacker News and several security firms issued warnings.<\/span><\/td>\n<\/tr>\n
15-17\/05\/2026<\/span><\/td>\nMicrosoft released a temporary mitigation through EEMS.<\/span><\/td>\n<\/tr>\n
Hi\u1ec7n t\u1ea1i<\/span><\/td>\nCurrently, there is no complete permanent security patch available.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Technical mechanism\"D452ade8<\/a><\/span><\/h2>\n

Exploitation conditions<\/span><\/h3>\n

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.<\/span><\/p>\n

Related Architecture and Root Cause<\/span><\/h3>\n

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).<\/span><\/p>\n

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.<\/span><\/p>\n

\"88fe2d8b<\/a><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

This means the malicious script will run under the same origin as OWA, for example:<\/span><\/p>\n

\"8228d74b<\/a><\/p>\n

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.<\/span><\/p>\n

Detailed technique<\/span><\/h2>\n

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.<\/span><\/p>\n

Stage 1 – The attacker sends a crafted email<\/span><\/h3>\n

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.<\/span><\/p>\n

\"837c4adf<\/a><\/p>\n

Stage 2 – Exchange processes the email<\/span><\/h3>\n

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.<\/span><\/p>\n

Stage 3 – The user opens the email using OWA<\/span><\/h3>\n

As soon as the victim logs into\u00a0https:\/\/mail.company.com\/owa\/<\/a>\u00a0and 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.<\/span><\/p>\n

Stage 4 – JavaScript begins to operate<\/span><\/h3>\n

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.<\/span><\/p>\n

MITRE ATT&CK Mapping<\/span><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
Tactic<\/span><\/th>\nTechnique<\/span><\/th>\nM\u00f4 t\u1ea3<\/span><\/th>\n<\/tr>\n<\/thead>\n
Initial Access<\/span><\/td>\nT1566.001<\/span><\/td>\nSpearphishing Attachment\/Email<\/span><\/td>\n<\/tr>\n
Execution<\/span><\/td>\nT1059.007<\/span><\/td>\nJavaScript Execution<\/span><\/td>\n<\/tr>\n
Credential Access<\/span><\/td>\nT1539<\/span><\/td>\nSteal Web Session Cookie<\/span><\/td>\n<\/tr>\n
Collection<\/span><\/td>\nT1114<\/span><\/td>\nEmail Collection<\/span><\/td>\n<\/tr>\n
Persistence<\/span><\/td>\nT1137<\/span><\/td>\nOffice Application Startup\/Rules<\/span><\/td>\n<\/tr>\n
Defense Evasion<\/span><\/td>\nT1036<\/span><\/td>\nMasquerading\/Spoofing<\/span><\/td>\n<\/tr>\n
Lateral Movement<\/span><\/td>\nT1021<\/span><\/td>\nRemote Services via hijacked account<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Assessment<\/span><\/h2>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

Recommended actions<\/span><\/h2>\n

Verify the exact status of mitigation<\/span><\/p>\n