Finding Went to Machine Speed. Fixing Didn’t.

Executive summary: Frontier models made vulnerability discovery cheap and fast, yet AI-found bugs are exploited at the historical rate: only about 1% of them have been exploited in the wild. Only 1 in 8 disclosed findings has a known upstream patch. Finding bugs now runs at machine speed, while deploying remedies and patches is still human-driven. In code, the solution is to remediate inside the agent and prevent the new flood of vulnerabilities. For operations, attributing the assets and giving teams easy-to-deploy remedies is the key to approaching machine-speed vulnerability remediation.

Key takeaways

• Measure cost per verified, deployed fix. Cost per finding stopped being a useful number when a model could produce a privilege-escalation result for roughly $1,280.
• Treat AI-found vulnerabilities like every other vulnerability. VulnCheck counts 14 exploited out of 1,061, or 1.3%, inside the 1 to 2% historical norm.
• Stop the bug class at the source. Turn your confirmed findings into guardrail rules the coding agent reads every session, and hand findings back while the session is still open.
• Work the backlog by fix, not by finding. One base-image rebuild or one library upgrade can close dozens of tickets, and most of the pile is not reachable anyway.
• Keep a person on every merge. Supervised AI security patches reach a 67.7% merge rate. Unsupervised patches that stop the exploit still fail developer tests about a third of the time.
• You can’t prevent or fix anything if you don’t know which asset is affected and which team owns the fix.

1. The problem: discovery went to machine speed, remediation stayed at human speed

Finding vulnerabilities used to be the expensive part. It isn’t anymore, and now it moves at machine speed.

In November, OpenAI described a Linux campaign that produced 948 distinct local privilege-escalation results for $1.21 million in API credits, roughly $1,280 each (OpenAI). Months earlier, Anthropic’s Mythos Preview built eight Windows privilege-escalation chains for $15,700 (Anthropic). These are research-pipeline costs, not the price of a breach. They still tell you where the curve is going: discovery and exploit development now scale with compute budget.

The fix side tells a different story. Anthropic’s own disclosure dashboard, updated 2 November, lists 5,087 disclosed findings across 680 open-source projects and 629 known upstream patches (Anthropic CVD dashboard). That is about one in eight. It is a snapshot of a lagging process, not a rejection rate, and the labs are clear about why. In May, Anthropic wrote that the bottleneck is “the human capacity to triage, report, and design and deploy patches” (Anthropic).

Meanwhile, vendor patch volume keeps climbing, and every enterprise sits downstream of it. A patch that exists upstream protects nobody until it is in your build, your image and your running estate.

Daniel Stenberg, who maintains curl, put it bluntly on LinkedIn this week: the trillion-dollar companies are focused on finding issues at high speed and volume, and hardly any of them care about fixing those problems with any sense of quality. He has earned the right to say it. curl’s security reports arrived at four to five times the 2024 rate this spring, and by October the project moved low and medium-severity reports into public GitHub issues just to keep up (Stenberg, The pressure; curl policy change).

Most of the industry conversation is still about finding more. The real issue is that nobody scaled the other half.

2. Technical analysis: AI-found does not mean AI-exploited, and a patch is not a fix

The apocalypse did not arrive through discovery

VulnCheck has been tracking this since spring, and we laid out the exploitation data behind the shift in Less Doom, More Action: the Vulnapocalypse-Ready VM Program. As of early October, 286 public CVEs were linked to Anthropic or Project Glasswing, and two were exploited in the wild: the Ghost SQL injection (CVE-2026-26980) and the Rejetto HFS authentication bypass (CVE-2026-61500), each exploited within about a day of disclosure (The Register, 21 Sep; The Register, 3 Oct). That is 0.7%.

Widen the lens to every AI-assisted discovery, Anthropic and Berkeley combined, and VulnCheck’s State of Exploitation 1H-2026 counts 14 exploited out of 1,061, or 1.3% (VulnCheck). The historical norm for all vulnerabilities sits at roughly 1 to 2%.

The lab number everyone quoted deserves the same scrutiny. Mythos turned known SpiderMonkey crashes into working exploits in 181 of 250 trials, 72.4%. Those trials started from crashes that were already known, ran with the browser sandbox removed, were run by Anthropic, and have not been independently repeated (Help Net Security). In real attacks, about one in a hundred AI-found bugs has been exploited.

Two caveats keep this honest. Google’s threat intelligence team found that AI-discovered CVEs skew toward medium and high risk compared with conventional CVEs (TechTarget). And when one does get exploited, it happens fast. So this is no reason to relax. Exploitation still follows the same economics it always did: attackers go after what is exposed, reachable and unpatched. Your exposure is the vulnerabilities still sitting in production, whoever found them.

Found, acknowledged, not fixed

The number the discovery headlines leave out is acceptance into a shipped fix. On 2 October, Anthropic’s own dashboard showed this funnel (Anthropic CVD dashboard):

