Who Found the Bug? Why the CVE Record Cannot Say 'An AI Did It', and What That Breaks

A vendor tells you their AI found forty vulnerabilities last quarter. You want to check it. The obvious move is to go to the authoritative record, the CVE List, and read the credits. So we did that, across every AI-linked CVE record we could verify, and the result is worth knowing before your next vendor meeting: the CVE Record Format has no field that says an autonomous agent found the bug. It can name people. It can name organizations. It can even name tools. It cannot record who or what did the finding in a way you can query.

That is not a complaint about a schema. It is the reason this entire market is hard to evaluate. Every claim you have read about AI-discovered vulnerabilities has been squeezed through a free-text field whose contents are entirely at the discretion of the numbering authority, and different authorities fill it in completely differently. Six records we pulled directly from the CVE Services API use six different conventions for the same underlying question.

A classification note first, because this post sits next to a lot of scarier ones. Every vulnerability named on this page is Category C, a product vulnerability in software, found and reported through coordinated disclosure and patched. None is Category A, a guardrail bypass or jailbreak. None is Category B, an external attacker misusing an AI platform against third parties. None is Category D, a corporate breach of the vendor itself. And none is Category E, which we use for a model-initiated action during an authorized evaluation, where the vendor's own model acts against a real third party with no attacker involved. This page is about paperwork and provenance, not intrusions.

The schema problem: what the CVE credits field can and cannot record

Pull the CVE Record Format schema and read the definition of credits. It describes itself as acknowledging people, organizations or tools involved in researching, discovering, remediating or helping with a CVE (CVE Program schema). Each credit entry has a free-text value field of up to 4,096 characters, an optional user UUID, and an optional type drawn from a fixed list: finder, reporter, analyst, coordinator, remediation developer, remediation reviewer, remediation verifier, tool, sponsor, other.

So there is a tool type. That is the part most commentary gets wrong in the other direction. But read what it is for: the schema defines tool as naming tools used in vulnerability discovery or identification. It is a supporting credit. finder, defined as the party that identifies the vulnerability, is a separate type and it is the default. There is no combination of these fields that expresses "this was found by an autonomous system with no human in the loop", and there is no flag anywhere else in the record that carries it either.

The consequence is that the only place the distinction can live is the free-text string. And nobody has to write it there. Here is what six records we fetched from the CVE Services API actually contain.

Six records. Six conventions. Not one of them used the schema's dedicated tool credit type. If you are building a dashboard that counts AI-discovered CVEs, you are not counting a field. You are parsing prose, and only the prose that somebody chose to write.

Google's own two records, under three months apart: assisted versus solo

The cleanest proof that the distinction is real, and that it depends entirely on the authority's discretion, comes from one programme filing two records in one quarter.

For the SQLite memory-corruption issue CVE-2025-6965, published 15 July 2025, Google as numbering authority recorded a single finder credit naming Vlad Stolyarov of Google's Threat Analysis Group, with assistance from Google Big Sleep (CVE Program). A human is the finder. The agent assisted. The record scores it CVSS 4.0 base 7.2 and directs users to SQLite 3.50.2.

For the FFmpeg use-after-free CVE-2025-59734, published 6 October 2025, the same authority recorded a single finder credit reading, in full, "Google Big Sleep" (CVE Program). No human name at all. The fix is FFmpeg 8.0.

Same programme, same year, under three months between publication dates, two genuinely different attribution buckets. The distinction survived only because Google chose to write it into free text on both occasions. Had Google written "Google Big Sleep" on both, or a human name on both, nothing in the record would have been false and no consumer of the data could have told. That is the whole problem in two records.

FreeBSD CVE-2026-4747: two primary sources, two different stories

CVE-2026-4747 is a stack-based buffer overflow (CWE-121) in FreeBSD's RPCSEC_GSS packet validation, published 26 March 2026 by FreeBSD as numbering authority. It affects FreeBSD 15.0-RELEASE before p5, 14.4-RELEASE before p1, 14.3-RELEASE before p10 and 13.5-RELEASE before p11. FreeBSD's finder credit reads: Nicholas Carlini using Claude, Anthropic (CVE Program).

