AI Slop CVEs: Triaging a Polluted Vulnerability Feed

On August 3, 2026, JFrog's security research team published a finding that should change how every engineering org reads its vulnerability feed. A batch of six critical and high-severity SQLite CVEs — including one Red Hat initially scored at a perfect CVSS 10.0 — turned out to be fiction. Not exaggerated. Not disputed. Fabricated.

The advisories cited functions that did not exist in the affected versions. They pointed at line numbers that landed on comments. They referenced patches with no corresponding diff. And when JFrog traced them back, all six came from a single newly created GitHub repository that had published 55 advisories in four days. 54 of them were completely fabricated.

SQLite ships in every Android phone, every iOS device, every browser, and most embedded systems on earth. For roughly a week, security teams worldwide had six phantom criticals sitting in their queue against one of the most widely deployed pieces of software ever written.

This is the part of the AI security story nobody planned for.

What JFrog actually found

The six advisories were not subtly wrong. Each one collapsed the moment anyone opened the source.

Look at CVE-2026-51296 for a moment. The advisory referenced line 3555 of a file that is 2706 lines long. That single check — does the file even have that many lines? — takes about ten seconds and invalidates a "high severity" advisory. Nobody in the chain ran it before the CVE was published and mirrored into downstream databases.

The proof-of-concept payloads, where supplied, did not reproduce. The severity scores were confident, precise, and attached to nothing.

Why this is structurally different from ordinary bad reports

Bogus vulnerability reports are not new. What is new is the cost asymmetry.

Producing a plausible-looking advisory used to require enough understanding of the codebase to be dangerous. Now it requires a prompt. An LLM will happily produce a technically fluent advisory — correct terminology, plausible function names, a CWE mapping, a CVSS vector, a proof-of-concept that reads convincingly — for software it has only pattern-matched, never analyzed. The output is indistinguishable from expert work at a glance and worthless on inspection.

The economics flipped. Generating noise is now effectively free; verifying it still costs an expert's afternoon. That gap is the whole problem, and it is why this looks less like spam and more like a denial-of-service attack on maintainer attention.

The curl project hit this wall first. Daniel Stenberg pulled curl's monetary bug bounty in early 2026 after report volume spiked roughly eightfold, with about a fifth describing vulnerabilities that simply did not exist. Removing the payout worked — Stenberg later reported that "the slop situation is not a problem anymore," and that confirmed-vulnerability rates rose above pre-2024 levels once the bounty-chasers left. Linus Torvalds described the kernel security list as nearly unmanageable, noting the obvious follow-on effect: "If you found a bug using AI tools, the chances are somebody else found it too." Duplicate findings from identical tooling, at scale.

And it is not only the fake reports. VulnCheck's tracking of early 2026 shows genuine AI-assisted disclosure volume climbing steeply too — Chrome up 563%, GitHub advisories across open source up 476%, Apache up 170%. GitHub's Madison Oliver Ficorilli noted that no single reporter accounts for more than about 3% of volume and no single project more than about 7%, which rules out a handful of bad actors and points at something systemic.

So your feed is getting two floods at once: more real vulnerabilities than your team has ever had to process, mixed with fabrications that carry the same formatting and higher severity scores. Sorting them is now a core engineering competency.

The triage checklist

JFrog's red flags generalize into a check you can run in a few minutes, before a critical CVE reorganizes anyone's week.

1. Check the vendor's own advisory page first. SQLite maintains sqlite.org/cves.html. Most serious projects publish something equivalent. A critical CVE that the maintainers have never acknowledged is the single strongest signal available, and it costs one page load.

2. Demand a commit hash or a pull request. Every real fix has a patch. If the advisory says "fixed in 3.51.3" but cannot point at the commit, ask why. Then check the diff yourself — git log -p v3.51.2..v3.51.3 -- src/expr.c would have killed CVE-2026-51303 outright.

3. Verify the code exists. Clone the exact affected version and grep for the function named in the advisory. If it is not there, you are done. This catches the majority of fabrications because LLMs hallucinate symbol names from adjacent versions and general C idiom.

4. Sanity-check the line numbers. Cheapest test in the set. wc -l on the cited file. If the advisory points past the end of the file, stop reading.

5. Reproduce the PoC in a sandbox. If a payload is supplied, run it in an isolated container against the claimed version. No reproduction, no priority. This is non-negotiable for anything rated critical.

6. Look at metadata coherence. Empty CPE definitions, contradictory affected-version ranges, a brand-new reporter account with a burst of advisories, several criticals filed against the same project within hours — individually weak signals, collectively decisive.

7. Weight the source. A CVE from a project's own security team, a known vendor, or an established research group is not the same artifact as one from an account created last week. Treat reporter provenance as a first-class field in your triage.

