The Exploit Doesn't Exist. You Can Still Prove It Works Against You

4 hours ago 6

Picus TTP Chain

For thirty years, vulnerability management has run on what now looks like an impossible luxury: a buffer of months between when a vulnerability was found and when someone could figure out how to weaponize it. Triage by severity, schedule the fix, validate, move on.

That generous buffer is what made the entire system work.

AI has stripped out the manual drag that kept weaponization slow. Reading the advisory, finding the path, shaping the chain, testing what works: none of it can afford to move at human speed anymore. Today, the disclosure-to-exploit timeframes run in hours, not months.

The Zero Day Clock, which tracks this in real time, currently averages around 8 hours for 2026, down from roughly 53 days just two years ago. The figure shifts as fresh data lands, but at this point it’s sitting firmly below 24 hours.

From vulnerability to exploitation

You Can't Patch Your Way Out of This

The reflex is usually to just patch faster. But remediation isn't simply a switch you flip. Patches wait on a number of contingencies: regression testing, change windows, and uptime commitments. And today, every number that matters is unfortunately moving in the wrong direction.

Verizon's 2026 Data Breach Investigations Report, drawn from more than 13,000 organizations, found that:

The median fix time for known-exploited vulnerabilities is now 43 days, up from 32 last year.
The share of organizations fully patching them is down from 38% to 26%.
Even the best performers close only 30 to 40% of these vulnerabilities in the first week, a rate that's barely budged in years.

Stats

When offense runs in hours and remediation runs in weeks, the breach lands in between. And the runway is only getting longer.

The volume guarantees it: 48,185 CVEs in 2025, fewer than 0.6% ever patched. "Patch your way out" has stopped being workable math.

Even worse, these are pre-Mythos numbers.

Mythos is the threshold at which AI models became able to find and weaponize vulnerabilities on their own, and it isn't theoretical: Anthropic's Mythos-class model found a flaw that had been hiding in OpenBSD, widely regarded as one of the world's most secure operating systems, for 27 years.

The 2025 baseline has become the floor, not the ceiling.

The question is no longer "what's vulnerable?" because in a list where everything scores a 9 or a 10, this effectively prioritizes nothing. The real question has become,"What's actually exploitable against us, right now, with the controls we’re already running?" Finding the exposure was never the hard part. Proving the right call (patch, mitigate, monitor, or accept) is the critical gap.

Your Pentest Got Faster. It Still Can't Reach What Matters.

The popular response has been to automate the pentest.

Automated pentesting tools take the manual penetration test that used to happen once a quarter and run it continuously, at scale, firing real exploit chains against real assets. Where that can run, it's the strongest proof there is: you watch the exploit succeed. Picus does it too, with Autonomous Penetration Testing. No argument there.

But, while automating the launch makes you faster; it doesn't change what the launch can reach.

Live exploitation only works where firing an exploit is safe and where a working exploit exists. That leaves three gaps no pentest tool can close, and stacking the three of them together doesn't help either. Why?

No exploit, nothing to fire. A large share of disclosed CVEs never get a public or safe exploit. With nothing to launch, execution can't tell you whether they're exploitable in your environment.
Assets you can't risk. Business-critical, regulated, and air-gapped systems are exactly the ones you can't safely detonate an exploit against, and they're usually the ones that matter most.
The day-one window. Weaponizing a fresh exploit and wiring it into your tooling takes time. Attackers are already moving while your launch is still on the bench.

In a typical enterprise, the slice you can safely exploit live is usually only 10 to 15% of your total exposure picture. For the other 85 to 90%, execution has no answer to give.

Ground-Test the Rocket You Can't Launch

The surest way to prove a rocket will fly is to launch it. But no space program proves its fleet that way.

Some exist only as a design on paper, some are crewed and too valuable to risk, and some are still on the assembly line. So engineers prove them on the ground instead: engine thrust on a static stand, testing the fuel system under full pressure, the heat shield against its maximum thermal load. If any required component fails, the rocket can't fly, and they know it without leaving the pad.

That's the same three-part gap security teams are facing.

The CVE with no exploit is the rocket that exists only on paper.
The off-limits asset is the crewed rocket you won't risk.
The day-one CVE is the partly built fuselage while your launch window is running out

The launch is the proof you reach for when you can; the ground test is the proof you rely on when you can't.

Break the Chain, Break the Exploit

An exploit isn't magic. It's a chain of specific techniques, the TTPs an attacker has to execute in sequence: gain execution, bypass a protection, escalate privilege, dump credentials, move toward the target.

Each link depends on conditions in your environment, and each can be tested on its own against your actual deployed controls, the way an engineer tests an engine on a static stand without having to launch the entire vehicle.

That's TTP-chain validation. You map a CVE to the chain of techniques its exploitation requires, then validate each technique against your existing controls. If your environment breaks any required link, the exploit can't succeed there, and you know it without having to fire a live exploit. If every link would hold, the exposure is genuinely exploitable, with evidence.

Four things separate that verdict from a static CVSS or EPSS label:

It validates by inference, not detonation. So, it works where live exploitation would be unsafe or impossible.
It's control-aware. The verdict reflects your real EDR, GPO, LSASS protection, allow-listing, and firewall, not just a number on a data sheet.
It weighs reachability. Contained exposures don't get over-counted.
It ships evidence. The chain, the controls tested, and the result: an audit trail that survives to the board.

What It Looks Like on a Real CVE

Take CVE-2025-29824, a Windows CLFS use-after-free that escalates to SYSTEM (seen in the wild in Storm-2460 → RansomEXX activity).

TTP Chaining

Instead of firing an exploit, you decompose it into the chain an attacker must run and test each step against your stack:

certutil & MSBuild execution – T1105 / T1127
KASLR bypass / SysInfo – T1082
CLFS UAF exploit → kernel execution – T1068
token modification & dllhost injection – T1134 / T1055
LSASS dump via masked dllhost – T1003

Each technique is tested against EDR policy, GPO/hardening, LSASS protection, application allow-listing, and NGFW.

If your allow-listing stops the MSBuild exec, or your LSASS protection blocks the credential dump, the chain breaks, the CVE isn't exploitable on that asset, and you can show exactly why. No certified exploit needed, and it works on the air-gapped box you'd never point a live exploit at. And in doing so, you’ve gone from a fresh CVE ID to a defensible decision in hours, on the day of disclosure, rather than weeks later.

Want to go deeper on TTP-chaining? Our two-pager walks the full pipeline and coverage model end to end. >> Read it here

Prove It Everywhere, Not Just Where You Can Launch

The launch and the ground test aren't rivals, they’re symbiotic. The strongest programs run both, and keep re-testing as the environment moves through time and configurations.

That's the loop Picus runs: live exploit chains where firing is safe, TTP-chaining for the off-limits assets and day-one CVEs that a launch can't reach, and continuous control validation so last quarter's "accept" is re-tested, not assumed.

One platform, and one answer to the only question that matters: “What's actually exploitable here, right now?”

Put it to the test on the case stuck in your backlog: the CVE on the air-gapped box you can't touch, or the one that dropped this morning with no public exploit yet.

Book a demo, and Picus will map it to its TTP chain and show you, against your own controls, whether it's exploitable or not, and why, with the evidence to take to your board.