Anthropic's own write-up describes the same bug very differently. It says Mythos Preview fully autonomously identified and then exploited a 17-year-old remote code execution vulnerability in FreeBSD, and defines "fully autonomously" as meaning no human was involved in discovery or exploitation after the initial request to find the bug (Anthropic, 9 April 2026).

Both are primary. Both are on the record. They do not say the same thing, and the disagreement does not stop at the credit. Anthropic's page describes the flaw as reachable starting from an unauthenticated user anywhere on the internet. FreeBSD's own CVE record says that for the kernel path, remote code execution is possible by an authenticated user able to send packets to the kernel's NFS server while the relevant module is loaded. FreeBSD does note in the same description that the signature-validation routine itself can be triggered without the client authenticating first, and that a userspace RPC server with the affected library loaded would be exposed to any client able to send it packets, while adding that it is not aware of any such application in the FreeBSD base system.

We are not going to resolve that for you, because neither source is subordinate to the other. What a defender should take away is narrower and more useful: the vendor that owns the code scoped the kernel exposure to an authenticated sender, the finder scoped it to anyone on the internet, and the CVSS 3.1 vector attached to the record by CISA's enrichment programme reads PR:L, privileges required low rather than none, giving 8.8 High. If you are prioritizing this in your own estate, prioritize it against the vendor's scoping and your own NFS exposure, not against the finder's headline.

OpenSSL's January 2026 batch: twelve CVEs, and no mention of AI anywhere

On 27 January 2026 OpenSSL published twelve advisories in one coordinated release. We parsed OpenSSL's own vulnerabilities page and pulled every "Found by" line in that batch (OpenSSL). All twelve name humans. The batch credits five distinct parties in total: four Aisle Research researchers, with Stanislav Fort named on eight of the twelve, plus three colleagues. One entry, CVE-2025-11187, additionally credits Hamza of Metadust alongside two Aisle Research names. Severity spread is one High, one Moderate and ten Low.

The word "AI" does not appear anywhere on that page. Not once, across the full history of OpenSSL advisories rendered there.

AISLE's own post, published 26 January 2026, states that its autonomous analyzer found all twelve CVEs in the January 2026 coordinated release (AISLE). The post quotes the OpenSSL Foundation's CTO describing the release as fixing twelve issues all disclosed to OpenSSL by AISLE, which is a statement about who reported, not about what did the finding. And OpenSSL's own record qualifies the tidy "12 out of 12" framing in one place: CVE-2025-11187 carries a co-credit to a researcher outside AISLE.

There is a second lesson buried in the follow-up. AISLE's April 2026 post reports that CVE-2026-28386 was independently discovered by both AISLE and Anthropic, with Anthropic's Alex Gaynor reporting the same issue 63 days later, and states that OpenSSL rated it Low while NVD scored it 9.1 Critical (AISLE). We checked. OpenSSL does rate it Low. But NVD's primary CVSS 3.1 score is 7.5 High; the 9.1 Critical in that record is a secondary score contributed by CISA's enrichment programme (NVD). Three organizations, three severities, on one bug. And the CVE record for it carries no finder credit at all: OpenSSL filed three reporter credits and three remediation developer credits, all human names (CVE Program).

Redis CVE-2026-23479: what the advisory's own credit section says

Redis published a multi-CVE advisory covering CVE-2026-23479 alongside four siblings, with a section headed "Who gets the credit?". For CVE-2026-23479 it credits independent researchers Team Xint Code, naming Tim Becker, Jacob Newman and Juno IM (Redis).

Three named humans. We searched the full advisory text for any mention of AI, autonomy or a vendor tool name: zero matches. The CVE record itself, assigned through GitHub as numbering authority, contains no credits container at all (CVE Program).

This bug is widely retold as an autonomous AI discovery. The authoritative record does not support that reading, and neither does the vendor advisory. What both support is a human-credited finding reported through a published process; any AI-assistance element comes from the finding team's own tooling disclosure, not from Redis and not from the CVE record. Redis also notes in the same section that a number of the vulnerabilities in the batch were identified at a live-hacking event, which is a statement about the batch and not about any single CVE in it. If you want the fuller build-out of that distinction across the year, our AI-attributed CVE tracker keys every row to a credit bucket, and the Exim Dead.Letter analysis walks the case where a human found the bug and the AI only raced the follow-on work.

