How to Spot Hallucinated CVEs in AI-Generated Vulnerability Reports

A vulnerability report written by an LLM should be treated as a draft, not as evidence. The practical gate is simple to state: no claim in the report moves into a ticket, patch, or customer communication until it carries a concrete, checkable anchor, and the anchor has survived whatever verification actually applies to it. For some claims that verification is a deterministic check a machine can run. For the rest it is a human reviewer. The reason to be strict about this is cost: a fabricated or hollow finding that enters your workflow does not save review time, it moves the error somewhere more expensive.

This is not a hypothetical posture. A study of bug bounty report validity, which analyzed 9,942 disclosed HackerOne reports to understand how reviewers judge submissions, describes the current inflow plainly: “Recent years have brought a surge of AI-generated submissions in bug bounty programs. Many of these reports appear convincing at first glance but contain fabricated evidence or shallow reasoning, creating significant overhead for triage teams.” Convincing at first glance is the operative phrase. Plausibility is exactly what generative models are good at producing, so plausibility cannot be the criterion that gets a CVE identifier into a ticket.

The survey’s central point: test the evidence, not the authorship

A recent arXiv survey, AI Slop and Hallucinations in Vulnerability Assessment, synthesizes the failure modes and mitigation patterns for LLM-assisted security analysis. Its most useful contribution is also its most counterintuitive one. The authors reject the framing that “AI slop” means machine-written output:

The core failure of AI slop is not that it was produced by a machine. A human analyst working from incomplete information under time pressure can produce an equally hollow report. An LLM-assisted analysis that has passed formal verification is useful regardless of its origin.

This changes the design of any triage gate. A filter that tries to detect “AI-written” reports targets the wrong variable, and it would both miss hollow human reports and reject verified machine-assisted ones. The gate has to interrogate the evidence attached to each claim, whoever produced it.

The survey’s prescribed architecture follows from that: “The path forward requires treating generation as the starting point of a verification pipeline, pairing generative models with deterministic evaluators while remaining explicit about where each evaluator’s blind spots lie.” It also argues for active verification and neuro-symbolic approaches, and catalogs open challenges in building trustworthy triage. One caveat on provenance: this is an author-synthesized, unreviewed preprint, so its framework is a principled position rather than an empirically validated standard. The positions it stakes out, though, align with what the empirical work below shows, and they give a triage team something concrete to build on.

Gate 1: Does every claim have a concrete anchor?

The cheapest filter is the one the survey defines as “explicitly grounded”:

“Explicitly grounded” means the output contains a concrete evidence anchor for cic_{i}: a specific code reference, execution trace, concrete input specification, or formal proof fragment. Vague appeals to “the data flows through several functions” do not count.

Applied to an incoming vulnerability report, this gate asks one question per claim: what artifact could I check right now? A claim about an integer overflow should name the function and the arithmetic operation. A claim about an exploitable path should include the input that exercises it or the trace that demonstrates it. A claim citing a CVE should include a reference that resolves. Reports full of confident prose about data flowing through functions fail this gate in seconds, and they fail it without any model-specific detection tooling.

The same grounding logic extends naturally to the artifacts a CVE claim drags behind it. Does the cited CVE identifier exist? Does the claimed affected-version range match what the identifier’s record says? Do the references in the report actually resolve and actually say what the report asserts? I want to be precise about the status of these checks: no cited study evaluates CVE-existence lookups, version-range comparison, or reference-validity checks as tested tools. They are a direct application of the survey’s grounding definition, treating each named identifier, version range, and citation as a claim that must anchor to something checkable. That derivation is sound as a design principle, but no cited study measures how well any specific implementation of these checks performs.

What the grounding gate catches is the dominant failure pattern both sources describe: fabricated evidence and shallow reasoning wrapped in fluent prose. What it cannot catch is a well-anchored claim that is still wrong, which is what the next gate is for.

Gate 2: What a deterministic evaluator can close

Some vulnerability claims are machine-checkable, and where they are, a deterministic evaluator beats both model self-review and human skimming. The clearest demonstrated example in the evidence is COBALT, described by its authors as “a Z3 SMT-based formal verification engine for identifying CWE-190/191/195 arithmetic vulnerability patterns in C/C++ infrastructure prior to deployment.” If a report alleges an integer overflow, underflow, or wraparound in C or C++ code, an SMT solver can, in principle, settle whether the pattern exists rather than assess whether the report sounds right.

The scope limit matters as much as the capability. COBALT’s demonstrated reach is a specific set of arithmetic weakness classes. It says nothing about injection flaws, authentication logic, race conditions, or the long tail of CWEs that dominate real triage queues. This is exactly the survey’s instruction to be “explicit about where each evaluator’s blind spots lie”: every automated gate should ship with a written statement of the failure classes it cannot see, so reviewers know what the green checkmark does not mean.

A second, softer deterministic assist comes from the bug bounty validity study. Its central methodological finding: “Adding reviewer knowledge in the form of a taxonomy of invalid report types helps the models detect invalid cases more reliably and make decisions more consistently.” Encoding a taxonomy of your program’s known invalid-report categories into the screening prompt measurably improved detection in that study. A list like out of scope, duplicate, informational, or non-reproducible is illustrative of what a program might define; the study’s own taxonomy covers rejection reasons for Information Disclosure reports specifically. The caveat is that this result comes from the study’s dataset of 9,942 disclosed HackerOne reports, not a deployed product benchmark, so it supports taxonomy-driven screening as a method rather than guaranteeing a specific accuracy in your queue.

