An unauthenticated Exchange spoofing bug shows why DMARC and patching aren't the same control

On May 14, Microsoft confirmed active, in-the-wild exploitation of CVE-2026-42897, a high-severity spoofing vulnerability (CVSS 8.1) in the Outlook Web Access component of on-premises Exchange Server 2016, 2019, and Subscription Edition, according to Microsoft’s own advisory and BleepingComputer. The root cause is a reflected cross-site scripting flaw: OWA didn’t properly sanitize certain user-supplied input before rendering it, so a specially crafted email could run arbitrary JavaScript inside the victim’s browser session the moment they opened it in webmail. From there, an attacker’s script runs with the privileges of the logged-in session — reading mail, sending as the victim, planting inbox rules that persist past a password reset, or hijacking the session outright, as Help Net Security detailed. Exchange Online was not affected; this is an on-premises-only issue.

No authentication, no attachment, no macro — just a message the victim opens in a browser-based mail client. That’s the detail worth sitting with, because it’s a category of trust assumption most people don’t think about: webmail is a browser rendering content an attacker fully controls, and every rendering bug is a potential script-execution bug.

Two different problems that both involve “email trust”

It’s easy to conflate “the message is authenticated” with “the message is safe to render,” but they answer different questions entirely, and CVE-2026-42897 is a clean illustration of why both matter and neither substitutes for the other.

	DMARC (SPF/DKIM alignment)	Patching the mail client
What it verifies	The sending domain actually authorized this message	The rendering engine doesn't execute attacker-controlled code
What it protects against	Domain spoofing, look-alike sender fraud, unauthorized use of your domain	Malicious content hidden inside an otherwise legitimately-sent message
Where it runs	At the receiving mail server, before the message reaches an inbox	In the mail client itself, when the message is opened and rendered
Stops CVE-2026-42897?	—	✓
Stops a spoofed 'from your bank' email?	✓	—

A perfectly DMARC-aligned message can still exploit a rendering bug in the client that opens it — DMARC never inspects message body content, only whether the sending domain is who it claims to be. Conversely, a fully patched, bug-free mail client offers zero protection against a message that spoofs a trusted domain and simply asks the recipient to click, reply, or wire money — there’s no code to exploit, just a convincing lie the client renders faithfully because nothing checked whether the sender was allowed to use that domain in the first place.

Webmail has always had to trust the message it’s about to render

This isn’t the first time a webmail client has shipped an XSS bug, and it won’t be the last, because the underlying design tension never goes away: a webmail client’s entire job is to take content written by someone else — potentially a stranger, potentially an attacker — and render it as formatted HTML in the same browser context as the rest of the mailbox. Every mainstream webmail client strips or neutralizes script tags, event handlers, and other executable content before rendering, precisely because HTML email is, by design, attacker-controlled input. CVE-2026-42897 is a reminder that the sanitization layer doing that work is itself just code, and code has bugs. A single gap in how OWA neutralized one kind of user-supplied input was enough to let a script through that the sanitizer was supposed to catch.

That’s worth generalizing beyond Exchange specifically. Any system that renders untrusted HTML — a webmail client, a help-desk ticket viewer, a CRM that shows inbound message bodies, a marketing tool that previews received replies — carries the same structural risk. The fix is never “don’t render HTML,” because that breaks the product; it’s maintaining and continuously testing the sanitization boundary against new bypass techniques, the same way Exchange’s OWA team will now need to re-audit its input handling after this disclosure.

What this means if you run a sending domain or manage a mailbox

If you’re on the sending side, CVE-2026-42897 isn’t really “your” vulnerability — it’s a mail-client bug on the receiving end. But it’s still relevant to your deliverability posture in two ways. First, it’s a reminder that DMARC enforcement on your own domain does nothing to protect your recipients from a rendering bug in whatever client they use to read your mail — that’s on the client vendor, not the sender. Second, and more directly: attackers exploiting bugs like this often pair them with domain spoofing to maximize the odds a target opens the malicious message in the first place. A domain with strict DMARC enforcement is measurably harder to spoof convincingly, which reduces the pool of victims worth targeting with a client-side exploit that requires a plausible sender to begin with — and it’s the same authentication a connected sending domain has to verify before Norbelys will let a campaign go live on it, not an optional hardening step left for later.

If you administer mail infrastructure — Exchange or otherwise — the practical takeaway is boring but true: patch cadence for the mail client and browser-rendering surface is a distinct control from anything DMARC, SPF, or DKIM will ever cover, and skipping either one leaves half the attack surface open. Review your SPF and DKIM alignment and keep DMARC reports under regular review — and treat vendor patch advisories for whatever mail client your organization actually opens messages in as an equally non-optional part of the same deliverability and security posture, not a separate IT concern.

The DMARC half of that posture is the part a sending platform can actually own on your behalf. Norbelys DMARC monitoring tracks SPF and DKIM alignment continuously and shows the policy path from p=none to p=reject, so your own domain isn’t the plausible-looking sender an attacker pairs with a client-side bug like CVE-2026-42897 to get a target to open the message in the first place. It doesn’t touch the patch cadence for whatever mail client your recipients use — that’s still on the client vendor — but it closes the authentication half of the attack surface that’s actually yours to control.