CVE-2026-62914

The CVSS 'authorized attacker' qualifier on this Exchange Server XSS masks a structural problem that defenders need to understand clearly. Yes, exploitation requires some level of authenticated access—but that access shrinks over time. In Exchange's threat model, 'authorized' has meant everything from high-privilege admin accounts down to 'can send email to a monitored mailbox.' If you can deliver mail to an Exchange-hosted address, you've found your entry point. The constraint is a historical artifact that erodes with each CVE disclosure, not a stable mitigation. The real issue isn't whether Microsoft has access to HTML sanitization libraries—they do. It's that Exchange's rendering pipeline creates a double-trust-boundary problem that standard web-app XSS mitigations weren't designed to handle. The server must parse, store, and re-render HTML originating from untrusted external sources, then serve that content to clients (Outlook, OWA, mobile) that apply their own parsing layers. Each sanitization pass is an opportunity for encoding mismatch, and each client reconstructs the DOM differently. This isn't just incomplete use of existing libraries—it's that those libraries weren't architected for content flowing through multiple independent rendering engines in sequence. Consider also the blast radius: an XSS in Exchange doesn't just compromise a browser session. Because Exchange serves as the authentication broker for EWS, MAPI, and OAB protocols, a successful exploit can pivot to access every mailbox the compromised account can reach. The CVSS 7.3 score prices the technical XSS mechanism without accounting for this cascade potential. Legacy code is likely a significant factor. Exchange spans three decades of continuous development. Deprecated rendering pathways that predate modern sanitization libraries may still exist in the codebase—sediment layers that persist because removing them risks breaking something. When developers reach for familiar utility functions without checking their lineage, they may connect to rendering paths that never received sanitization because it wasn't the expectation when they were written. The pattern across Exchange's vulnerability history suggests this is a class problem, not an incident problem. The question for defenders isn't whether to patch—patch immediately—but whether your organization's threat model treats Exchange XSS as routine maintenance or a signal of architectural exposure that warrants deeper review of the email-rendering pipeline.

Reviewed through automated stages and approved by a human before publication.