CVE-2026-51302False Positive

❗️ The slopocalypse is real. MITRE published a critical SQLite vulnerability with a CVSS of 10.0 that does not exist. Turns out it was hallucinated by an LLM. SQLite's Richard Hipp says dozens more fake CVEs were filed. CVE-2026-51302 was assigned on 27 July. CISA's enrichment programme then scored it critical and flagged a public proof-of-concept. The Dutch National Cyber Security Center republished it as an advisory, and has now withdrawn it, saying the "vulnerability" was most likely hallucinated by an LLM.

CVSS 10.0, but the evidence doesn't add up. CVE-2026-51302 in SQLite claims critical impact, but: ❌The supplied PoC does not reproduce ❌The source code does not match the claims And it's not an isolated case: JFrog found the same issues in 54 of 55 CVEs published by the same GitHub repository in just 4 days, and informed in the proper CVE channels. ⚠️Don't blindly trust newly published CVEs. Validate the advisory, PoC, and source before prioritizing or patching.

MITRE assigned CVE-2026-51302 to SQLite. CVSS 10.0. Critical severity. Proof of concept available. The Dutch cybersecurity center published an advisory. Told everyone to patch immediately. Then withdrew it. The vulnerability was hallucinated. By an LLM. It does not exist. SQLite's Richard Hipp said dozens more fake CVEs were filed the same way. An AI wrote a vulnerability description. Posted it somewhere. Someone copied it into the CVE system. MITRE assigned it a number. CISA scored it. The Netherlands published it. All for a bug that does not exist. The slopocalypse is real. Every organization is using AI to write security advisories now. Every AI hallucinates sometimes. Sometimes the hallucination is a fake vulnerability. Sometimes it gets a CVE number. Sometimes it gets published as official guidance. Sometimes people waste engineering time patching a ghost. SQLite is open source. The code is public. The vulnerability does not exist in it. But it got a CVE anyway. Now organizations have to decide if they trust CISA's scoring. If they trust MITRE's assignment process. If they trust that the next critical CVE is real or hallucinated. The answer is they cannot. An LLM can generate official-looking vulnerability descriptions faster than humans can verify them. The system is breaking. And nobody noticed until dozens of fake CVEs stacked up.

CVE-2026-51302 and CVE-2026-51303 both scored CVSS 9.8 "Critical" against SQLite. Both are fake. AI-generated garbage. I pulled the SQLite source to check, and here is what I found. JFrog Security Research looked at 55 SQLite advisories filed from one GitHub account (programmervuln). 54 were completely fabricated. Only 1 had a real bug, and even that one was wrapped in unverified metadata. The tells were not subtle once you dig: The advisories named specific versions: 3.41.0, 3.51.2, 3.51.3. The vulnerable functions they cited did not exist in those versions. The proof-of-concept code crashed nothing. GptZero flagged the write-ups as AI-generated text. And these still got a 9.8 and flowed into the GitHub Advisory Database, NVD, and Red Hat feeds before anyone validated them. Think about what that means for a second. The attack is not against SQLite. SQLite was fine the whole time. The attack is against the vulnerability-management pipeline itself. Here is the part that should bother you if you automate anything. Building a security tool that ingests CVE feeds? A dependency scanner, an auto-patch bot, an agent that opens tickets when a Critical drops? BEFORE (dangerous): new CVE lands with CVSS 9.8 // bot trusts the score // auto-creates P0 ticket, pages on-call, maybe force-bumps the dependency // 3am fire drill over a function that does not exist AFTER (safe): new CVE lands with CVSS 9.8 // treat score + advisory text as UNTRUSTED input, same as user input // check: does the cited function exist in the named version? // check: does the PoC actually reproduce? // check: did a real maintainer confirm, or just a fresh throwaway account? // only then page a human The score is not evidence. The advisory text is not evidence. Reproduction is evidence. We spent years teaching people that LLM output is untrusted input. Turns out CVE feeds are now LLM output too. report-to-cleanup lag here was days, not months, which is the one bright spot. GitHub, Red Hat and NVD have flagged or removed them. But the next batch is already being written by a model somewhere. So here is my real question: how much of your patch pipeline runs on a CVSS number alone, with zero reproduction check? And when the fake CVE targets a library you actually ship, will your bot know the difference? #AISecurity #CVE #LLM