Anthropic's Project Glasswing: the numbers, and which denominator you are being shown

Project Glasswing was announced on 7 April 2026, bringing together Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA and Palo Alto Networks, with access extended to over 40 additional organizations and up to $100M in usage credits committed (Anthropic).

The published numbers are the most useful public dataset on this question, precisely because Anthropic shows the whole funnel rather than one headline. From its 22 May 2026 update: Mythos Preview has found what it estimates are 6,202 high or critical severity vulnerabilities across more than 1,000 open-source projects, out of 23,019 in total. Of those, 1,752 have been assessed by one of six independent security research firms, or in a small number of cases by Anthropic itself, and 90.6 percent (1,587) proved to be valid true positives, with 62.4 percent (1,094) confirmed as high or critical (Anthropic).

The disclosure dashboard, snapshotted the same day, carries the downstream half: 1,596 vulnerabilities disclosed across 281 open-source projects, 97 patched to Anthropic's knowledge, and 88 of those assigned a CVE record or a GitHub Security Advisory (Anthropic).

Note the ratio: 23,019 at the top, 88 at the bottom. A vendor quoting the first number and a vendor quoting the last are describing the same programme.

There is one more wrinkle worth printing. VulnCheck's first-half 2026 analysis states that Anthropic reported more than 23,000 findings through Project Glasswing but only 126 have resulted in published CVEs (VulnCheck). Anthropic's own dashboard says 88 with a CVE or GHSA as of 22 May 2026. Both are primary sources, they count slightly different things over slightly different windows, and we are not picking one. The point is that even the bottom of the funnel is not a single agreed number.

The five checks that separate an AI-found bug from an AI-assisted human find

None of this requires special access. All of it can be done from a browser in a few minutes.

Check three deserves a worked example, because it is the one buyers miss. Microsoft's CVRF v3.0 API acknowledges XBOW for CVE-2026-21536, CVE-2026-32191 and CVE-2026-32194 (MSRC). The CVE records for those same IDs carry no credits container, so the acknowledgment lives in Microsoft's advisory feed rather than in the CVE List. And in both places the credit names a company, not an agent. Two of the three acknowledgment strings even render as "XBOW with XBOW", because Microsoft's template pairs a researcher with a tool and here both slots hold the same entity. Nothing in either record distinguishes that company's humans from its software. That is the honest ceiling on what a discovery credit can tell you.

What this means when you are buying

A discovery credit tells you that something was found and reported. It does not tell you how much human judgement went into it, how many false positives sat around it, or whether the finder's severity framing matches the vendor's.

Two data points should calm the temperature. First, the triage bottleneck is human even at the frontier: Anthropic's dashboard is explicit that independent human review is the rate-limiting step, which is why 23,019 becomes 88. Second, exploitation has not followed the discovery curve. VulnCheck reports that of 1,061 vulnerabilities attributed to AI-assisted discovery in the first half of 2026, 14, or 1.3 percent, were confirmed exploited in the wild, roughly matching the overall rate for all vulnerabilities in the period; its stated conclusion is that AI-discovered vulnerabilities are not inherently more likely to be exploited, and that AI mainly increases volume (VulnCheck).

So the right question to put to a vendor is not "how many did your AI find". It is: show me the CVE IDs, show me the credit type on each, show me your findings-to-confirmed ratio and who confirmed it, and tell me which of those findings a human validated before it reached me. That last one is the operative distinction in our own delivery: Stingrai's Snipe runs as an autonomous agent against web applications, hunting the complex authorization and business-logic classes rather than stopping at known-class noise, and our Hybrid engagements put a senior human on every finding before it lands in your report. Stingrai is a CREST-accredited penetration testing service provider at firm level, founded in 2021 and operating from Toronto and London, with 18 published CVEs of our own and 5.0 out of 5.0 across 19 Clutch reviews. Scope and packages are on our pricing page, and the questions we think belong in a procurement conversation are collected in questions to ask an AI pentest vendor and our AI pentest benchmark results.

The CVE record will get better at this eventually. Until it does, the credits field is prose, and prose has to be read.

