Google says it fixed 1,072 security bugs in the two Chrome releases it shipped in June. That is more than the 1,036 it fixed across the previous 23 releases, covering roughly two years. Four weeks later, JFrog researcher Afek Berger published an audit of 55 vulnerability advisories that a newly created GitHub account had pushed into the CVE system over four days. Fifty-four were fabricated. One of them, CVE-2026-51302, sat in the NVD as a 9.8 CRITICAL and briefly carried a 10.0 from Red Hat.

Both piles are the output of language models pointed at C code. Most of the coverage read them as opposing evidence: AI is good for security, AI is bad for security, pick a side. They are the same result. What separates them is not the model. It is whether anything downstream was obliged to check.

The pitch

Doug Turner, Chrome's director of engineering, told TechCrunch that LLMs have "fundamentally shifted the economics of cybersecurity, transforming vulnerability discovery into an automated, industrial-scale operation", and that "by applying models like Gemini, we are preemptively fixing vulnerabilities, outpacing our adversaries and making Chrome safer with every update".

Take the first half at face value, because it is demonstrably true. Microsoft patched a record 570 flaws in a single July Patch Tuesday and credited its own AI use. Ryan Dewhurst of KEVIntel puts the current rate at roughly 200 new CVEs published per day. NIST clocked a 263% rise in CVE submissions between 2020 and 2025. Discovery has gone industrial and nobody serious disputes it.

The second half, safer with every update, is where the pitch and what I can verify come apart. Not for the reason sceptics usually give.

What actually separates the two piles

A Chrome memory-safety bug is decidable by a machine. Build the binary, feed the candidate input to it under AddressSanitizer, watch for a crash. That is a decision procedure. It costs CPU rather than judgment, it runs unattended, and it scales on roughly the same compute curve as the thing generating candidates. Google has had that infrastructure for years. What the models added was volume at the front of a pipeline that already had a cheap, automatic answer to "is this real?" waiting at the other end.

Now look at what JFrog had to do to check six advisories. Clone sqlite/sqlite. Check out three tags. Compile each release inside an isolated Docker container. Feed every advisory's proof-of-concept SQL verbatim into an ASan build. That is the identical procedure Google runs. The difference is purely one of sequence: Google runs it before a finding counts as a finding, and JFrog ran it weeks after the finding was already sitting in public databases scored 9.8.

The detail that should bother people is how little of that check was actually hard. CVE-2026-51296 cited a use-after-free at lines 3555 and 3575 of json.c. In the version named, json.c is 2,706 lines long. CVE-2026-51302 blamed a function, exprComputeOperands(), that did not exist in the release it was filed against. CVE-2026-51303 claimed a patch landed in 3.51.3; the diff between 3.51.2 and 3.51.3 touches src/expr.c not at all. Line count and grep would have rejected half the batch before a human read a sentence. The verification that was missing here was not scarce expert attention. It was two shell commands that nobody in the chain was required to run.

The step that would have caught it was retired in April

In April 2026, NIST changed how the NVD works. Enrichment now goes only to CVEs already in CISA's Known Exploited Vulnerabilities catalogue, CVEs in software the US federal government runs, or software designated critical under Executive Order 14028. Everything else is filed "Not Scheduled". Nothing published before 1 March 2026 gets enriched at all. And NIST stopped routinely attaching its own severity score, deferring instead to whatever the CVE Numbering Authority supplied.

That last change is the load-bearing one. The number that made those SQLite advisories look like an emergency came from the party filing them, and NVD policy is now not to second-guess it. I want to be careful about the causal claim: I cannot show that the old process would have caught this specific batch. What I can show is that the step most likely to have caught it is the step that stopped running four months earlier.

NIST did not choose this out of complacency. It enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, and still lost ground. That is the shape of the whole problem. Human enrichment cannot race a generator, and working harder at it produced a 45% improvement against a 263% increase. The answer to a machine writing advisories is not more analysts reading them.

The strongest case against this read

Patrick Garrity at VulnCheck has the best data on the question and reaches a more cheerful conclusion. In his first-half 2026 exploitation analysis, of 1,061 vulnerabilities attributed to AI-assisted discovery, 14 (1.3%) were confirmed exploited in the wild, which closely matches the rate across all vulnerabilities. Roughly 200 CVEs reached KEV status within 31 days of publication in the first half of 2026, in line with 196 in 2024 and 194 in 2025. The KEV-to-CVE ratio has fallen from a 2.7% peak in late 2023 to 1.4%. His read: "giving defenders access to more advanced frontier models is more likely to give defenders an advantage in strengthening software than to give attackers an advantage in discovering vulnerabilities before the software producers do".

