Every patch is a confession.
The moment a vendor ships a security fix, the diff between the old code and the new code tells anyone watching exactly what was broken and where. Turn that diff back into a working exploit, and you can hit every system that hasn't updated yet. This is N-day exploitation, and it's always been a race: the vendor patches, the clock starts, and defenders try to deploy before an attacker finishes reverse-engineering the fix.
For the last thirty-odd years, defenders usually won that race.
Reverse-engineering a patch into a reliable exploit was slow, specialized work - usually requiring weeks of expert-level effort. Historically, the gap between a patch and a working public exploit spanned weeks, often months.
The traditional playbook assumed you had at least a few weeks. You don't anymore. Not even close.
Reverse-engineering a patch used to take weeks. Mythos does it in an hour.
Anthropic's red team measured exactly that.
Given nothing but the public diff and two builds, Claude Mythos Preview turned 18 Firefox patches into 8 working code-execution exploits on its own. Its first exploit landed under an hour after Mozilla shipped the patch. The Firefox release carrying that fix was still 18 days out.
The Windows results are harder still: no source code, just stripped binaries and decompiler output. Even so, out of 21 kernel bugs it built proof-of-concept crashes for 18 (the fastest in 31 minutes) and chained 8 of them all the way to SYSTEM, at a cost of roughly $2,000 each.
 |
| Figure 1. Time to reproduce PoCs for 21 Windows kernel CVEs by Anthropic |
It gets worse: one of those SYSTEM chains was for a bug Microsoft had tagged "Exploitation Unlikely," and those ratings are calibrated for human researchers. Clearly, that calibration no longer holds.
The public Claude models, with their safeguards turned on, built exploits too, just fewer, so this is not one locked capability behind a single gated model.
Defenders can take some small comfort that turning an exploit into a full intrusion still takes more work, delivery, targeting, evasion. But the step that used to buy defenders their weeks - turning a patch into a working exploit - is exactly the one whose timeline has completely collapsed.
As Anthropic's own team put it: "N-hour is closer to the reality we now operate in."
Sorry, you can't patch your way out of this
Here's the asymmetry that breaks the old playbook: the patch meant to protect you is the same artifact that arms the attacker. Oh boy.
Ship the fix, and you hand attackers a roadmap to the bug, and everyone who hasn't updated becomes a target. Researchers now call this tipping point the "Vulnpocalypse", the moment a model can weaponize a disclosure faster than defenders can deploy the fix.
It's why a 1-day exploit reads nothing like it did two years ago.
The knee-jerk response to patch faster is a losing proposition. The numbers back this up:
- Verizon's 2026 DBIR puts the median time to fix a known-exploited flaw at 43 days, up from 32 the year before, with only 26 percent ever fully patched. Even the best performers close just 30 to 40 percent of known-exploited vulnerabilities in the first week.
- The Zero Day Clock puts 2026's average time-to-exploit at less than 24 hours, down from about 53 days in 2024.
 |
| Figure 2. Mean Time to Exploit a CVE by Zero Day Clock |
Patches wait for regression testing, change windows, and uptime commitments; taking production down to outrun an exploit is just a different outage. And with roughly 135 new CVEs a day, (currently up about 40 percent year over year), it's no surprise that your teams will never be able to clear the backlog. Today's breaches are increasingly happening in that gap.
So the question is no longer "what's vulnerable?" A backlog where everything scores 9.8 effectively prioritizes nothing. The question to ask instead is," Which exposures can an attacker actually exploit here, would our controls stop the attempt, and can we prove it?"
Validation doesn't make you patch faster. It makes patch speed matter less.
 |
| Get the Post-Mythos Action Plan: five moves, a pass test for each, and a five-day start plan. Start closing the gap now. Download now. |
Validate exploitability, don't assume it
Proving this takes three methods, because no single one reaches the whole environment.
One: fire a real exploit where you can do so safely.
A live exploit chain against a reachable asset is the strongest proof there is, and it's what autonomous penetration testing does. But a live exploit can only detonate where detonating is safe. That rules out business-critical systems, restricted networks, and air-gapped segments, which are generally the assets that matter most. It rules out every CVE with no public, safe exploit. And on day one, there's a lag before any exploit exists. Add it up and the safely testable slice of your total exposure is a paltry 10 to 15 percent of your environment.
No matter how many pentest tools you own, they all eventually hit the same wall. The other 85 to 90 percent, the crown jewels you can't touch and the threats no one has weaponized yet, is where the decision actually lives.
Two: for that 85 to 90 percent, prove against your controls instead of firing an exploit.
This isn't reading a config and assuming; it's running the actual attacker behaviors against your live stack and watching what holds. Think of a rocket you can't launch, one of a kind, human-crewed, or perhaps still in development. You prove it on the ground in every way you can before that first test flight, testing each component against real conditions; if a required part fails, it won't fly, and you know that without the expense, exposure, and danger of a live launch.
An exploit is essentially the same idea: a chain of techniques run in sequence.
 |
| Figure 3. TTP Chaining by Picus Exposure Validation |
Decompose a CVE into that chain and validate each link against your actual controls, EDR policy, segmentation, allow-listing, and firewall.
Break a required link and you know the exposure isn't exploitable here, with evidence, even on the assets you can never touch and against the threats no one has weaponized yet.
Three: prove your controls actually hold.
Continuously run the newest attacker techniques against your live prevention and detection stack, so you know what gets blocked, what silently slips through, and where a control has drifted, before an attacker finds it out for you.
Run together, these stop being three separate processes and become one continuous loop: validate, decide, fix, re-validate. That's the shift Gartner's adversarial exposure validation describes, and it's what turns a critical finding into a defensible call: Patch, Mitigate, Monitor, or Accept, instead of a guess resting on a severity score.
Where Picus fits in
Finding the exposure was never the hard part. Proving the right call is, and that's the loop Picus runs continuously, so the answer never goes stale.
- Where firing a live exploit is safe, Picus Autonomous Penetration Testing hands you the strongest proof there is by running the real chain against reachable assets.
- For everything you can't safely touch, the restricted, air-gapped, and business-critical systems, plus the CVEs with no exploit yet, Picus Exposure Validation proves exploitability through TTP-chaining, no detonation required, with an answer on day one of disclosure.
- And Picus Breach and Attack Simulation keeps checking your live security stack against the newest techniques. When a control slips, it hands back the exact signature or rule to close the gap, then re-validates that it's actually been closed.
Three methods, one loop. All driven at machine speed by Picus Swarm, a team of AI agents that works inside the guardrails you set, with a traceable chain of custody, no opaque scores or hallucinated attack paths.
The following are actual customer results, from closing real gaps instead of buying more tools:
- 92% fewer SLA violations on high and critical findings
- 89% lower MTTR
- 2x control effectiveness in three months
That's the business case: keep operations running and spend budget where it changes the outcome, instead of patching everything and protecting nothing, and lighting your teams' hair on fire in the process. The board question has moved from "are we patched?" to "are we secure right now, and can you prove it?"
Find out what an attacker could actually exploit in your environment before the next patch wave hits. Request your free demo here.
Note: This article was written by Sıla Özeren Hacıoğlu, Security Research Engineer at Picus Security.