Maintainers acknowledged 83% of what they received and shipped a fix for 8.4%. Four in five findings never left the lab. Of those that did, fewer than one in ten became a patch.

The trend does not rescue it. In May, 75 of 530 disclosed high and critical bugs were patched, about 14%, with an average of two weeks per fix (Anthropic). By October the share had fallen to 8.4% as volume grew. The November figure of 12.4% looks better mainly because Anthropic stopped counting duplicates and withdrawn findings, shrinking the denominator. VulnCheck’s reconciliation of Anthropic’s ledger was harsher still: 0.8% of 26,153 claimed findings marked fixed (VulnCheck). Anthropic itself notes that “patched upstream” does not mean the patch was widely installed.

Part of the reason acceptance is slow is that every finding costs a maintainer review, and many arrive overrated. Claude rated 91.5% of findings high or critical; maintainers rated 51.3% that way (TechTarget). Of eight Critical ratings on CVE-assigned advisories, one held (Help Net Security). Vendors absorb the same load: Mozilla fixed 271 Mythos bugs in Firefox 150, 180 of them sec-high, and Palo Alto shipped an advisory with 26 CVEs against a usual fewer than five (Ars Technica).

VulnCheck’s Patrick Garrity named the gap correctly: it lies “downstream in coordination, triage, remediation, and patch deployment” (The Register). Discovery produced the backlog. Nobody built the machine to drain it.

Where fixes actually stall

Remediation is a chain, and every link has its own failure rate. The table below separates stages that most reporting collapses into one number.

The last row is the one your board cares about, and it is the one nobody publishes.

The fix is fast. Everything around it is slow.

Stenberg makes a point that most vendors skip. Once a problem is confirmed and agreed, writing the patch for curl is usually quick. The time goes into the process before that: verifying the finding, judging severity, reconstructing history, coordinating with the reporter (NPR). In October he described the new problem as high volume and high quality, which is harder than slop because you cannot dismiss it (Stenberg).

Enterprises live the same pattern one level down. The patch exists. The hard part is knowing which of 400,000 findings it closes, which team owns the repository, whether the package lives in the build file or the base image, and whether the change will break the service. That is context work, and model tokens spent without that context are wasted.

3. The Phoenix approach: close the tap, burn the backlog

If discovery scales and remediation doesn’t, adding another scanner makes the list longer and changes nothing. You have to work both ends at once: stop new vulnerabilities from entering the code, and shrink the pile that is already there faster than it grows. That is the control framework we published in June, Close the Tap, Burn the Backlog, and both halves run on the same knowledge graph.

Close the tap: fix it while the agent still has the context

A finding on agent-written code that lands three days later costs twice. Once in reviewer hours. Again in tokens, because a fresh session has to re-read the repository to find code it wrote yesterday. Purple Hook runs inside the AI coding assistant at fixed moments: session start, after a push, when it opens a pull request. It puts the finding and its remedy back into the session that produced the bug, so the assistant applies the fix while it still understands the change.

Two design rules matter more than any feature. Only findings new in the changed lines block, so a ten-line change is never judged against the whole backlog. And a skipped or failed scan is named as skipped, never reported as a pass. Engineers disable gates they cannot read.

The guardrail loop compounds this. Every confirmed finding becomes a candidate rule for the agent’s next session. The measure to watch is simple: new findings in those classes should trend toward zero.

Burn the backlog: fix by remediation, not by finding

The tap does nothing for the hundreds of thousands of findings already in your estate. Most of that pile is noise: unreachable code, the same package counted four times across four tools, CVSS scores with no exploit path. Strip that out with reachability, deduplication and ownership, and the backlog becomes a list of fixes, each with an owner.

Green AI Remedy works on what survives. It decides where each fix lives before any model runs. A package declared in the build file is an SCA fix, and the agent assesses it. A package that arrived with the base image is a rebuild, owned by the platform team, with no model call at all. The plan shows the estimated cost in US dollars before the first token is spent. A person reads the finding statuses, reviews the diff and publishes the pull request. A merge does not close the finding. The next scan does, because only the scan proves the vulnerable version is gone.

That last rule is the whole argument of this post in one line. AI can propose. Verified closure is what counts.

4. Attribution: you can’t prevent or fix what nobody owns

Every finding needs two answers before anyone can act on it: which asset is affected, and which team owns the change. Without both, a finding is an observation. It cannot become a fix, and it cannot become a rule that stops the next one.

This is the step the discovery race skips. A model can tell you a library in a container image is vulnerable. It cannot tell you that the image is built from a repository owned by the payments team, runs on a base image owned by platform, and serves a customer-facing service in production. That mapping lives in your CI pipelines, registries, cloud accounts and org chart, and in most companies it lives in nobody’s head completely.

Why ownership decides both prevention and remediation

Prevention needs an owner as much as remediation does. A guardrail rule belongs in a specific repository’s agent files, and someone has to accept it there. A hook policy is set per workspace, and someone has to answer when it blocks. If a finding class keeps recurring across 40 repositories and you cannot say which teams own them, you cannot push the rule to the right place, and the agent keeps writing the bug.

