A record Patch Tuesday and the Exchange zero-day that mattered (CVE-2026-42897)

Today's Patch Tuesday was the largest on record. Counts vary by who is filtering, with trackers reporting north of 200 CVEs, 37 critical, and six zero-days, one of which was already being exploited in the wild. When a release is that big the natural reaction is to feel buried, and the natural mistake is to treat it as one undifferentiated wall of work. It is not. A 200-CVE month has a shape, and reading that shape is the entire job. Most of those CVEs need ordinary patch hygiene on a normal cadence. A small number need to be on a fire schedule today. The skill is telling them apart.

The one that belongs on the fire schedule this month is CVE-2026-42897, an Exchange Server flaw that was being exploited before a patch existed. This is a defender's read of why a cross-site scripting bug on a mail server is an enterprise-takeover surface, how to triage a record month without drowning, and how to verify your own exposure with evidence rather than vibes.

Why the Exchange bug is the one to chase first

CVE-2026-42897 is described as a spoofing flaw, a stored cross-site scripting issue in Outlook Web Access affecting Exchange Server 2016, 2019, and Subscription Edition. The mechanism is brutally simple: an attacker sends a specially crafted email, and when the victim views it in Outlook Web Access, attacker-controlled JavaScript runs in the context of the webmail session. There is no link to click in the classic phishing sense and no attachment to open. Rendering the message is the trigger.

On a consumer webmail service, stored XSS is bad. On a corporate Exchange server it is a different category of problem, for three reasons.

First, Outlook Web Access is internet-facing for almost everyone who runs it, because remote mail access is the point. The attacker does not need to be on your network to deliver the email.

Second, the JavaScript runs with the victim's authenticated webmail session. That means it can read mail, send mail as the victim, manipulate rules and forwarding, and reach whatever the OWA session can reach. Email is the root of trust for password resets across most of your other systems, so an attacker who can act as a user's mailbox can often pivot into everything that mailbox can recover.

Third, Exchange sits at the heart of the identity fabric in a hybrid estate. Mailbox access plus the right follow-on technique has historically been a stepping stone toward broader directory compromise. A foothold in OWA is rarely the attacker's destination; it is the on-ramp.

That this was exploited before the patch shipped is the tell that someone weaponized it deliberately. Mail servers are perennial targets precisely because the blast radius is the whole organization's communications.

How to triage a 200-CVE month without drowning

The honest way to handle a record release is to stop thinking about the total and start sorting on four signals, in this order.

1. Exploited in the wild. Anything flagged as actively exploited goes to the top regardless of CVSS. Real exploitation is a stronger signal than a theoretical score. This month, the Exchange OWA flaw is the clear member of this bucket.
2. Internet-facing and pre-auth. Among the rest, prioritize anything that an unauthenticated attacker can reach from outside. A critical bug in a service nobody can reach is a lower fire than a medium bug on your perimeter.
3. Wormable or chainable. Some of this month's entries include flaws with self-propagation potential. A bug that one host can use to infect the next deserves urgency even if it is not yet seen in the wild, because the window between proof-of-concept and mass exploitation is short.
4. Everything else, on cadence. The long tail of local-only, authenticated, or hard-to-reach issues is real work, but it is normal-cadence work. Spending your emergency-change budget here is how the genuinely urgent item slips.

Notice that none of these signals is the raw count. The number is designed to alarm. The triage is designed to ignore the alarm and act on the structure.

How to confirm your Exchange exposure, evidence-first

For the OWA flaw, exposure is the product of three facts, each of which you can confirm passively against assets you own.

First, do you run on-premises Exchange at all, in an affected version. A pure cloud-mail estate is not affected by this specific server bug; a hybrid or on-premises deployment is. Read the build you have.

# Passive: which Exchange version and build is deployed?
# Read your own server inventory / build number, compare to the fixed level.
#   Affected: Exchange Server 2016, 2019, Subscription Edition below the fix.
#   PASS: cloud-only mail, or on-prem build at or above the June fix.

Second, is Outlook Web Access actually reachable from the internet. The delivery is an email, but the execution surface is OWA. A server whose OWA endpoint is restricted to an internal network or behind an authenticating proxy has a smaller window than one open to the world.

# Passive: is the OWA surface internet-reachable?
#   - Is /owa published to the public internet, or fronted by a control
#     that the crafted-message render path still passes through?
# FINDING posture: affected build + publicly reachable OWA render path.

Third, the patch state itself. The fixed builds shipped today. Confirm the cumulative update or security update that carries the fix is actually applied, not merely downloaded, because Exchange updates are notorious for needing the right post-install steps to fully take effect.

How we validate it, and why the validation is the product

We carry the active-exploitation entries from each Patch Tuesday as fresh N-day bands in the relevant families within forty-eight hours of release, and we re-run them across every continuous-monitoring engagement. For the Exchange flaw the catalog entry confirms the deployed build is inside the affected band and that the OWA surface is reachable, both passively. When both hold, we mint a Proof Capsule that records the build, the reachable surface, and the remediation that names the fixed update. When the server is patched, or OWA is not externally reachable, or the estate is cloud-only, we record a PASS and raise nothing. The point is that a record Patch Tuesday is not a reason to send a customer 200 alerts. It is a reason to prove, with evidence, which one or two of those CVEs actually touch their attack surface today.

How to fix it, in priority order

1. Apply the June Exchange security update now. The OWA flaw was exploited before the patch existed, so treat it as emergency change. Follow the vendor's post-install steps so the fix is actually active, not just installed.
2. Hunt the mailbox, not just the server. Because exploitation predates the patch, review for the signs an attacker would leave: unexpected inbox rules, new forwarding addresses, mail sent that the user did not send, and OWA sessions from unusual locations.
3. Constrain the OWA surface. Where remote webmail is not a hard business requirement for everyone, front OWA with strong authentication and restrict its exposure. A render-triggered bug is far less dangerous when the render surface is not open to the entire internet.
4. Work the rest of the month on cadence. Sort the remaining CVEs by the four signals above and schedule them honestly. The fire is the exploited item; do not let it borrow capacity from itself by treating the whole list as urgent.

What a record month says about the discipline

The headline that a single vendor shipped over 200 fixes in one day is real, and it is also a distraction. The number grows every year, and chasing it is a losing game. What does not change is the structure: a handful of these CVEs are reachable from outside, a smaller handful are being used right now, and the rest are background hygiene. The teams that stay calm in a record month are the ones who triage on reachability and real exploitation rather than on count and severity score. We do that triage for you the same way every month, by proving which of the new CVEs actually intersect your surface, attaching the patch, and recording a clean PASS on the ones that do not. The point of a continuous program is that a 200-CVE month is just another Tuesday.