The COBALT paper also models a discipline worth institutionalizing in the gate itself. Discussing a sandbox escape whose cause was not publicly established, the authors write: “Anthropic has not publicly characterized the escape vector; some secondary accounts hypothesize an arithmetic vulnerability in the sandbox’s networking infrastructure [2, 4]. We treat those accounts as unverified.” A triage pipeline should have an explicit “unverified” state that blocks promotion, rather than a binary where everything not yet disproven drifts toward accepted.

Gate 3: When a human has to look

Automated gates partition the queue; they do not empty it. The escalation rule that follows from the evidence:

• Anchor missing or vague. Reject or return. The grounding check is cheap enough that nothing unanchored should consume human time.
• Anchored, and a deterministic evaluator applies. Run it. An SMT check on a claimed arithmetic pattern, a taxonomy match against known invalid categories, an identifier that resolves or fails to resolve. Passes move forward; failures are documented, not argued with.
• Anchored, and the claim class has a prescribed machine gate. Run it, and write down its limits. The survey maps exploitability claims to fuzzing, where “the generated proof-of-concept is compiled and executed under a coverage-guided fuzzer such as AFL or libFuzzer,” and claimed constraints to symbolic execution, where “a symbolic executor such as KLEE or angr explores the path space to determine whether claimed constraints are satisfiable.” The same section documents where both stop: “Coverage-guided fuzzers struggle with magic-byte comparisons, deep conditional branches, and path constraints requiring specific heap layouts,” the fuzzing verdict “depends entirely on the LLM-generated harness,” and symbolic execution “faces path explosion as feasible paths grow exponentially with branch count.”
• Where a gate’s documented limits bite, or no gate applies. Human review. Business-logic impact is the clearest ungated case: the survey’s pipeline maps no machine evaluator to it. This is where much of the queue still lives.

There is a useful cross-domain analogy for how to structure the human step. In image super-resolution, the VHA method frames hallucination assessment as a support judgment: does the generated content match what its ground-truth counterpart supports? The domain is images, not security, so this is an analogy rather than a control, but the transfer is the reviewer’s stance. The question is never “is this report plausible?” It is “is each claim in this report supported by the reference it points to?”

Verification is also not a one-time event. Rescans in one orchestrated vulnerability management deployment run every 50 hours for traditional devices and every 100 hours for constrained ones, with continuous passive monitoring between scans. That evidence comes from network device management, not LLM-output triage, but the operational shape carries over: an initial check, periodic re-checks, and passive monitoring in between. A finding that verified cleanly at intake can still need re-examination when the advisory record, the affected-version data, or the codebase changes underneath it.

Why a bad import costs more than the review it skipped

The maintainer-side evidence explains why the gate belongs between model output and ticket rather than between ticket and merge. In interviews with open-source maintainers about bug bounty handling, seven of the seventeen interviewees point to CVE creation support as an essential feature during report review (I=7), and six describe the CVE process itself as complicated (I=6). Ten of them attribute the flood of low-quality and spam reports to a diverted focus on bounties and CVEs (I=10). The I-values count the interviewees who raised each point, so these are qualitative interview findings rather than throughput measurements, but the picture is consistent: the CVE pipeline is already strained, already friction-heavy, and already absorbing spam motivated by the prestige of CVEs and bounties.

A hallucinated CVE identifier imported into that pipeline does not sit quietly in a queue. It triggers reviewer attention, possibly CVE creation work, possibly a patch, possibly a customer notification. Each handoff multiplies the cost of the original fabrication, and retraction at the far end costs more than rejection at the near end. That asymmetry is the whole economic argument for the gate.

The triage checklist

The table below maps the failure patterns documented in the evidence to checks. The “documented” column is deliberate: some rows rest on study results, and others are principled inferences from the survey’s grounding and verification-pipeline principles. The distinction matters if you are writing this into procedure, because the inferred rows have no measured efficacy in the cited studies.

If I were setting this up, I would start with the grounding gate alone and measure what fraction of the incoming queue it rejects before adding anything else. It is the one check with a crisp definition, it runs without model assistance, and it targets the failure both studies describe most directly. The taxonomy screen is the next cheapest addition, provided your program maintains an honest list of its own invalid-report categories.

What this evidence cannot settle

Three honest limits before anyone builds policy on this. First, none of the cited studies quantifies how often hallucinated CVE identifiers actually occur, and none documents a specific fabricated CVE by name. The surge of fabricated-evidence submissions is documented; the frequency of the specific identifier-hallucination failure is not, and any article or policy that cites a rate is citing something this research does not contain. Second, the survey underpinning the framework is an unreviewed, author-synthesized preprint; its verification-pipeline architecture is an argued position, not a validated standard. Third, the per-row checks in the table above that go beyond the survey’s own definitions, the identifier-existence, version-range, and reference-validity lookups, are inferences from its grounding principle. They are worth building, but their efficacy is untested in the cited studies, and any specific CVE or NVD tooling should be verified against its own documentation before you promise it catches anything.

None of that weakens the core decision. Treat generated findings as unverified input, demand a concrete anchor, close what deterministic evaluators can close while writing down their blind spots, and send the rest to a human who asks “supported?” instead of “plausible?” The alternative is not faster triage. It is auditing your own tickets for errors you imported yourself.