I think he is right about the question he asked, and it is a different question from mine. He is measuring whether the extra volume is dangerous. I am arguing about whether it is affordable. Those two costs come apart cleanly. Daniel Stenberg shut down curl's HackerOne bug bounty in February 2026 not because slop reports were being exploited but because his security team was reading them; the confirmed-vulnerability rate on submissions had fallen below 5%, against something north of 15% over the programme's life. Curl reopened a month later when report quality recovered, but the volume did not fall. No exploitation metric captures that cost, and curl paid it anyway.

There is also a second reading of Garrity's own headline number that he does not take and I think deserves airing. A KEV-to-CVE ratio falling from 2.7% to 1.4% is consistent with exploitation failing to scale with disclosure, which is his reassuring interpretation. It is equally consistent with a denominator filling up with records that were never vulnerabilities. His data cannot separate those, and neither can mine. That ambiguity is itself the problem: once the CVE count stops being a count of vulnerabilities, every ratio built on it becomes unreadable.

The stronger objection to my position is a policy one. Make a working proof-of-concept a condition of publication and you exclude real vulnerabilities: logic flaws, races, auth bypasses that need a specific deployment, findings a reporter cannot safely demonstrate. You would advantage vendors with test infrastructure and disadvantage exactly the volunteer researcher the CVE system exists to serve. That objection is correct, which is why the fix cannot be a wall.

Make it a field instead. The record already carries provenance metadata; what it does not carry is a required, machine-readable statement of what was done to check. Third-party reproduced under sanitiser. Vendor-confirmed. Asserted only, no reproduction attempted. Publish all three, and let scanners rank on it. Nobody gets excluded. What stops is "a CVE exists" functioning as an undifferentiated claim, which is the property automated consumers are currently relying on and should not be.

Anthropic's ledger is the same bottleneck wearing a lab coat

The organisation doing verification most carefully is also the one that seized up. Anthropic announced Project Glasswing in April and launched a disclosure ledger in May, claiming Claude had identified 23,019 findings and committing 1,611 entries. Garrity's tracking finds the ledger has not grown past those 1,611 since, that 126 findings have become published CVEs, that exactly one (CVE-2026-26980) has been confirmed exploited, and that more than 150 findings have passed the disclosure deadline in Anthropic's own coordinated disclosure policy without publication.

That 126-from-23,019 figure is not a false-positive rate and should not be read as one; it folds in deduplication, severity triage, vendor response and disclosure timing. What it does show is where the compression happens, and how expensive that compression is when a human coordination process is the filter. Verification is the bottleneck even for the people funding it properly. Skip it and you get the SQLite batch. Do it by hand and you get a ledger frozen for three months.

The bet

The second-order effect is the one JFrog flags at the end of its own write-up, and it is worth stating plainly. The consumers of the CVE feed are increasingly agents. An agent handed CVE-2026-51302 will go looking for exprComputeOperands() in SQLite 3.41, fail to find it, and then do one of two things: give up, or write the function. Fabricated advisories stop being noise at that point and become instructions.

So here is the bet. Google's numbers will keep climbing for the class of software that has a cheap, automatic oracle sitting behind it, and flatten for everything else. Apple is the closest thing to a control we have: an independent count puts it at 482 bugs patched in 2026, roughly its 2015 pace. Either Apple is not doing this, or a bug-fix count measures your tooling and your disclosure policy more than it measures your security. Both possibilities are worth knowing and neither appears on Google's chart.

The falsifiable part: by the end of 2026, either a major aggregator ships a visible reproduction-provenance tier, or the same filtering happens privately, with commercial scanners quietly de-ranking unvalidated CNAs and the public CVE record becoming a feed you have to pay somebody to interpret. I would put money on the second and I would rather lose it. What would change my mind is straightforward to watch for: if audits over the next two quarters turn up nothing comparable to 54 fabrications from 55 filings, then this was one bad actor rather than a structural hole, and the safety net that came down in April was not holding anything up.