The Impact of AI on CVEs: INDUSTRY CHALLENGES

Integrating artificial intelligence into cybersecurity has fundamentally changed vulnerability research – and not necessarily for the better. For decades, discovering and verifying Common Vulnerabilities and Exposures (CVEs) required deep technical expertise, creating a disciplined process that kept disclosure volume relatively manageable. Today, Generative AI has obliterated that barrier to entry.

While AI empowers seasoned security researchers to uncover complex zero-days at unprecedented speeds, it simultaneously enables a flood of low-effort, AI-generated vulnerability reports. The result is a fractured ecosystem struggling to stay afloat. The signal-to-noise ratio in vulnerability intelligence is plummeting, open-source maintainers are drowning in hallucinated “slop“, and foundational institutions like the American National Vulnerability Database (NVD) are buckling under the sheer volume of submissions.

In Part 1 of this series, we explore how the AI era has weaponized scale in CVE research. We examine the real-world toll on maintainers, the growing danger of severity inflation, the rise of fabricated security advisories, and the cost of keeping up with it all.

The CVE Surge in Numbers

The JFrog security research team has collected data about CVEs published since 2021. Below is a graph showing the steadily climbing increase in the volume of CVEs in recent years.

 Due to AI the volume of CVEs is growing at an alarming rate

The data shows a sharp increase in total CVEs, driven by two AI-related trends: experienced security researchers can now identify vulnerabilities faster and more easily, while lower skilled researchers can leverage AI to bypass traditional technical barriers, flooding systems with noise and real CVEs alike.

This surge caused major changes in how CVEs are being assessed and the quality of those assessments.

The Boy Who Cried Wolf

In January 2026, the consequences of this growing verification burden culminated in a stark milestone: Daniel Stenberg, creator of the widely used curl utility, announced the end of the project’s bug bounty program. According to Stenberg, an explosion of AI-generated submissions in 2025 contributed to a flood of invalid reports, and the share of submissions confirmed as vulnerabilities fell below 5%.

Just six months later, Michael Catanzaro, then the security coordinator for the GNOME project, announced changes to the GNOME security tracking system. Catanzaro stated he would no longer forward security reports to GNOME maintainers who had explicitly opted out of receiving AI-generated content. Because the overwhelming majority of incoming reports in 2026 utilized LLMs, he explained, the project was forced to operate under the assumption that the overwhelming majority of vulnerability reports  now contain AI-generated material. To manage this new reality, Catanzaro also slashed GNOME’s vulnerability disclosure deadline from 90 days to 30 for issues reported on or after August 1, 2026. Noting that some other projects, notably the Linux kernel, have implemented an immediate full disclosure policy for reports that seem to be AI-generated, GNOME adopted the shortened window as a compromise to accelerate the pipeline without crushing maintainers.

The National Vulnerability Database’s Policy Change

The deluge of CVEs has also led NIST to change how it prioritizes NVD analysis. In an April 2026 announcement on NVD operations, NIST said that starting April 15, 2026, it would prioritize CVEs in CISA’s Known Exploited Vulnerabilities Catalog, software used by the federal government, and critical software. NIST also moved backlogged CVEs published before March 1, 2026 to “Not Scheduled.” In our view, this leaves many published CVEs without NVD enrichment and pushes more of the verification burden onto enterprise security teams.

AI Shortens the Path from Disclosure to Exploitation

AI is not only accelerating vulnerability discovery; it is also reducing the time and expertise required to turn vulnerability information into a working exploit. In one May 2026 case involving CVE-2026-46529, which affects GNOME’s Evince document viewer and its forks, a researcher used Claude to help develop a weaponized, single-click code-execution exploit. Controlled research from PoCGen and Anthropic has demonstrated similar capabilities, showing how attackers could exploit the period between public disclosure and widespread patching.

Severity Inflation

Not every vulnerability labeled Critical represents a critical real-world threat. Severity inflation occurs when a rating is based on a theoretical or reasonable worst-case outcome without adequately accounting for the conditions required to enable it in the wild.

These conditions may include whether the vulnerable code is exposed, whether an optional feature is enabled, whether a particular configuration is present, or whether exploitation requires an unlikely sequence of events.

Annual number of CVEs segmented into Critical, High, and other severities

This distinction is built into CVSS itself. The official FIRST CVSS v4.0 User Guide  states that CVSS Base scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. Nevertheless, scanners, dashboards, and remediation policies frequently treat the Base score as a universal measure of urgency.

At JFrog, we provide additional, proprietary, research-backed severity assessments, allowing customers to prioritize vulnerabilities and define policies using trusted JFrog severity scores instead of relying solely on external Base scores.

The Cost of Scoring at Scale

The scale described earlier matters because vulnerability assessment does not expand automatically with vulnerability volume. Each score may require reviewing the affected code, reproducing the issue, inspecting its fix, and understanding how the component is deployed.

When thousands of records must be processed quickly, assessors may instead rely on short CVE descriptions, the general vulnerability class, or default worst-case assumptions. Volume alone does not make a score incorrect, but it increases the likelihood that important technical details might be missed.

Severity Dissonance: The curl Case