Remediation fails the same way, more visibly. An unowned finding sits in a shared queue, gets reassigned twice, and ages past every SLA. An AI-generated pull request against a repository nobody claims is noise with better formatting. In Green AI Remedy, a finding not mapped to a repository is listed as an exclusion with that reason, because there is nobody to review the fix. That exclusion is an ownership gap worth fixing on its own.

The freezers are the extreme version. The flaws were public, the fixes were published, and for months nobody whose job it was to close them knew the devices were on the internet.

What attribution has to cover, code to cloud

Phoenix builds these links with team attribution rules and team inheritance: assign ownership once at the level that is true (a repository pattern, a cloud account, a tag, a service), and every finding and asset underneath inherits it, including new ones the next scan finds. Bazaarvoice mapped 32,000 team rules this way, and one team reached zero criticals in a single month once its findings arrived with a clear owner.

The measure to watch is ownership coverage: the share of findings and assets with an assigned team. Anything below full coverage is a list of risks nobody can act on, and no amount of discovery speed changes that.

5. Real-world example: the freezers were not a discovery problem

In October, attackers forced refrigeration controllers in hundreds of French supermarkets into prolonged defrost, with temperatures reported as high as 50°C (BBC). A second wave on 2 November hit shops across several European countries, including around 40 Delhaize stores, and reached cold-room controls at three French blood-service sites, where monitoring caught it before any product was lost (BBC; EFS). We covered the incident chain in From Freezer Hacks to Developer Compromise.

Nobody needed a frontier model to find these weaknesses. They were public for years.

Read the last row against the fourth. The fix was available for over a year. Taking the interface off the internet took days once someone cared. And 1,019 of those exposed addresses had already been sitting there since March. The remediation was never technically hard. It was unowned, unprioritised and deferred until after the damage.

One honest caveat: CERT-FR has not mapped the attacks to these specific CVEs, and the exact attack path is unconfirmed (CERT-FR). The point stands regardless. Known weaknesses on exposed, consequential systems stayed open because nobody owned closing them.

This is the same failure mode at enterprise scale. ClearBank faced it across its container estate. Container lineage, deduplication and team ownership turned a backlog nobody could burn into a set of fixes with owners, and produced a 98% reduction in container vulnerabilities without adding headcount. The volume was solved by context first. Automation was worth its cost only on what was left.

6. Practical guidance for Monday morning

These apply with Phoenix or without it.

1. Change the metric. Report fully loaded cost and time per verified, deployed fix, from actionable finding to the scan that proves the vulnerable version is gone. Findings found per month tells you nothing anymore.
2. Separate the stages. Track blocked-the-exploit, passed-developer-tests, merged, released and running-in-production as distinct numbers. Most programs only see the first and the last, and confuse them.
3. Inventory what is exposed and consequential first. The freezer controllers were internet-facing management interfaces with known flaws. Exposure plus authority to change a physical process outranks any CVSS score.
4. Sort the backlog by fix and by layer. Build file, image layer and base image need different fixes and usually different owners. One base-image rebuild can close dozens of findings with no model call.
5. Turn your top recurring finding classes into agent rules this week. Pick the five most common confirmed CWEs in your backlog and write them into the rule files your coding agents already read.
6. Move the finding into the session. Measure the time between an agent’s commit and the moment an engineer sees the finding. If the median is days, the assistant is paying to rediscover its own work.
7. Keep a person on the merge and let the scanner close it. Supervised AI patches get merged. Unreviewed ones fail developer tests a third of the time.

Next steps

• Read the control framework behind this post: Close the Tap, Burn the Backlog.
• See how Green AI Remedy turns a prioritised selection into a reviewed pull request, with the cost on screen before anything runs: Green AI Remedy is generally available.
• See how Purple Hook hands the fix to the coding assistant inside the session: Purple Hook is generally available.
• Book a demo and bring your backlog. We will show you how many findings collapse into how many fixes.

References

1. Anthropic. Coordinated vulnerability disclosure dashboard. Snapshots of 2 October and 2 November 2026.
2. Anthropic. Project Glasswing: initial update. May 2026.
3. OpenAI. A thousand fewer paths to root. November 2026.
4. VulnCheck. State of Exploitation 1H-2026. 2026.
5. The Register. Second Anthropic-linked vulnerability exploited in the wild: Rejetto HFS CVE-2026-61500. 3 October 2026.
6. Le, Shi and Xing, Northwestern University. On the Reliability of LLM-Based Vulnerability Patching Benchmarks. arXiv, October 2026.
7. Trail of Bits. 1Password’s AI patching benchmark is misleading. 15 September 2026.
8. Daniel Stenberg. The pressure. 26 May 2026.
9. Daniel Stenberg. Do minor curl vulnerabilities in the open. 20 October 2026.
10. IPinfo. France’s supermarket fridges were vulnerable online for months. October 2026.