An AI Hallucination Earned a CVE

Recently, a purported SQLite vulnerability report—apparently generated by a large language model and technically invalid—was formally assigned a CVE identifier and briefly entered security information feeds as a “high-severity vulnerability.” After reviewing the report, the JFrog security research team concluded that the vulnerability it described lacked verifiable evidence, that the alleged trigger path did not match the actual code, and that the report as a whole looked more like an AI-generated artifact with complete structure and professional wording, but no real debugging behind it.

This is far more serious than “AI hallucinated again.”

An incorrect answer from an ordinary chatbot usually ends with the conversation. But once a false report enters CVE records, security advisories, vulnerability databases, and scanner rules, machines replicate it at scale, turning it into alerts, tickets, upgrade tasks, and even procurement and compliance risks. What the model fabricated was not merely an answer, but a “fact” capable of driving enterprise security processes.

As of August 3, 2026, the most important aspect of this incident is not the identifier itself, but a reality exposed by the vulnerability disclosure system: A CVE can give a report a unique identifier, but it cannot automatically perform the technical validation on the report’s behalf.

Why a Report That “Looks Like a Vulnerability” Can Get Through

According to the findings recently published by JFrog, the report had the typical appearance of a security report: an affected component, a vulnerability type, a version range, and a seemingly plausible impact description. To anyone who is not a SQLite expert, it sounded quite convincing.

The problem is that vulnerability research is not an exercise in filling out a template.

A genuine memory-safety vulnerability must answer at least several questions:

• How does the input reach the target function?
• Which object’s length, lifetime, or bounds are handled incorrectly?
• Which reachable call chain ultimately causes an out-of-bounds access, use-after-free, or integer overflow?
• Under which commit, build options, and runtime environment can the issue be reproduced reliably?
• What evidence is provided by AddressSanitizer, UndefinedBehaviorSanitizer, or a debugger?
• Is there an observable difference in behavior before and after the fix?

Reports suspected of being AI-generated can often produce keywords such as “heap buffer overflow,” “remote code execution,” and “specially crafted SQL input,” yet lose their footing at the most critical points: the claimed relationships between functions do not line up, variable semantics are misunderstood, the affected version range has no basis, or the allegedly dangerous path is simply unreachable in the real program.

This type of content can particularly easily fool form-driven review processes. It does not need to prove the vulnerability; it only needs to fill in all the fields expected in a vulnerability report.

The heuristics the security industry previously used to filter out low-quality reports are also being weakened by large language models. Chaotic spelling, incomplete descriptions, and an inability to write reproduction steps used to be obvious signs of a poor report. Models can now generate text with accurate terminology, complete sections, and a confident tone within seconds. The “writing quality” of a report is no longer reliably correlated with its technical credibility.

A CVE Identifier Is Not a Quality Certification

Many developers interpret “it already has a CVE” as meaning the vulnerability has been independently verified. This is a common but dangerous misconception.

The core purpose of CVE is identification and coordination: assigning a unique identifier to a publicly disclosed security issue so that vendors, researchers, vulnerability databases, and security products can discuss the same issue. Identifiers are generally assigned by CNAs, or CVE Numbering Authorities. Different CNAs do not necessarily apply the same intake standards, technical capabilities, or depth of review.

The following three concepts must therefore be considered separately:

1. Receiving a CVE identifier: This means that an issue has been registered and given a unique identifier.
2. Receiving a high CVSS score: This means that the issue’s theoretical severity is high when calculated according to the attack conditions and impact claimed in the report.
3. Reproducing the vulnerability: This means that researchers have observed an actual security boundary being breached in a clearly specified version and environment.

Neither of the first two can substitute for the third.

If the original report claims that the vulnerability can be triggered remotely without authentication and can cause memory corruption, the CVSS calculation may naturally fall into the High or even Critical range. But that score rests on the assumption that the description is true. If the premise was invented by a model, a score precise to one decimal place is merely a “high-precision error.”

It is like assigning a medical record number to a fictional disease and classifying the case as critical based on the contents of the record. The number makes the record easier to route, and the critical classification follows the rules for the information entered—but the patient may not exist at all.