🔴 Yapay zeka, uydurduğu "kritik" SQLite güvenlik açığını resmi CVE sistemine soktu! MITRE, CVE-2026-51302 numarasıyla SQLite için CVSS 10.0 (Critical) seviyesinde bir güvenlik açığı yayınladı. Kayıt daha sonra CISA'nın Enrichment Programı tarafından zenginleştirildi, Hollanda Ulusal Siber Güvenlik Merkezi (NCSC) tarafından advisory olarak paylaşıldı ve birçok güvenlik platformunda gerçek bir zafiyet gibi değerlendirildi. Ancak yapılan teknik incelemelerde, referans verilen bazı fonksiyonların SQLite'da hiç bulunmadığı ve PoC'lerin çalışmadığı ortaya çıktı. Yani ortada gerçek bir güvenlik açığı yoktu, tamamen yapay zeka tarafından uydurulmuş LLM hallucination (slop) bir açık. Bu olayın ardından SQLite'ın yaratıcısı Richard Hipp şöyle dedi: "Düzinelerce daha sahte CVE var." https://sqlite.org/forum/forumpost/34bdf3b9bd759d4d

CVSS 10.0, but the evidence doesn't add up. CVE-2026-51302 in SQLite claims critical impact, but: ❌The supplied PoC does not reproduce ❌The source code does not match the claims And it's not an isolated case: JFrog found the same issues in 54 of 55 CVEs published by the same GitHub repository in just 4 days, and informed in the proper #CVE channels. ⚠️Don't blindly trust newly published CVEs. Validate the advisory, PoC, and source before prioritizing or patching. Full technical analysis: https://bit.ly/4xgICKk

NVD marked them critical. CISA's ADP agreed. Red Hat scored CVE-2026-51302 a 10.0, then 7.6, and its page now says upstream has confirmed the CVE is fictitious and any scanner hit on it is a false positive. JFrog ran the proof-of-concept payloads. Nothing crashed.

JFrog audited 55 SQLite advisories from one publisher. 54 were completely fabricated. Functions absent from the version cited. Line numbers past the end of the file. One had a real bug in unverified metadata. CVE-2026-51302 drew a 10.0 Critical from Red Hat, later cut to 7.6. https://t.co/7YY9qcnXHE

CVE 流水线被 AI 幻觉打穿了。 GitHub 上有人批量丢「SQLite 严重漏洞」公告，NVD/CISA 直接走高危通道。复核却对不上：引用代码不存在、PoC 打不出崩溃、官方也没收录。CVE-2026-51302 一度被打到 10.0，后来降到 7.6。 规则还是「先标严重再人工」——自动聚合的门槛，扛不住 LLM 垃圾报告。谁先吃亏：靠评分机器分诊的安全团队。

What happens when AI hallucinates a critical CVE? If you’re a maintainer, SOC analyst, or anyone feeding CVEs into automation, this matters because fake signals are now creating real workload. The scary part is how far this one got. A fresh GitHub repo published 50+ SQLite CVE advisories that JFrog now believes are mostly LLM slop. NVD flagged some as critical. CISA’s ADP agreed. Red Hat initially scored one, CVE-2026-51302, at 10.0 before later dropping it to 7.6. Then the claims fell apart under basic verification. JFrog checked the actual SQLite tags, built clean releases in Docker, ran the supplied PoCs under AddressSanitizer, and audited the metadata. One advisory referenced exprComputeOperands() in SQLite 3.41. That function did not exist there; it appeared in 2025. Another claimed a patch in 3.51.3, but the relevant file had no diff. One cited json.c lines 3555 and 3575 in a version where the file only had 2706 lines. This is the new AI security failure mode: fake precision. The advisories had CVE IDs, function names, line numbers, PoC payloads, CVSS scores, and enough vulnerability-shaped wording to flow through systems built for volume. To a busy maintainer, SOC analyst, or compliance team, it looks costly before it looks fake. The grounded take: AI did not invent bad CVEs. It made them cheaper to mass-produce, more technically fluent, and harder to reject at first glance. Security teams probably need a new triage step: verify that the named code exists in the named version before treating severity as reality. Curious how many scanners, dashboards, and SLAs already turned hallucinated CVEs into real tickets this week. https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/