Here is a rough gate you can wire into a review script:

#!/usr/bin/env bash
# Fast structural sanity check on a CVE claim.
# Usage: ./cve-check.sh <repo-path> <version-tag> <function-name> <file> <line>
 
REPO=$1; TAG=$2; FUNC=$3; FILE=$4; LINE=$5
 
git -C "$REPO" checkout --quiet "$TAG" || { echo "FAIL: version tag $TAG not found"; exit 1; }
 
if ! grep -rq "\b$FUNC\b" "$REPO/$FILE"; then
  echo "RED FLAG: function '$FUNC' absent from $FILE at $TAG"
fi
 
TOTAL=$(wc -l < "$REPO/$FILE")
if [ "$LINE" -gt "$TOTAL" ]; then
  echo "RED FLAG: cited line $LINE exceeds file length ($TOTAL lines)"
fi
 
echo "Context at $FILE:$LINE —"
sed -n "$((LINE-2)),$((LINE+2))p" "$REPO/$FILE" 2>/dev/null

Three checks, a few seconds, and it would have flagged four of the six SQLite advisories on its own.

What to change in your process

Individual checks are necessary but not sufficient. The process assumption that broke is "published CVE equals verified CVE." That was never formally true, but it was operationally reliable enough to build workflows on. It is not anymore.

Three adjustments are worth making now.

Add a verification stage between ingestion and prioritization. Most teams pipe a scanner straight into a ticket queue, where CVSS score sets urgency. Insert a step: for anything rated 9.0 or above, a human confirms the vulnerability exists in your actual deployed version before it can page anyone. Yes, this adds latency to real criticals. The alternative is that anyone with an API key can set your sprint priorities.

Track reporter provenance in your tooling. If your vulnerability management platform does not surface who filed an advisory and when their account was created, that is a gap worth closing. The SQLite batch was identifiable as a cluster — 55 advisories, four days, one new repo — long before anyone read the C.

Write down your disputed-CVE path. When you determine an advisory is invalid, someone needs to report it to the CNA and the downstream databases, and your internal record needs to say "verified false" rather than "not yet patched." Otherwise the same phantom resurfaces in the next audit, and your compliance evidence quietly rots. JFrog reported their findings to GHSA, Red Hat, and NVD — that step is what actually removes the pollution.

If you are running AI agents that consume security feeds and open remediation PRs automatically, this matters twice over. An agent that trusts CVSS scores will burn real engineering time patching imaginary bugs, and the patches will look plausible too. Any automated remediation loop needs the existence check wired in ahead of the fix step — the same discipline we covered in reward hacking and specification gaming, applied to inputs rather than outputs.

The uncomfortable symmetry

The same capability cuts both ways, and that is what makes this hard to legislate away.

AI-assisted vulnerability research is finding genuine, serious bugs — Anthropic's Project Glasswing work and the surge in legitimate disclosures from Mozilla, Microsoft, and Google are real, and we covered that side of the story in Claude Mythos and Project Glasswing. Nobody sensible wants that to stop. Apache received a $1.5M donation specifically to handle the increased genuine response load. Curl's own maintainer noted that one of five early Mythos findings was valid — a 20% hit rate that would be excellent for a human researcher.

The problem is that valid and fabricated arrive in the same envelope, formatted identically, and the fabricated ones tend to claim higher severity because nothing constrains them. There is no watermark, and proposals to filter AI slop with AI mostly relocate the trust problem rather than solving it.

What is left is unglamorous and effective: reproduce before you prioritize, and treat a severity score as a claim rather than a measurement. The ten seconds it takes to run wc -l on a source file is currently one of the highest-leverage security practices available.

For teams in the region

For SMEs across Tunisia, Saudi Arabia, and the wider MENA region, this lands on already-thin security capacity. If your compliance posture depends on an automated scanner report — and for many organizations pursuing ISO 27001 or ZATCA-adjacent requirements it does — you now have a data quality problem sitting underneath your evidence.

The practical minimum: no critical CVE reaches your remediation queue without a human confirming the affected code path exists in your deployment. That is one checkbox in a process document and maybe an hour a month of senior engineer time. It is considerably cheaper than a quarter spent patching software that was never broken, and far cheaper than the alternative failure mode — a team that learns to ignore criticals because most of them turned out to be noise.

That second outcome is the real risk here. Alert fatigue is how a genuine CVSS 10.0 gets missed.

Related reading:

• Claude Mythos and Project Glasswing: AI zero-day discovery
• Security of AI-generated code: vulnerabilities guide
• Trapdoor: supply chain attacks on AI coding tools
• DevSecOps: integrated security across the development cycle