SQLite Is Particularly Susceptible to Becoming a Target of “High-Value Hallucinations”

SQLite is unusual in that it is both small and ubiquitous.

It is embedded in browsers, mobile applications, desktop software, operating-system components, and numerous IoT devices. Once a report claims that SQLite contains a general-purpose memory-corruption vulnerability, the potential scope of impact can easily be portrayed as enormous, making the report more likely to attract the attention of CVE databases, security vendors, and the media.

At the same time, SQLite’s code has undergone years of review, and its testing infrastructure is highly mature. Finding a real vulnerability is not impossible, but proposing a credible new issue usually requires a concrete understanding of the parser, virtual machine, query execution, extension interfaces, and memory management. A large language model only needs to learn common narrative templates from public vulnerability reports to piece together a story in which “SQLite receives malicious SQL, triggers a bounds-checking flaw, and ultimately enables code execution.”

That story may be statistically plausible while being completely invalid in the actual code.

Another mistaken conclusion must also be avoided: the appearance of this false report does not mean that all SQLite vulnerabilities discovered by AI are untrustworthy. CVE-2025-6965, previously discovered by Google Big Sleep, was a genuine SQLite memory-corruption issue and has been regarded as an important example of AI-assisted vulnerability discovery.

Taken together, the two cases accurately illustrate the current state of AI security research:

AI can discover code defects that humans have overlooked for years, and it can describe a defect that never existed in the same professional tone.

What distinguishes the two is not the model’s brand, parameter count, or writing style, but reproducible engineering evidence.

The Real Cost Begins After the Identifier Is Assigned

A false vulnerability does not become harmless merely because “there is nothing for an attacker to exploit.”

For software maintainers, an incorrect report with a CVE identifier may trigger multiple rounds of review: locating the allegedly affected code, setting up historical versions, running fuzz tests, responding to downstream distributions, and communicating with the CNA to amend or reject the record. Open-source projects are already understaffed. AI has reduced the cost of generating reports to nearly zero, but it has not similarly reduced the cost of validation for maintainers.

For enterprise security teams, the impact is more direct. A typical software supply-chain process looks roughly like this:

1. A vulnerability database ingests the CVE.
2. An SCA scanner discovers that an asset includes SQLite.
3. The system automatically creates a high-priority ticket based on CVSS and policy.
4. The security team requires the business team to upgrade, isolate the asset, or submit an exception.
5. The development team spends time determining whether the relevant code path is actually reachable.
6. Only days later does everyone discover that the original vulnerability cannot be reproduced at all.

If a scanner only checks whether “the component version falls within the affected range,” a single AI hallucination can easily generate thousands of alerts. More troublingly, false high-severity alerts consume an organization’s attention budget. After repeatedly handling incidents like this, security teams may hesitate when the next genuine alert arrives—the classic problem of alert fatigue.

“CVE spam,” therefore, is not merely a matter of database hygiene. It reduces the signal-to-noise ratio of the entire vulnerability-response system.

How to Determine Whether a Report Describes a Vulnerability or Merely Looks Like One

Enterprises and open-source maintainers do not need to determine whether a report was written by AI. That question is difficult to answer reliably and is not the point. Humans also submit incorrect reports, while models may submit genuine vulnerabilities.

What should be verified are the technical claims in the report.

Layer One: Pin Down the Version and Environment

Reproduction must be tied to a specific source-code commit, compiler version, set of build parameters, and runtime platform. “The latest version is affected” is not actionable information. For components such as SQLite, which are frequently updated and support numerous build options, a vague version range is especially inadequate.

A basic isolated validation workflow might look like this:

# This example is only for validating a vulnerability report and contains no exploit code
git clone https://github.com/sqlite/sqlite.git
cd sqlite
git checkout <the commit claimed to be affected in the report>

export CFLAGS="-O1 -g -fsanitize=address,undefined -fno-omit-frame-pointer"
./configure
make -j"$(nproc)"

# Run the minimal reproducer supplied in the report in an isolated environment
./sqlite3 < claimed-reproducer.sql

If the report provides no executable input and offers only a natural-language chain of reasoning, its credibility should be downgraded immediately. A claim that something “may cause memory corruption” cannot substitute for a crash stack trace, Sanitizer output, or clear evidence that an invariant was violated.

