AI models are now finding real vulnerabilities in widely used software, and the public record barely shows it. Both CVE records and OSV advisories have a structured way to say "a tool found this": a credit type called tool. In the 2,544 CVE records added between 12:00 UTC on 13 October and 15:49 UTC on 14 October 2026, two used it. Everywhere else, AI involvement shows up as free text in a finder's name, a paragraph at the bottom of an advisory, or not at all.
This post is for security teams who consume advisories and for maintainers and CNAs who write them. It shows what the records say today, why the gap matters to the people patching, and the small change that would fix it.
The short answer
AI-assisted vulnerability discovery is real and growing, but advisories record it inconsistently, so nobody downstream can count it, filter on it or plan around it. The CVE record format and the OSV schema both already define a tool credit type. Maintainers and CNAs should credit the AI system as a tool alongside the people who found, verified and reported the bug. Consumers should start treating AI-heavy research programmes as a signal that more fixes are coming to the same project soon.
What two days of CVE records show
We pulled every CVE record added to the CVE List between 12:00 UTC on 13 October and 15:49 UTC on 14 October 2026, 2,544 records in all, 1,407 of them from Microsoft's October release. Of those, 610 credit anyone at all. Across those credits, finder appears 537 times, reporter 140, coordinator 73, remediation developer 38 and analyst 5. tool appears twice, in two Libreswan records that credit "Claude (Anthropic)" as the tool and an ADA Logics researcher as the reporter.
Other records from the same window describe AI involvement in other ways:
- curl's record for an HTTP/2 use-after-free (CVE-2026-92392) lists "Anthropic" and a researcher "with Claude" as finders.
- Two Xen records (CVE-2026-79610 and 79611) have a single finder credit that is a sentence: the issue "was discovered by Claude Opus" and diagnosed by a named engineer.
- A Red Hat record thanks "Anthropic Research" in an untyped credit.
- The Podman record we covered today (CVE-2026-94603) has no credits at all. Its GitHub advisory says it was found by ADA Logics "using Anthropic's Claude models".
All four are accurate. None of them is machine-readable as "a tool was involved". This script shows the difference on four of those records:
#!/usr/bin/env python3
"""Show how CVE records credit their finders, and flag AI tools credited outside the 'tool' type.
Usage: python3 credit_types.py CVE-ID [CVE-ID ...] (standard library only)"""
import json, re, sys, urllib.request
AI = re.compile(r"\b(Claude|Anthropic|GPT-?\d[\w.-]*|Codex|Gemini|Big Sleep|XBOW|LLM|AI[- ]assisted|AI agent)\b", re.I)
for cve in sys.argv[1:]:
with urllib.request.urlopen(f"https://cveawg.mitre.org/api/cve/{cve}", timeout=30) as r:
record = json.load(r)
credits = record["containers"]["cna"].get("credits") or []
print(f"{cve} ({record['cveMetadata']['assignerShortName']}, {len(credits)} credits)")
for c in credits:
value = " ".join(c.get("value", "").split())
note = " <- AI named, not typed 'tool'" if AI.search(value) and c.get("type") != "tool" else ""
print(f" {c.get('type') or '(no type)':<22} {value[:70]}{note}")
$ python3 credit_types.py CVE-2026-77206 CVE-2026-92392 CVE-2026-79610 CVE-2026-94603
CVE-2026-77206 (libreswan, 2 credits)
tool Claude (Anthropic)
reporter David Korczynski (ADA Logics Ltd)
CVE-2026-92392 (curl, 3 credits)
finder Luna with Claude <- AI named, not typed 'tool'
finder Anthropic <- AI named, not typed 'tool'
remediation developer Stefan Eissing
CVE-2026-79610 (XEN, 1 credits)
finder This issue was discovered by Claude Opus and diagnosed as a security i <- AI named, not typed 'tool'
CVE-2026-94603 (GitHub_M, 0 credits)
The same pattern in GitHub's advisory database
GitHub-reviewed advisories show the same thing over a longer period. We searched the text of every reviewed advisory in the crates.io, Go, Maven, npm, NuGet, Packagist and PyPI ecosystems (OSV export, downloaded 14 October 2026) for statements that AI helped find, reproduce or analyse the vulnerability, then removed false positives by hand, such as bugs in LLM-generated code.
| 2025 | 2026 (to 14 October) | |
|---|---|---|
| Reviewed advisories | 3,664 | 11,441 |
| Advisory text says AI helped find or analyse the bug | 8 | 54 |
| Of which, published 1 to 14 October 2026 | 16 |
That's under 1% of advisories, and it is certainly an undercount: disclosure is voluntary, and the phrasing varies so much that a text search misses some. A further 13 advisories in 2026 said AI only wrote the report, the proof of concept or the advisory text.
The phrasing tells its own story. We found "AI involvement disclosure" sections, "Disclaimer on the use of AI powered tools", "Provenance: found by an external automated code scan", "Written by an agent (Codex, GPT-5)", credits to "an AI agent developed by the GitHub Security Lab", and batches from named programmes: Google's Big Sleep, XBOW, Anthropic's coordinated disclosure programme and the "Patch the Planet" initiative, a Trail of Bits and OpenAI collaboration, which produced six vLLM advisories on 5 and 6 October. Every one of those is a reasonable way to disclose. Together they're impossible to query.
Why defenders should care
It would be easy to call this a bookkeeping problem. It isn't, for three reasons.
AI-driven research arrives in batches. A model pointed at a codebase tends to find several related bugs, and the fixes land close together. When one advisory for a dependency says it came from an AI research programme, the useful inference is that more may follow for the same project in the coming weeks. That's worth knowing when you plan an upgrade, and it's the kind of signal you can only act on if it's structured.
It's a quality signal, in both directions. Several of the advisories above say the finding was "manually reproduced" or "reviewed before submission". That's exactly what maintainers want to know, given how much unverified, AI-generated noise they receive. A tool credit next to a human finder or analyst credit says that a person stood behind the result.
Nobody can measure the trend without it. Volume is already a problem: GitHub reviewed roughly three times as many advisories in these ecosystems in 2026 as in 2025 (see our post on tracking CVE volume in 2026). How much of that growth comes from automated discovery is a question the data could answer, if it were recorded.
The fix is already in the schemas
No new standard is needed:
- CVE record format 5.x defines credit types
finder,reporter,analyst,coordinator,remediation developer,remediation reviewer,remediation verifier,tool,sponsorandother. - OSV has the same list in upper case, including
TOOL. - GitHub repository advisories support a
toolcredit type in their API, but every credit must be a GitHub account, so a model can only be credited if it has one. For now, the advisory text and the CVE record are the practical places to record it.
What we'd suggest:
- Maintainers and CNAs: credit the model or system as a
tool(for example, "Claude (Anthropic)" or "Big Sleep (Google)"), and credit the people asfinder,analystorreporteras appropriate. Libreswan's records are a good template. - Researchers: ask for that split when you report. Keep the human verification statement in the advisory text, because that's what maintainers read.
- Consumers: when you triage, read the credits. A
toolcredit from an active research programme is a reason to expect follow-up fixes in the same project.
The fair view
There are fair objections. Some researchers worry that labelling a finding as AI-assisted makes it look less credible, and maintainers can't verify the claim either way. Credits are also optional, and plenty of CVE records have none at all, AI or otherwise. A tool credit won't stop low-quality AI-generated reports, which are a separate and real burden on maintainers.
But the alternative is the current state: an accurate story told in a dozen incompatible ways, and a trend that matters to everyone who patches software but can't be measured. Using the field that already exists costs one line per record.
