Google Big Sleep

What Big Sleep is

Big Sleep is a vulnerability research agent built jointly by Google DeepMind and Google Project Zero. Google’s own words, from the Cloud CISO Perspectives post opened in full: “Developed by Google DeepMind and Google Project Zero, Big Sleep can help security researchers find zero-day (previously-unknown) software security vulnerabilities” (CONFIRMED, verbatim). Its lineage is Project Naptime, which gave a language model the tooling a human researcher uses, a code browser, a debugger, a Python interpreter for building candidate inputs and a reporting step; Naptime became Big Sleep when DeepMind and Project Zero merged the effort (CONFIRMED, Project Zero post opened 19 September 2026).

The operating pattern visible in the artefacts is agentic rather than fuzz-driven. A fuzzer mutates inputs and waits for a sanitiser to trip; Big Sleep reads source, forms a hypothesis about a reachable flaw, then builds and runs an input that proves it. The CVE descriptions Google filed as CNA read exactly like that. From CVE-2025-59729, on FFmpeg’s DHAV parser: “When parsing the header for a DHAV file, there’s an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer” (CONFIRMED, verbatim from the record). That is a root-cause narrative with a reproduction path, the output shape of a report written for a maintainer. Google’s stated posture is that the agent has a human expert in the loop before reporting, while each vulnerability was found and reproduced by the agent without human intervention (SINGLE, August 2025 statement read as indexed content).

The October 2024 SQLite find

The register’s origin point is a stack buffer underflow in SQLite’s seriesBestIndex. Google’s Project Zero post of 1 November 2024, opened on 19 September 2026, describes the flaw as a write into a stack buffer with a negative index when handling a query with a constraint on the rowid column, reports that the project fixed it the same day, and states: “We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software” (CONFIRMED, verbatim). The bug was caught before release and never needed a CVE, so it sits on the register as an unnumbered entry.

Eighteen CVE records name it

A GitHub code search for the exact phrase “Big Sleep” across the CVEProject/cvelistV5 mirror returned 18 records on 11 September 2026, and every one was fetched and parsed from the raw mirror, then re-opened independently on 12 September (CONFIRMED). By project: FFmpeg 7, QuickJS 7, SQLite 1, curl 1, libxslt 1, WebKitGTK 1. By credit shape: fifteen name Google Big Sleep as sole finder, one names the Threat Analysis Group with Big Sleep assistance, and two are Red Hat acknowledgements worded “Red Hat would like to thank Google Big Sleep for reporting this issue” (CONFIRMED, every credits array read). Fifteen of the eighteen are Google’s own CNA records; CVE-2025-9086 is assigned by curl and the two 2026-era records by Red Hat, which suggests Big Sleep’s newer output reaches the corpus through the projects it reports to.

The ledger clusters, and the clustering is itself evidence of method. All seven QuickJS records share a datePublic of 24 July 2025 and the seven FFmpeg records run 21 July, 21 July, 27 July, 4 August, 4 August, 4 August and 20 August 2025, the signature of a campaign pointed at one codebase (CONFIRMED by parse). One record carries a title that looks wrong: CVE-2025-62495’s CNA title duplicates CVE-2025-62494’s, “Type confusion in string addition in QuickJS”, while its description is the libregexp bytecode integer overflow; the description is right and the upstream title is the duplicate (CONFIRMED).

The flagship record credits a person with the agent’s help

CVE-2025-6965 is the result Google leads with: an integer truncation in SQLite before 3.50.2, CVSS 4.0 7.2, published by Google as CNA on 15 July 2025 with a date public of 27 June (CONFIRMED, record opened). Google’s framing, from the Cloud CISO post: “Through the combination of threat intelligence from the Google Threat Intelligence Group (GTIG) and the Big Sleep AI agent, we were recently able to identify a critical SQLite vulnerability known only to threat actors that was imminently going to be used, and actually cut it off beforehand”, and “We believe this is the first time an AI agent has been used to directly foil efforts to exploit a vulnerability in the wild” (CONFIRMED, verbatim). The credit field carries a detail the announcements compress: “Vlad Stolyarov of Google’s Threat Analysis Group, with assistance from Google Big Sleep” (CONFIRMED, verbatim). So the flagship find is human-plus-agent and the routine finds are agent-first, which is a stronger statement about the programme than either framing alone.

Seven more sit in Apple’s and Google’s own advisories

Apple and Chrome, as CNAs, put the credit in their own advisory and leave the CVE record’s credits array empty, so the register carries those rows on the advisory tier. Apple’s page for Safari 26.1, released 3 November 2025, credits “Google Big Sleep” on CVE-2025-43429, 43430, 43431, 43433 and 43434, and credits CVE-2025-43432 of the same date to Hossein Lotfi of the Trend Micro Zero Day Initiative, which is why the sixth identifier in the range stays out of the block (CONFIRMED, raw page read 19 September 2026). Chrome’s Stable Channel Update of 26 August 2025 reads “Critical CVE-2025-9478: Use after free in ANGLE. Reported by Google Big Sleep on 2025-08-11”, and the update of 19 August 2025 reads “CVE-2025-9132: Out of bounds write in V8. Reported by Google Big Sleep on 2025-08-04” (CONFIRMED, both pages read as raw HTML). One caution for the method: a fetch tool’s summary of the Safari page assigned the 43434 credit to the ZDI researchers, which the raw page contradicts; the raw page is what the register follows.

The count is a floor

A CVE enumeration is a floor. Google states that publicly disclosed Big Sleep findings live on its own issue tracker, and that tracker was unreachable from this desk, so the programme’s own total is UNVERIFIED here. Three counted milestones sit outside the ledger: the first announced batch of 20 flaws in August 2025, described as mostly FFmpeg and ImageMagick (SINGLE, no ImageMagick record credits Big Sleep in the mirror); Google’s statement that Gemini 3.5 Flash Cyber, running inside Big Sleep, found 55 unique confirmed V8 issues (CONFIRMED in-house); and an early-2026 Chrome harness described as running “with higher efficiency and lower false positives” (SINGLE, the page unopened). The defensible statement is that at least 18 CVE records name Big Sleep, seven advisories credit it, and the programme’s own tally is higher by an amount only its tracker will settle.

Disclosure runs on the Project Zero clock

Project Zero’s rules bind Big Sleep output. The OSS-Fuzz disclosure guidelines state the deadline verbatim: “After notifying project authors, we will open reported issues to the public in 90 days, or after the fix is released (whichever comes earlier)” (CONFIRMED, opened). That posture explains the shape of the ledger: the FFmpeg records carry dates public in July and August 2025 against CVE publication on 6 October 2025, a spread of roughly 77 to 90 days, exactly where a 90-day deadline puts them. In July 2025 Project Zero added a Reporting Transparency trial, publishing the vendor, product, filing date and deadline within about a week of a report (SINGLE, announcement on an unopened host).

The receiving end is in the record too. curl accepted CVE-2025-9086 with Big Sleep as finder and Daniel Stenberg as remediation developer, its third reference a HackerOne report (CONFIRMED). In November 2025 FFmpeg maintainers publicly called a Big Sleep report against the LucasArts Smush decoder “CVE slop” and argued that trillion-dollar companies running AI over volunteer code should arrive with fixes and funding (SINGLE); the find was real and was patched, and the dispute is over the economics of inbound AI-generated reports. Bounty paid on every Big Sleep row: none published, because the programme reports upstream to projects that pay nothing, which is the reading the register carries in its bounty column.