The open-source AI patch gap: discovery is outrunning remediation

What is this?

Through the first half of 2026, AI systems began reporting vulnerabilities in open-source software at machine speed — and the humans who maintain that software cannot patch nearly as fast. On July 2, 2026, Help Net Security summarised a Tuskira study of Anthropic’s Claude Mythos Preview coordinated-disclosure program, which over roughly nine weeks this spring combed more than 23,000 open-source code paths and routed verified findings to the projects that own them. The program reported 1,596 verified vulnerabilities across hundreds of projects. Six external security firms triaged the findings before they reached maintainers, and confirmed a 90.8% true-positive rate on the subset they checked — so the volume reflects real bugs, not model noise.

The problem is what happens next. Discovery ran at about 25 verified vulnerabilities a day; credited repairs moved at closer to 1.5 a day. Tuskira distils that imbalance into a single figure — a discovery-to-remediation ratio of roughly 16.5 to one — and calls the widening backlog a “vulnerability deficit.” This is not an attack. It is a structural shift in the disclosure-and-patch economy, and it changes the planning assumptions for anyone who ships software built on open-source dependencies. We cover it because the defensive implications are concrete and immediate.

How it works

The gap is the sum of several delays, each ordinary on its own. Maintainers are responsive at the front door: the median time to acknowledge a report came in near a fifth of a day. But acknowledgement and repair sit far apart. At the snapshot, only about 6% of disclosed vulnerabilities carried an upstream patch (a figure the researchers treat as a lower bound, since some fixes ship quietly), and roughly 95% had no public advisory at all.

Downstream, more delay accumulates. Advisory databases need time to ingest a fix, commercial scanners need time to refresh, and enterprises need time to test a patch before it touches production. Because most vulnerability-management programs only begin serious work once a public advisory exists, the span from private disclosure to a deployed enterprise fix runs, in the report’s structural estimate, three to five months. Patch validation alone commonly takes two to six weeks for ordinary language packages — and longer for embedded, cryptographic, or regulated components — a stretch during which the flaw may already be public and exploit tooling may circulate.

One upstream finding also rarely stays one alert. A single ImageMagick flaw can propagate to eighteen or more downstream package variants, and distribution rebuilds carry source-only fixes across many separate feeds. The number that matters to a defender is every reachable affected instance in production, which climbs higher than the upstream tally suggests.

The supply side of this asymmetry is now being industrialised. On June 22, 2026, OpenAI launched Patch the Planet, a Daybreak initiative built with Trail of Bits (and HackerOne and Calif) that pairs frontier models and its Codex Security tooling with expert human review, explicitly to reduce maintainer burden rather than add to it — engineers reproduce, deduplicate, re-score, and patch findings before they ever reach a maintainer. SecurityWeek reported the same week that OpenAI is deliberately refocusing from discovery toward getting patches deployed. The recognition is telling: the discovery problem is now considered easier than the remediation one.

Why it matters

The exposure window is widening, not closing. For years the implicit deal was that most bugs stayed undiscovered, giving under-resourced projects slack. AI erodes that slack: bugs surface faster than they are fixed, so at any moment more flaws are known-but-unpatched than before. OSS-Fuzz logged over 13,000 vulnerabilities across nine years; a single AI program reached a meaningful fraction of that corpus in a sliver of the time, and more discovery efforts are coming online.

The CVE feed is arriving late. With ~95% of these findings carrying no public advisory at the snapshot, waiting for a CVE to trigger action means acting after the useful signal has already appeared — in upstream commits, transparency-log changes, and the security firms credited on advisories.

Volume is not the same as priority. Two dozen new findings a day, per program, will swamp any team that treats every report as an emergency. Without a way to decide what actually matters in your environment, the deficit becomes unmanageable noise.

Defenses

The specific numbers come from one program, but the operating changes generalise to anyone consuming or maintaining open source.

1. Operate at discovery cadence, not only remediation cadence. Assume that known-but-unadvised vulnerabilities in your dependencies now outnumber the ones with CVEs. Watch upstream commits, release notes, and transparency logs for your critical dependencies rather than waiting on advisory databases.

2. Treat patching as a decision problem, not a queue. Tuskira’s model routes each finding through four questions: does the vulnerable code path actually run in production, who can reach the exposed instance, is there any sign of active exploitation, and do existing controls already block it. In their worked example, a critical nginx flaw that appeared to threaten 1,200 instances narrowed to three that were public, unauthenticated, and lacking a web application firewall. Emergency effort goes to those; the rest move through staged lanes or documented deferral.

3. Know your dependency inventory before you need it. A current software bill of materials, with reachability and exposure data, is what turns a flood of findings into a short list. You cannot triage what you cannot see.

4. Add compensating controls to shorten your effective window. Where a patch will take weeks to validate, reduce exposure in the meantime: restrict network reachability, add WAF or input-validation rules, and tighten authentication on internet-facing instances so a public flaw is not also an unauthenticated one.

5. For maintainers: insist on validated, deduplicated, human-reviewed reports. The Patch the Planet model — researchers reproduce evidence, remove duplicates, reassess severity, and draft patches before anything reaches the maintainer — is the pattern to demand from any AI-assisted disclosure program. Unfiltered model output adds to the backlog it claims to solve.

Status

Item	Reference	Date	Notes
”AI patch gap” analysis	Help Net Security / Tuskira	2026-07-02	1,596 verified vulns; ~16.5:1 discovery-to-repair ratio
Patch the Planet launched	OpenAI / Trail of Bits	2026-06-22	AI + expert review to help maintainers patch OSS
Refocus on remediation	SecurityWeek	2026-06-23	OpenAI Daybreak shifts emphasis from discovery to patching

The one-line version: AI has made finding open-source vulnerabilities cheap and fast, while fixing and deploying them remains slow and human — so the number of known-but-unpatched flaws in the software you depend on is growing. The durable takeaway is defensive: stop waiting on the CVE feed, inventory what actually runs in production, and prioritise by exploitability and exposure rather than by report count.