SQLite Critical CVEs or LLM Slop?
Several recent “critical” SQLite vulnerabilities turned out to be fabricated, likely generated by large language models, yet still propagated through official CVE feeds and enterprise scanners. Commenters argue this exposes how overstretched and noisy the current vulnerability ecosystem has become, especially for organizations bound by compliance, insurance, or internal policy to patch every CVE regardless of context. While many see LLMs as powerful tools for finding real bugs, they warn that AI‑generated slop is driving up triage costs, undermining trust in CVE data, and creating pressure to add stronger validation steps—potentially using AI again on the defensive side.
Impact on organizations and security workflows
- Many commenters say “patch all CVEs” policies (driven by SOC2, ISO27001, HIPAA, insurance clauses, gov work, etc.) are already barely workable; fake or low-quality CVEs make it worse.
- Security teams report spending most of their time disproving unexploitable or irrelevant findings (e.g., Bluetooth vulns on headless servers, Windows-only issues in Linux stacks).
- Auditors, insurers, and internal policies often make it easier to patch or upgrade than to argue a vuln is irrelevant, even when clearly unreachable.
- Some orgs mitigate by using exceptions/risk-based SLAs, but getting exceptions approved can be painful and politically fraught.
Problems with the CVE ecosystem
- CVSS base scores are seen as poor proxies for real risk; environmental/contextual scoring is hard and labor-intensive.
- Many CVEs target obscure or unused components (e.g., utilities bundled with libraries) yet force global upgrades.
- Chaining and defense-in-depth complicate “not exploitable” claims: minor bugs can become serious when combined.
- NIST/NVD is overloaded; CVE assignment is mostly clerical and trusts submitters, with no systematic PoC requirement.
- Large projects becoming CNAs try to regain control but are now flooded with AI-generated reports; some bounty programs have removed rewards due to slop.
LLMs in vulnerability discovery
- Thread agrees LLMs are now capable of finding real bugs, especially in old C/C++ code; maintainers report a rising volume of genuine issues.
- At the same time, LLMs hallucinate code, versions, and exploits, leading to bogus CVEs and wasted triage effort.
- Concern that attackers will combine scanning LLMs with exploit-writing LLMs and large compute to automate deep, lateral compromise.
- Anticipated next step: agents that auto-reproduce PoCs and filter out slop before humans see reports, though cost and reliability are open issues.
Debate over LLM capabilities and trust
- One camp emphasizes LLMs as stochastic next-token predictors requiring strict human verification, warning against over-trusting them in safety-critical workflows.
- Another camp argues that, despite being probabilistic, they already display nontrivial problem-solving and code analysis, and should be treated as powerful but fallible tools.
- Broader philosophical argument over whether brains are “just” probabilistic machines and what that implies for machine intelligence.
Proposed mitigations and governance
- Suggestions include: require working exploits for high-severity CVEs; finer-grained, usage-aware vulnerability scanners; automated PoC runners; better funding for NIST; and possibly professional licensure or stronger accountability for misuse of AI in critical domains.