What Happened
CVE-2026-42897, a cross-site scripting (XSS) vulnerability in Microsoft Exchange's Outlook Web Access (OWA), is being actively exploited with no patch available. Attackers can compromise OWA mailboxes through malicious scripts injected into the web interface. Your email system—the hub of your organization's communication and sensitive data—is exposed, and Microsoft has not published a remediation timeline.
Timeline
Initial disclosure: CVE-2026-42897 published with active exploitation confirmed
Patch status: None available
Affected component: Outlook Web Access (OWA) interface
Attack vector: Cross-site scripting allowing mailbox compromise
The compressed timeline matters. This is a live threat with no official fix, and your response window is now.
Which Controls Failed or Were Missing
Input Validation and Output Encoding
The XSS vulnerability exists because OWA fails to properly sanitize user-supplied input before rendering it in the browser. Untrusted data reaches the DOM without contextual encoding, a common failure mode for XSS.
If your organization runs OWA without additional defense layers, you're relying entirely on Microsoft's code quality, which has proven insufficient.
Defense-in-Depth Architecture
Most organizations deploy Exchange as a monolithic trust boundary. If you can authenticate to OWA, you have full access to the web interface with minimal additional controls. There's often no Web Application Firewall (WAF) inspecting OWA traffic, no Content Security Policy (CSP) headers restricting script execution, and no additional authentication for sensitive mailbox operations.
The absence of layered defenses means a single XSS vulnerability can lead to a mailbox compromise.
Security Monitoring and Detection
XSS exploitation leaves traces: unusual script executions, unexpected DOM modifications, abnormal authentication token usage. But without collecting OWA application logs or correlating web traffic with mailbox access patterns, you won't see the attack until users report compromised accounts.
Most organizations treat Exchange as infrastructure, not as an application requiring security instrumentation.
What the Relevant Standards Require
OWASP ASVS v4.0.3
Requirement 5.3.3: "Verify that context-aware output encoding is used to protect against reflected, stored, and DOM based XSS."
This is the core control that failed. OWA must encode output based on where data appears—HTML body, HTML attributes, JavaScript contexts, CSS, or URLs each require different encoding schemes.
Requirement 5.3.8: "Verify that the application defends against XSS attacks via Content Security Policy (CSP) that disallows 'unsafe-inline' and 'unsafe-eval'."
Even if application code has encoding gaps, a strict CSP prevents inline script execution.
PCI DSS v4.0.1
Requirement 6.4.1: "Security vulnerabilities are identified and addressed."
For in-scope systems processing cardholder data, you must identify vulnerabilities through scanning, threat intelligence, and vendor advisories. Once CVE-2026-42897 was disclosed, the clock started. You need documented evidence that you assessed the risk and implemented compensating controls.
Requirement 6.4.2: "An inventory of bespoke and custom software, and third-party software components is maintained."
You should know which Exchange version you're running, whether OWA is exposed, and who has access.
NIST 800-53 Rev 5
SI-10: Information Input Validation: "Check the validity of information inputs."
Microsoft failed this control in OWA's code. But you own SI-10 for your environment, which means deploying validation at the perimeter—WAF rules that block common XSS patterns.
SI-4: System Monitoring: "Monitor the system to detect attacks and indicators of potential attacks."
You need visibility into OWA usage patterns. Deviations signal potential exploitation.
Lessons and Action Items for Your Team
Immediate Actions (Next 24 Hours)
Deploy WAF rules for OWA endpoints. Enable XSS detection rulesets. Block requests containing <script>, javascript:, onerror=, and common encoding bypasses. Tune aggressively but err toward blocking.
Implement Content Security Policy headers. Add a reverse proxy or load balancer in front of OWA that injects CSP headers:
Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'self'
This won't fix the vulnerability, but it prevents script execution even if an attacker injects a payload.
Enable enhanced logging. Turn on Exchange's HttpProxy logs and IIS detailed request logging for OWA virtual directories. Configure your SIEM to alert on suspicious patterns.
Restrict OWA access. Require VPN for OWA access or enforce MFA and device compliance. Reduce the attack surface by limiting who can reach the vulnerable interface.
Short-Term (Next Week)
Hunt for indicators of compromise. Search Exchange message tracking logs for suspicious activities. Check for new inbox rules that auto-forward messages and review recent mailbox delegations.
Test your incident response plan. Ensure you can isolate the Exchange server without disrupting email service. Run a tabletop exercise this week.
Document your compensating controls. For PCI DSS compliance, document the WAF rules, CSP headers, access restrictions, and enhanced monitoring.
Strategic (Next Quarter)
Evaluate OWA alternatives. Consider disabling OWA if it's not necessary and mandate client applications with certificate-based authentication.
Build application-layer monitoring. Instrument Exchange like a custom web app: track authentication failures, unusual mailbox access patterns, and suspicious email forwarding rules.
Establish a zero-day response playbook. Create a decision tree for assessing risk when there's no patch. Test this playbook quarterly.
The hard truth: You can't patch your way out of zero-day risk. You need defense-in-depth, visibility, and the operational muscle to deploy compensating controls while vendors catch up. CVE-2026-42897 is testing whether you built those capabilities before you needed them.