FAKE SQLITE CVES ARE LLM SLOP 1. New GitHub repo filed SQLite CVEs citing functions that don't exist. One PoC pointed past EOF in json.c. 2. JFrog audited 55 advisories: 54 fabricated. Red Hat cut CVE-2026-51302 from 10.0 to 7.6. #SQLite #CVE #InfoSec https://t.co/ik83CXnkCu

What happens when AI hallucinates a critical CVE? The failure was not that fake CVEs appeared. It was that they reached trusted security pipelines. A new GitHub repository published 50+ SQLite CVE advisories that JFrog now assesses as mostly LLM-generated noise. NVD marked some as critical. CISA’s ADP concurred. Red Hat first scored CVE-2026-51302 at 10.0, then later reduced it to 7.6. The evidence broke at verification. JFrog checked the referenced SQLite tags, built clean releases in Docker, ran the supplied PoCs under AddressSanitizer, and reviewed the metadata. One advisory named exprComputeOperands() in SQLite 3.41. That function was not present there; it appeared in 2025. Another claimed a fix in 3.51.3, but the relevant file showed no diff. One cited json.c lines 3555 and 3575 in a release where the file had only 2706 lines. This is the operational risk: fabricated specificity. The advisories contained CVE IDs, function names, line numbers, PoC payloads, CVSS scores, and plausible vulnerability language. That is enough to enter systems optimized for intake, ranking, and response. For maintainers, SOC analysts, and compliance teams, the first signal may be workload, not falsity. The grounded conclusion: AI did not create low-quality vulnerability reports. It lowered the cost of producing them at scale, with enough technical form to survive initial review. Security teams should add a basic gate: confirm the named code exists in the named version before treating severity as fact. The open question is how many scanners, dashboards, and SLAs have already converted hallucinated CVEs into real work. https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/

What happens when AI hallucinates a critical CVE? The underestimated risk is not fake CVEs. It is fake CVEs with enough structure to enter real security workflows. A new GitHub repository published 50+ SQLite advisories that JFrog now assesses as mostly LLM-generated noise. NVD marked some as critical. CISA’s ADP concurred. Red Hat first scored CVE-2026-51302 at 10.0, then revised it down to 7.6. The evidence failed at source-code level. JFrog checked the referenced SQLite tags, built clean releases in Docker, ran the provided PoCs with AddressSanitizer, and reviewed the metadata. One advisory cited exprComputeOperands() in SQLite 3.41. That function was not present in that version; it appeared in 2025. Another claimed a fix in 3.51.3, but the relevant file showed no diff. A third pointed to json.c lines 3555 and 3575 in a release where the file had only 2706 lines. This is a practical AI security failure mode: synthetic specificity. The reports contained CVE IDs, function names, line references, PoC payloads, CVSS scores, and vulnerability-style wording. That is enough to pass through tooling and human queues optimized for throughput. For maintainers, SOC teams, and compliance owners, the cost arrives before the falsity is obvious. The bounded conclusion: AI did not create low-quality vulnerability reports. It reduced the cost of producing technically fluent ones at scale. A useful triage control is simple: confirm the named code exists in the named version before treating the severity score as operational fact. The open question is how many scanners, dashboards, and SLA clocks already converted hallucinated advisories into real work this week. https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/

🚨SQLite UAF + PoC (CVE-2026-51302) — CVSS 9.8. Crafted SQL can trigger use‑after‑free → DoS, data leak or RCE. Limit processing of untrusted SQL, sandbox DB access, and apply vendor patches when available. Details → https://app.rapidriskradar.com/cve/CVE-2026-51302 https://t.co/w4c8loLtIr