Frequently Asked Questions

Has AI actually discovered any real vulnerabilities?

Yes, and at least one case is recorded that way by the numbering authority itself. Google's CVE record for the FFmpeg use-after-free CVE-2025-59734 lists a single finder credit reading "Google Big Sleep", with no human name attached (CVE Program). Many other claims are real findings but credited to humans who used AI tools, which is a different thing, and the record usually cannot tell you which you are looking at.

Did Google's Big Sleep find the SQLite zero-day on its own?

No, not according to Google's own record. CVE-2025-6965 in SQLite carries one finder credit naming Vlad Stolyarov of Google's Threat Analysis Group, with assistance from Google Big Sleep (CVE Program). Compare that with the FFmpeg bug CVE-2025-59734, filed by the same authority under three months later, where the finder credit is "Google Big Sleep" alone. The same programme produced both buckets, and only the free-text wording tells them apart.

Who is credited for the FreeBSD CVE-2026-4747 vulnerability?

FreeBSD's CVE record lists a single finder credit naming Nicholas Carlini using Claude, Anthropic (CVE Program). Anthropic's own write-up describes the same bug as identified and exploited fully autonomously by Mythos Preview, with no human involved after the initial request (Anthropic). The two primary sources also disagree on preconditions: Anthropic describes it as reachable from an unauthenticated user on the internet, while FreeBSD's record says kernel code execution is possible by an authenticated user able to send packets to the NFS server.

Did AI find the twelve OpenSSL vulnerabilities?

AISLE says its autonomous analyzer found all twelve CVEs in OpenSSL's January 2026 coordinated release (AISLE). OpenSSL's own vulnerabilities page credits only humans across that batch, naming four Aisle Research researchers, and never mentions AI anywhere (OpenSSL). One of the twelve, CVE-2025-11187, additionally credits Hamza of Metadust, so the clean "12 out of 12" framing is qualified by OpenSSL's own record.

Was the Redis RCE found by an AI?

Not according to Redis. The advisory's "Who gets the credit?" section attributes CVE-2026-23479 to independent researchers Team Xint Code, naming Tim Becker, Jacob Newman and Juno IM, and the advisory never mentions AI or any autonomous tool (Redis). The CVE record itself carries no credits container at all. Any AI-assistance element in this find comes from the finding team's own tooling disclosure rather than from the vendor advisory or the CVE record, so it should not be filed as an autonomous discovery.

How many CVEs has Anthropic's Project Glasswing produced?

Anthropic's disclosure dashboard, as of 22 May 2026, reports 1,596 vulnerabilities disclosed across 281 open-source projects, 97 patched, and 88 of those assigned a CVE record or a GitHub Security Advisory, out of 23,019 raw findings (Anthropic). VulnCheck's first-half 2026 analysis instead states that only 126 of more than 23,000 Glasswing findings resulted in published CVEs (VulnCheck). Both are primary sources counting slightly different things over different windows, so quote whichever you use with its date and definition attached.

How do I check who is credited for a CVE?

Fetch the record directly from the CVE Services API at https://cveawg.mitre.org/api/cve/ followed by the CVE ID, and read the credits array in the CNA container. Pay attention to the type on each entry, because finder is the discovery credit while reporter, analyst and remediation developer are not. Then check the vendor's own advisory channel separately, since credits frequently appear there and not in the CVE record, as with Microsoft's CVRF feed (MSRC).

Are AI-found vulnerabilities more likely to be exploited?

The available data says no. VulnCheck reports that of 1,061 vulnerabilities attributed to AI-assisted discovery in the first half of 2026, 14, or 1.3 percent, were confirmed exploited in the wild, roughly matching the overall exploitation rate for all vulnerabilities in the same period (VulnCheck). Its stated conclusion is that AI-discovered vulnerabilities are not inherently more likely to be exploited, and that AI primarily increases the volume of vulnerabilities found.

References

1. CVE Program. CVE Record Format schema. https://raw.githubusercontent.com/CVEProject/cve-schema/main/schema/CVE_Record_Format.json. Definition of the credits array, its free-text value field and the ten-value type enum including finder and tool.

