The editorial argues that CVE issuance was designed assuming reporting a vulnerability is expensive, so submissions were usually real. LLMs have collapsed the cost of producing plausible-looking advisories to near zero while triage costs remain unchanged, breaking the economic foundation of the entire disclosure pipeline.
JFrog's post-mortem documents that every technical anchor in CVE-2025-6965 — the function name, code pattern, commit hashes, affected version range — was fabricated in the characteristic style of LLM hallucination. They traced it to an automated pipeline pairing LLM output with CVE submission, and note the fake advisory made it through MITRE and into NVD, triggering real emergency patching conversations.
The editorial contends that industry attention has been fixated on attackers using LLMs to write exploits faster, when the actual failure mode landing in production is defenders and researchers flooding the disclosure system with hallucinated vulnerabilities. This misdirection has left the reporting and triage infrastructure unprotected against the more consequential real-world abuse.
By submitting the JFrog research to HN where it earned 588 points and 215 comments, ymir_e surfaced a story whose engagement reflects broad developer alarm that a fabricated CVE could pass MITRE's issuance process and land in the National Vulnerability Database without any human catching that the referenced function and commits didn't exist.
JFrog's security research team published a post-mortem on CVE-2025-6965, a 'critical' SQLite vulnerability that they say never existed. The advisory described a memory-corruption bug in a specific SQLite internal function, complete with a CVSS 9.8 score, a plausible attack narrative, and references to code paths that a busy security engineer would have no reason to double-check.
The problem: when JFrog's researchers actually opened the SQLite source, the function named in the CVE wasn't there. Neither was the vulnerable code pattern. The commit hashes referenced in supporting material didn't resolve. The 'affected versions' range didn't line up with SQLite's actual release history. Every technical anchor in the advisory was fabricated in exactly the way a large language model fabricates code: confident, syntactically plausible, and completely disconnected from reality.
JFrog traced the likely origin to an automated vulnerability-discovery pipeline that pairs LLM output with a CVE-submission workflow. The advisory made it through MITRE's issuance process and landed in the National Vulnerability Database, where it was picked up by downstream scanners and — in at least some environments — triggered emergency patching conversations for a bug that has never existed in any shipping build of SQLite.
The CVE system was designed around a scarcity assumption: reporting a vulnerability is expensive, so the people who bother to do it usually have a real bug. That assumption has quietly stopped holding. LLM-assisted vulnerability research has collapsed the cost of producing something that looks like a credible security advisory to roughly zero, while the cost of triaging one has stayed exactly where it was.
Security teams have spent the last two years worrying about the wrong side of the LLM-in-security story. The narrative has been about attackers using models to write exploits faster. The actual failure mode showing up in the wild is more mundane and, in some ways, more corrosive: models generating plausible-sounding defensive artifacts — CVEs, patch notes, threat-intel reports — that consume defender attention without pointing at real problems. Curl maintainer Daniel Stenberg has been sounding this alarm for over a year about HackerOne submissions; the JFrog write-up is the same phenomenon reaching the CVE infrastructure itself.
SQLite is a particularly damning target for this kind of noise. It's in essentially every phone, every browser, and a large fraction of embedded devices on Earth. A critical CVE against SQLite triggers a real cascade: enterprise vulnerability scanners flag it, compliance frameworks demand action, on-call engineers get paged, procurement teams start asking vendors uncomfortable questions. A hallucinated SQLite CVE is not a curiosity — it's an incident that costs real engineering hours across thousands of organizations before anyone can prove the underlying bug doesn't exist.
The deeper issue is that CVE-as-a-format has almost no defense against this. The pipeline was built to take a reporter at their word and let downstream consumers apply their own judgment. When the reporter is a hallucination-prone model dressed up as a research pipeline, and the downstream consumers are automated scanners that just re-emit whatever they ingest, there's no adult in the loop. MITRE isn't going to hand-verify every submission. Vendors like SQLite's Richard Hipp aren't going to spend their week rebutting fabricated bugs against their own project.
If you run vulnerability scanning against CVE feeds — which is essentially every serious engineering org — you now need to treat the feed itself as untrusted input. Two concrete moves are worth making this quarter. First, require a source-code anchor before any CVE against a project you depend on generates a page or a patch cycle: a real commit hash, a real file path, a real function name that exists in the source tree. If your scanner can't cite one, hold the alert. Second, weight CVEs by the reputation of the reporting entity, not just the CVSS score. A CVE from Google Project Zero, Trail of Bits, or the project's own maintainers is a different artifact than a CVE from a name nobody in your industry recognizes.
For open-source maintainers, the JFrog case is a preview of a problem that's about to get much worse. If you maintain anything with a nontrivial user base, assume you will receive fabricated CVEs against your project within the next twelve months, and build the muscle to publicly rebut them fast — because your users' scanners will alert on them either way. A public 'known-invalid CVE' page on your project site, updated in near-real-time, is going to become table stakes.
For security vendors, the incentive alignment is uncomfortable. Scanner products get paid to find findings. A world where 20% of the CVE stream is hallucinated noise is a world where scanners generate more revenue-justifying alerts, not fewer. Expect the market to fix this slowly, if at all, and expect the burden to land on individual security teams to filter their own feeds.
The CVE ecosystem is going to need a trust layer it doesn't currently have — something like signed attestation from the affected project, or a verification step that requires a working proof-of-concept before a CVE can reach 'critical' status in downstream feeds. Until that exists, the practical answer is skepticism as a default posture: treat every unfamiliar CVE as unverified until a human you trust has confirmed the underlying code actually behaves the way the advisory claims. The SQLite incident won't be the last one; it's just the first one big enough to write a blog post about.
The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult.But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them t
Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.
I almost feel that we have a new generation of the "script-kiddie". People without much (or any?) knowledge of software engineering using outside tooling to do "stuff" they wouldn't be able to do themselves.Maybe it's a not a perfect analogy - in this case the intention
This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are.LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are deal