A clear illustration of severity inflation emerged in a recent four-month window involving the libcurl project. Since June, the maintainers have published 27 CVEs with assessed security impacts ranging from Low to Medium. However, when CISA evaluated these same vulnerabilities, nearly all were escalated to High or Critical scores.

When the JFrog Security Research team investigated this striking dissonance, we found that the assigned CVSS vectors had failed to reflect the vulnerabilities’ technical reality. For instance, flaws assigned Critical scores were often merely client-side crashes or required niche client configurations outside an attacker’s control. In several cases, client-side use-after-free bugs were miscategorized as network-based memory corruption threats, resulting in a Critical rating that, in our assessment, did not reflect the actual attack vector and practical security impact.

Faux CVEs: The Rise of AI Generated Slop

Generative AI is remarkably adept at mimicking the authoritative tone, formatting, and technical jargon required for a security advisory. The result is a growing wave of slop vulnerabilities that sound terrifying but either do not exist at all or are nowhere near as severe as they are presented.

Case Study: The SQLite Slop Advisories

A clear example of this systemic breakdown is the research we published at JFrog in July 2026 regarding a wave of critical advisories. A newly created GitHub repository published over 50 security advisories, a batch containing reports targeting SQLite alongside various other open source projects. The reports appeared polished and authoritative, detailing complex Use After Free (UAF) memory corruption flaws. They were swiftly assigned high CVSS scores, up to 9.8 Critical, and CISA’s ADP program agreed..

However, when our security researchers analyzed the target codebases to verify the claims, the reports completely fell apart. The technical details appear to have been hallucinated by an LLM:

• Nonexistent code: The advisories cited functions like exprComputeOperands() and jsonBlobEdit() that were not present in the targeted SQLite versions.
• Impossible line numbers: One advisory pointed to a vulnerability at line 3555 in a file containing only 2706 lines.
• Ghost fixes: Another claimed a fix was committed in a newer release, but source diffs showed zero changes to the referenced files.

Because the current CVE pipeline is overwhelmed by volume and does not require a working POC before scores are issued, these reports slide directly into downstream feeds. Out of 55 advisories published by that account, 54 were completely fabricated, yet reports like these can flow into GHSA, enterprise scanners, and developer alerts.

The Cost of Keeping Up

When a Flood of Fixes Arrives

The pressure becomes especially clear when a large number of fixes arrive together. According to Oracle, its July 2026 Critical Patch Update, its largest security release to date, addressed 1,434 distinct CVEs with 1,449 patches across 334 products. Oracle attributed the scale partly to AI-powered identification of actionable security findings. For customers, however, receiving more fixes does not make deploying them any simpler. Each organization still has to identify the affected systems, decide what is most urgent, test the relevant updates, and fit them into its release schedule.

AI is also uncovering bugs that were not detected even after years of conventional research. A security agent developed by depthfirst reported 21 zero-day vulnerabilities in FFmpeg, several of which had remained in the code for 15 to 20 years despite extensive fuzzing and manual review.

The Gap Between Discovery and Patching

AI can find vulnerabilities faster than developers can fix them. As AI increases the number of findings entering remediation queues, maintainers still have to verify each report, understand which versions are affected, develop and test a reliable fix, and prepare a release. Those steps do not become faster simply because discovery does. Rushing them can produce an incomplete patch or introduce new problems.

CISA has connected this pressure directly to AI-assisted discovery, stating that AI is vastly increasing the pace at which new vulnerabilities are found while defenders are already struggling to keep up. According to Verizon’s 2026 Data Breach Investigations Report, as cited by CISA, , organizations fully remediated only 26% of vulnerabilities in the Known Exploited Vulnerabilities catalog during 2025, down from 38% the previous year, while the median time for full resolution rose to 43 days. The UK’s National Cyber Security Centre has issued a similar warning, saying that AI-assisted discovery could create a vulnerability patch wave, with an influx of updates across all severity levels that organizations will need to deploy more frequently and at greater scale. Together, these sources show the practical effect of higher volume: even when teams improve their processes, a larger queue can still leave fixes waiting longer.

Stay Tuned…

AI has increased both speed and uncertainty across the CVE ecosystem. Finding vulnerabilities is no longer the only challenge, as verifying, prioritizing, and fixing those that pose a genuine risk has become equally important. In Part 2 of this series, The Impact of the AI-Era on CVE Research: PROTECTION STRATEGIES, we recommend best practices, demonstrate JFrog’s AI-assisted libheif exploit chain and show how JFrog Xray and JFrog Advanced Security help teams assess their actual exposure.

To gain a better understanding of how JFrog provides additional, proprietary, research-backed severity assessments, schedule a demo with our team.

Note: This blog content is provided for general informational and illustrative purposes. It reflects information available as of the publication date shown below and may not be updated. Examples and outcomes are illustrative; actual results may vary depending on your environment and use case. JFrog makes no representation or warranty that the content is complete, accurate, current, or suitable for your particular circumstances. You are responsible for evaluating the content before relying on it. This blog content does not modify any agreement governing your use of JFrog products or services. Product use remains subject to the applicable JFrog Subscription Agreement or other written agreement between you and JFrog.