"Hard to Exploit" Just Died

For 26 years, "hard to exploit" has quietly been part of how we prioritize risk. That assumption just died.

I've sat in a lot of patch meetings. More than 600 incident-response engagements, and a depressing number of them started with a vulnerability someone had already looked at, scored, and parked. The reasoning was almost always the same. Sure, it's a 9.1, but it needs a specific config. It's a memory corruption bug, you'd need someone really good to weaponize it. It only works if you chain it with something else. Nobody's going to bother.

I can picture the pattern without naming a single client. A mid-sized firm. An edge appliance flagged months earlier. The finding sat in an exception register with a note that said "high complexity, requires chaining, no known exploit." By the time I got the call, someone had done the chaining. The note was still there, perfectly accurate on the day it was written.

That logic wasn't lazy. It was economics.

Writing a reliable exploit took skilled people days or weeks. Skilled people are scarce and expensive, so attackers spent them on the easy stuff. Defenders priced that scarcity into every risk decision we made, usually without saying it out loud. "Hard" was a stand-in for "nobody has the time."

The scarcity is gone.

Weeks became hours

In April, Anthropic disclosed Claude Mythos Preview and Project Glasswing. In Firefox testing, Mythos produced 181 working exploits where the previous model managed two across hundreds of attempts. It found and chained multiple Linux kernel flaws on its own. Validators said exploits the model built in hours would have taken expert humans weeks.

Read that last part again. Weeks to hours. That gap is exactly where "hard to exploit" lived.

Mythos isn't publicly available. That matters less than people think. The capability is showing up everywhere else. Google's threat intelligence group reported in May the first zero-day exploit it believes was developed with AI. Researchers from Toronto, the Vector Institute, and Cambridge built a worm prototype that read advisories for CVEs published after its training cutoff and wrote working exploit code with no human involved. AISLE's autonomous system found all 12 CVEs in the January 2026 OpenSSL release, in one of the most heavily audited codebases on the planet.

Capability doesn't stay in the lab. It never has.

We've seen half of this movie

People will say we've been here before. Metasploit, exploit kits, ransomware affiliates buying access instead of earning it. Each of those lowered the bar to use an exploit. Point, click, done.

None of them lowered the bar to write one. That part stayed hard. Somebody still had to read the code, understand the memory layout, find the second bug that made the first one useful, and grind until it worked reliably. That work was the real filter on the threat landscape, and it was the filter our prioritization quietly leaned on.

That's the bar AI is taking out. Not the delivery. The creation.

It also changes who shows up. A crew that used to wait for someone else's proof of concept doesn't have to wait anymore. And the attacker's math gets ugly for us: compute is cheap, models don't get bored, and they only need one chain to land. You need every link covered.

The clock already moved

Mandiant's M-Trends 2026 puts the mean time to exploit at negative seven days. On average, exploitation now starts before the patch exists. Rapid7 found the median time from disclosure to the CISA KEV catalog fell from 8.5 days to 5, while exploited high and critical vulnerabilities more than doubled year over year.

One honest caveat, because this isn't a doom piece. VulnCheck's first-half 2026 data shows the share of known exploited vulnerabilities hit on or before publication actually dipped, from about 29% in 2025 to 23.4%. VulnCheck's read is that AI currently helps defenders more than attackers. Fair. But the same report shows median time from publication to KEV dropping from 120 days to 80.

The sky isn't falling. The clock is speeding up. And the most capable models haven't reached the people who'd point them at you. That's the window, and it won't stay open.

Where "hard to exploit" hides in your program

Nobody has a policy that says "ignore the hard ones." It's baked in quieter than that.

CVSS. Attack Complexity: High and Attack Requirements: Present pull scores down. Those metrics were partly a measure of how much human skill and setup an exploit took. That cost just collapsed, and the score didn't notice.

EPSS. Public exploit availability is the single strongest predictor in the model. It's trained on a world where writing exploits was slow. When the exploit gets written in the same session the bug is found, a model built on history is looking in the rearview mirror.

Your exception register. "Requires local access." "Requires chaining." "No public PoC." Read it back. Every one of those is an effort argument.

Your board's risk register. Somewhere there's a likelihood column with "Low" in it. Ask who rated it, and why. I'd bet the answer is "it's hard to pull off."

We leaned on "hard to exploit" because it let us defer work we didn't have the people for. Scanners and dashboards leaned on it too, because a shorter critical list looks like progress. Neither motive survives an attacker who doesn't get tired.

What to do Monday

Pull the deferrals. Every vulnerability you parked because of complexity, chaining, or "no public exploit." Re-rank them on exposure and impact alone.

Treat "no public exploit" as a timestamp. It tells you what was true yesterday. It's not a control.

Score chains as one finding. Three mediums on the same internet-facing box are a critical waiting for someone patient. AI is very patient.

Know what's exposed. If effort no longer filters your queue, reachability has to. You can't prioritize what you don't know is on the internet.

Make the landing boring. Segmentation, least privilege, and credential hygiene decide whether a working exploit becomes an incident or a log entry.

Point the same tools at yourself. Defenders have the same models. Use them on your own code and configs before someone else does.

Fix the likelihood column. Tell your board plainly that a set of risks just moved up a row, and why. They'd rather hear it from you than from me after the call.

Bottom line

"Hard to exploit" was never a control. It was a bet on the attacker running out of skilled people before we ran out of time. AI just ended the talent shortage on the other side. Go find every place your program still assumes it didn't.