2. CVE Program. CVE-2025-6965. https://cveawg.mitre.org/api/cve/CVE-2025-6965. SQLite record assigned by Google; one finder credit naming a Threat Analysis Group researcher with assistance from Google Big Sleep; CVSS 4.0 base 7.2; fixed in 3.50.2.

3. CVE Program. CVE-2025-59734. https://cveawg.mitre.org/api/cve/CVE-2025-59734. FFmpeg SANM use-after-free assigned by Google; one finder credit reading "Google Big Sleep"; fixed in 8.0.

4. CVE Program. CVE-2026-4747. https://cveawg.mitre.org/api/cve/CVE-2026-4747. FreeBSD RPCSEC_GSS stack overflow (CWE-121); finder credit naming a human researcher using Claude; description scoping kernel code execution to an authenticated sender; CVSS 3.1 8.8 supplied by CISA enrichment.

5. Anthropic. Claude Mythos Preview. 9 April 2026. https://www.anthropic.com/research/mythos-preview. Anthropic's account of CVE-2026-4747 as a fully autonomous identification and exploitation, and its definition of that term.

6. OpenSSL. Vulnerabilities. https://openssl-library.org/news/vulnerabilities/. Source for every "Found by" credit in the 27 January 2026 twelve-CVE batch and the 7 April 2026 release, and for the absence of any AI mention.

7. AISLE. AISLE Discovered 12 out of 12 OpenSSL Vulnerabilities. 26 January 2026. https://aisle.com/blog/aisle-discovered-12-out-of-12-openssl-vulnerabilities. The finder-side claim for the January 2026 batch.

8. AISLE. AISLE Discovers 20 OpenSSL Zero-Days in 6 Months. 24 April 2026. https://aisle.com/blog/aisle-discovers-20-openssl-zero-days-in-6-months. The April 2026 release, the independent co-discovery of CVE-2026-28386 with Anthropic, and the finder's severity comparison.

9. CVE Program. CVE-2026-28386. https://cveawg.mitre.org/api/cve/CVE-2026-28386. OpenSSL-assigned record using three reporter and three remediation developer credits and no finder credit.

10. NVD (NIST). CVE-2026-28386. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-28386. Primary CVSS 3.1 base 7.5 High from NVD, secondary 9.1 Critical from CISA enrichment.

11. Redis. Security advisory: CVE-2026-23479 and related. https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/. The "Who gets the credit?" section naming three human researchers for CVE-2026-23479, with no AI or tool mention anywhere in the advisory.

12. CVE Program. CVE-2026-23479. https://cveawg.mitre.org/api/cve/CVE-2026-23479. GitHub-assigned record containing no credits container.

13. Anthropic. Project Glasswing. 7 April 2026. https://www.anthropic.com/glasswing. Launch partners, the extension to over 40 additional organizations, and the committed usage credits.

14. Anthropic. Project Glasswing: an initial update. 22 May 2026. https://www.anthropic.com/research/glasswing-initial-update. The 6,202 estimated high or critical findings out of 23,019, the 1,752 independently assessed, and the 90.6 percent true-positive figure.

15. Anthropic. Coordinated vulnerability disclosure dashboard. Snapshot 22 May 2026. https://red.anthropic.com/2026/cvd/. 1,596 disclosed across 281 projects, 97 patched, 88 carrying a CVE or GHSA, and the statement that human triage is the rate-limiting step.

16. VulnCheck. State of Exploitation, 1H 2026. https://www.vulncheck.com/blog/state-of-exploitation-1h-2026. The 1,061 AI-attributed vulnerabilities with 14 confirmed exploited, and the separate count of 126 Glasswing findings resulting in published CVEs.

17. Microsoft (MSRC). CVRF v3.0, March 2026. https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/2026-Mar. Acknowledgments naming XBOW for CVE-2026-21536, CVE-2026-32191 and CVE-2026-32194.

18. CVE Program. CVE-2026-21536. https://cveawg.mitre.org/api/cve/CVE-2026-21536. Microsoft-assigned record for the Devices Pricing Program remote code execution issue, containing no credits container.

19. CVE Program. CVE-2026-32191. https://cveawg.mitre.org/api/cve/CVE-2026-32191. Microsoft-assigned Bing Images record, containing no credits container.