OWAReaper Survives a Full Reimage. Our Own PoC Watch Never Saw It — Because a Zero-Day Nobody Publishes Leaves No Trace to Watch For.

Proofpoint published analysis of a campaign in which TA488 — the Russian cluster also tracked as Void Blizzard and Laundry Bear — exploited CVE-2026-42897 in Outlook Web Access to deploy a backdoor called OWAReaper. The credit for this research is entirely theirs; we are writing about it because of what it does to the standard incident response playbook, and because of what our own data did not show.

The exploit is a half-click: a victim opens a crafted email in OWA and malicious JavaScript executes in the browser context. The vulnerability is a cross-site scripting flaw in on-premises Exchange Server, not Exchange Online, which narrows who needs to care and sharpens it considerably for those who do.

The part that breaks your runbook

OWAReaper runs inside the OWA browser context. It has no host footprint. It uses two command-and-control channels and two separate exfiltration protocols. And according to Proofpoint's analysis it survives browser reboots, credential rotation, and full re-imaging of the victim's device.

Read that last item again, because most incident response procedures terminate there. The standard containment sequence for a compromised endpoint is: isolate, rotate credentials, wipe, rebuild, return to service. Every step in that sequence assumes the adversary's persistence lives on the host. Reimaging is the nuclear option precisely because it is supposed to be unarguable.

Against an implant that persists in the browser-and-mailbox layer rather than the host layer, the nuclear option is theatre. You can wipe the laptop, hand the user a clean build, force a password change, and still have an adversary reading mail. Worse, you will have closed the ticket, because your containment checklist completed successfully.

Targets so far span government, telecommunications, finance, hospitality and aerospace across the United States and Europe, with an attack wave on 22 July.

The blind spot in our own data, stated plainly

This morning we published a piece on weaponization latency — how often a public proof-of-concept exists before CISA lists a CVE. The central discipline of that post was the denominator: we can measure 90 KEV entries because we hold both a listing date and a PoC-sighting date, and the other 1,571 have no PoC record, which we said was unknown, not clean.

CVE-2026-42897 is one of the 1,571. We checked. Our exploit watch has no PoC sighting for it at all.

And here is the uncomfortable, useful thing: that silence was not evidence of safety. It was the signature of the opposite. A nation-state crew using a vulnerability quietly does not publish a proof of concept, does not drop a repository, and does not generate the public exploit artifact our watch is built to catch. The absence of a PoC record for 42897 does not mean it was not weaponized. It means it was weaponized by someone with no reason to tell anyone.

We flagged that limitation this morning as a methodological caution. By the afternoon we had a live example of it. We would rather show you the case that exposes our instrument's blind spot than quietly leave the caution in a footnote — a metric you only illustrate with its wins is a brochure.

The timeline says zero-day

Proofpoint reports that the earliest infrastructure connected to this campaign was created in March 2026. CVE-2026-42897 entered CISA's catalogue on 15 May 2026, which is the date we carry for it. That is roughly two months of attacker infrastructure predating the vulnerability being publicly known, and Proofpoint's own assessment is that it is feasible the group was using this as a zero-day before anyone else knew it existed.

We hold the KEV entry from 15 May. We want to be exact about what that is worth: CISA's catalogue is synced into our corpus daily, so carrying that entry is redistribution of CISA's work on the ordinary schedule, not detection. We did not find this, we did not see the infrastructure in March, and we hold no indicators specific to OWAReaper. Proofpoint found it. Anything else we implied would be selling you an ingest timestamp.

What our data does add is the negative space around it, and negative space is worth something: a KEV entry with no PoC in the wild, no commodity scanning, and nation-state infrastructure predating disclosure is a distinct profile from a vulnerability that gets a GitHub PoC and a mass-scanning wave within a week. Those two things should not be triaged the same way, and today most prioritisation models cannot tell them apart.

What to actually do

If you run on-premises Exchange, patch CVE-2026-42897 and treat it as urgent regardless of whether you believe you were targeted. Exchange Online is not affected by this one.

If you have any reason to suspect exposure, the critical change is to your containment definition. Reimaging the endpoint does not evict this implant. Containment has to include the mailbox and the browser session layer: invalidate OWA sessions and refresh tokens server-side rather than relying on a password change, review mailbox rules and delegate permissions for persistence artifacts, and look for outbound patterns from the OWA context rather than from the host.

More generally, this is the prompt to ask whether your IR playbook has any step that assumes host-layer persistence is the only kind. Browser-resident and identity-layer implants are not new in concept, but an implant explicitly documented as surviving a full rebuild is the clearest argument yet that "wipe and rebuild" is a step in containment rather than the end of it.

The honest accounting

Proofpoint did the research. We carried the KEV entry from 15 May on the normal CISA sync and we hold no OWAReaper indicators. We came to this in a paranoia sweep after the fact, which is exactly the kind of catch that should have been in the morning brief and was not.

The one thing here that is genuinely ours is the negative result, and it cuts against us: our PoC watch had nothing on this CVE, and that emptiness was a signal we were not reading as one. We are recording it because the same blind spot applies to the other 1,570 entries we described this morning as unknown.

We guarantee five percent of what we publish is wrong. Today the five percent was in our own instrument, and it took someone else's research to show it to us.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.