AI Is Now Faking Cyberattacks

AI is now faking critical vulnerabilities, and the implications are chilling. The digital landscape faces a new, insidious threat: an AI-generated ghost in the machine, designed to mislead and disrupt.

JFrog's security team recently unearthed a disturbing trend: 54 fabricated SQLite vulnerabilities stemming from a single, new GitHub account. An audit of 55 advisories from this source revealed only one legitimate bug; the others were pure fiction. Intriguingly, GPTZero analysis flagged these advisories as unequivocally AI-generated content.

Examine the anatomy of one such phantom, CVE-2026-51302. The advisory claimed a heap use-after-free vulnerability in the exprComputeOperands function within SQLite 3.41. Yet, JFrog's investigation confirmed exprComputeOperands did not exist in that version, but only appeared in mid-2025. This was no isolated incident; across six advisories, JFrog found consistent patterns of cited non-existent functions, line numbers exceeding file limits, and patches that never occurred.

Astonishingly, this blatant fabrication still received an initial 9.8 'Critical' severity score from Red Hat. This high-stakes rating triggered real-world alerts across organizations, demonstrating how effortlessly a sophisticated AI-generated ghost can slip past initial gatekeepers. The incident underscores a perilous new frontier where AI can weaponize information, creating credible-looking threats that demand immediate, but ultimately wasted, attention.

System's Achilles' heel now lies exposed, gaping wide for exploitation. Since February 2024, NIST's NVD (National Vulnerability Database) has halted deep analysis on submissions, overwhelmed by a staggering backlog. This critical failure means over 27,000 unprocessed vulnerabilities are expected by the end of 2025, a dramatic surge from 13,000 just in February 2024, with CISA’s own enrichment program similarly drowning in its own queues.

Compounding this systemic breakdown, the CVE submission process itself offers virtually no gatekeeping. It requires neither identity verification nor any proof-of-concept to accept a vulnerability. This open-door policy provides a frictionless path for anyone—or anything—to inject claims directly into the global security infrastructure, no questions asked.

This creates a perfect storm, a catastrophic alignment of systemic vulnerabilities. A massive analysis backlog at the official database, coupled with a submission portal demanding zero scrutiny, means low-effort, AI-generated "slop" now slides effortlessly into the very databases security tools across the globe depend on. Automated defenses are now tasked with sifting through synthetic noise, potentially hunting for non-existent functions or attempting to patch code that was never broken.

Organizations relying on AI security agents for automated vulnerability triage now face a new, insidious threat. These sophisticated tools, designed to proactively identify and patch weaknesses, are being duped by the very AI that generates fake CVEs. Instead of safeguarding systems, your agents could be weaponized against themselves, wasting resources on phantom threats.

Imagine an autonomous agent trying to patch CVE-2026-51302, a fabricated SQLite vulnerability initially flagged as critical by Red Hat. It would exhaust compute cycles attempting to locate the non-existent function exprComputeOperands in SQLite 3.41, or trying to fix code that was never broken. This isn't just a theoretical problem; JFrog’s audit revealed 54 fabricated advisories out of 55 from one GitHub account, all designed to send agents on these wild goose chases.

The asymmetry of this problem is staggering. Crafting a convincing, AI-generated fake CVE is virtually free, a few cents of compute. Yet, verifying and debunking it demands significant expert human effort—painstaking code review, cross-referencing, and independent analysis. This creates an unsustainable burden on security teams, drowning them in a sea of AI-generated noise. For deeper insights into this phenomenon, read SQLite Critical CVEs or LLM Slop? - JFrog Security Research.

The age of implicit trust in public vulnerability feeds is over. Security teams must now operate under a new first principle: never trust, always verify. Before mobilizing any response to a critical CVE, cross-reference it immediately with the vendor’s official security page. This crucial step separates legitimate threats from AI-generated phantoms.

This isn't a mere suggestion; it's a mandate born from systemic failures. The NIST NVD backlog, which by late 2025 swelled to over 27,000 unprocessed vulnerabilities, created an environment ripe for deception. A submission system lacking identity verification or proof of concept allows fabricated advisories to slide straight through.

Industry consensus now shifts dramatically away from fully automated AI agents for vulnerability triage. The future demands hybrid models, where human experts validate AI-surfaced threats, acting as the critical filter against sophisticated digital deception that can assign a 9.8 critical score to non-existent code.

AI-generated 'slop' will increasingly degrade the signal-to-noise ratio in public feeds, forcing organizations to adapt their security posture. Assume every new report is potentially fake until proven otherwise, and prioritize vendor-confirmed threats above all. Your security operations must become inherently skeptical, investing in the human expertise that can differentiate genuine threats from AI-fabricated ghosts. The cost of verification now pales in comparison to the operational cost of being duped.

What are AI-generated fake CVEs?

They are fabricated vulnerability reports created by AI to mimic real security flaws. These fakes often contain plausible-sounding but entirely false technical details, designed to get accepted into official databases.

How did a fake CVE get a 9.8 critical score?

The fake advisory was submitted to the official CVE program. Due to a massive backlog, NIST's NVD is performing less deep analysis, allowing unverified reports to be processed. Downstream vendors like Red Hat then assigned an initial score based on the flawed data.

Why are fake CVEs a major security threat?

They mislead automated security tools and human teams, wasting critical resources on non-existent threats. This 'boy who cried wolf' scenario erodes trust and can cause teams to miss real vulnerabilities.

How can you protect your organization from fake CVEs?

Always verify critical CVEs against the official vendor's security advisory page before taking action. Implement a human-in-the-loop process to validate alerts from automated systems and never trust a CVE at face value.