Layer Two: Verify Code-Path Reachability

Models are very good at identifying local code that appears “unsafe,” but they often overlook upstream constraints. For example, a length value may appear unchecked within a function, while the caller may already guarantee that it can never exceed the boundary. A pointer may seem capable of being null, but the real call chain may only ever pass initialized objects.

Reviewers need to trace the call chain upward rather than focusing only on the few lines of code named in the report.

Layer Three: Require Minimal Evidence

A high-quality report should provide as much of the following as possible:

• A minimal triggering input;
• A complete crash stack trace;
• The affected commit and the fixed commit;
• Sanitizer or debugger output;
• Expected behavior and actual behavior;
• Whether the issue reproduces across platforms and compilers;
• A concrete explanation of the security boundary being violated.

A long, model-generated “attack scenario” without any of this evidence contains very little actual information.

Layer Four: Incorporate Upstream Findings into Scoring

Component maintainers understand their code’s constraints best. Security platforms should not synchronize CVSS scores alone; they should also synchronize upstream confirmation, disputed status, and rejection status. A record that upstream has explicitly determined to be unreproducible should not continue bombarding users at the default high-severity priority, even if it temporarily retains a CVE identifier.

Security Platforms Need to Add an “Evidence Layer”

The real bottleneck exposed by this incident is not that large language models can hallucinate, but that existing automated systems are too quick to trust structured fields.

At a minimum, the next generation of vulnerability-management systems should separate the following data:

• Claimed severity: What consequences does the reporter claim?
• Technical credibility: Is there a PoC, crash stack trace, or independent reproduction?
• Asset reachability: Can the enterprise’s actual code enter the relevant path?
• Upstream status: Has the maintainer confirmed, disputed, fixed, or rejected the issue?
• Source reputation: What is the reporter’s historical validity rate, regardless of whether AI was used?
• Record status: Has the CVE been updated, withdrawn, or marked as rejected?

In other words, CVSS can answer only, “If the description is true, how severe are the consequences?” It cannot answer, “How likely is the description to be true?” What enterprises actually need is a two-dimensional assessment of severity and credibility.

For example, a report with a CVSS score of 9.8, no executable PoC, no independent reproduction, and explicit upstream dispute should not automatically outrank a CVSS 7.5 vulnerability for which exploitation has already been observed in production.

AI Did Not Break CVE; It Merely Amplified an Existing Problem

Low-quality vulnerability reports did not first appear in the era of large language models. Bug-bounty incentives, false positives from automated scanners, and researchers’ insufficient understanding of code have all produced large numbers of invalid reports. What AI changes is the scale and appearance: where one person might previously have assembled a few reports per day, hundreds can now be generated in bulk, each looking professionally edited.

Simply placing the blame on “using AI to submit vulnerabilities” and banning it is therefore pointless. The effective threshold should be an evidentiary one: without a pinned version, a minimal reproducer, and runtime evidence, natural-language claims alone should not be granted high-confidence status.

Nor does the CVE system need to bear the entire burden. The purpose of assigning identifiers was never to conduct code audits on behalf of developers worldwide. But security products, vulnerability databases, and enterprise response systems must stop translating “has an identifier” into “has been confirmed.”

This SQLite incident leaves the industry with a straightforward conclusion: The marginal cost of generating AI-written vulnerability reports has approached zero, while the marginal cost of security validation has not declined. Anyone who continues to work according to report volume and textual completeness will be the first to drown in AI-generated noise.

In the future, the scarcest resource will not be models capable of writing vulnerability reports, but validation systems capable of producing deterministic execution traces, minimal reproducers, and auditable chains of reasoning. What the security industry truly needs is not another chatbot that is better at saying “there may be an RCE here,” but a mechanism willing to state clearly, when the evidence is insufficient, that an issue is “not yet confirmed.”

References

• SQLite GitHub Mirror Repository: Used to inspect SQLite source code and commit history and to establish an independent reproduction environment.

Note: The core review findings for this incident come from an investigative article recently published by JFrog Research. Due to this article’s source-domain restrictions, no external link to that article is included.