![[261103] Why Are Software Vulnerabilities Growing So Fast?](https://www.x-cmd.com/icons/apple-touch-120x120.png){kind=icon}
TLDR
- Growth Trend : Public vulnerabilities are experiencing explosive growth, with 2026 projections nearing 75,000 entries.
- Core Reasons : Driven by increasing software dependency complexity (especially AI toolchains), the proliferation of automated and AI scanning tools, and broader coverage of vulnerability disclosure ecosystems.
- Mitigation Strategy : CVE counts do not equal actual risk; developers do not need to track every vulnerability, but should focus on rapid triage of core risks within their own technology stacks.
In the previous article, we discussed how the number of CVEs has been steadily increasing over the past few years.
From 43,471 entries in 2025 to over 50,000 so far in 2026, the rate at which public vulnerability records are increasing has accelerated significantly. Looking at annual data:
| Year | CVE Count |
|---|---|
| 2026 (To date) | ~56,000 |
| 2025 | 43,471 | | 2024 | 38,451 | | 2023 | 30,616 | | 2022 | 26,445 | | 2021 | 22,601 | | 2020 | 19,392 |
At the current growth pace, the full-year figure for 2026 may continue to climb. Calculated at the current growth rate, the total number of CVEs for the year could approach 75,000.
Seeing this change naturally raises a question:
Why are vulnerabilities increasing so rapidly?
Has software quality declined?
The reality is not that simple.
Changes in CVE counts are related to both the scale of the software ecosystem and shifts in how vulnerabilities are discovered and disclosed.
Software Dependencies Are Becoming Increasingly Complex #
Modern software projects rarely rely solely on their own code.
An application may depend on a multitude of open-source libraries, foundational components, and third-party services.
This is even more pronounced in AI applications.
An agent project may simultaneously involve model runtimes, frameworks, vector databases, tool services, plugins, and various basic dependencies.
As the number of dependencies increases, the issues capable of being discovered and recorded also rise.
Many CVEs are not suddenly appearing as brand-new issues, but rather flaws in certain components that have been formally documented after analysis.
Vulnerability Discovery Methods Have Changed #
In the past, many vulnerabilities relied on manual analysis by security researchers.
Today, static code analysis, fuzzing, automated scanning, and other tools have become vital methods for finding vulnerabilities.
When the same piece of code is inspected with the participation of more tools, it exposes more previously undiscovered problems.
In recent years, AI-assisted code analysis has also entered the security domain, helping researchers handle larger-scale codebases.
Improvements in discovery capabilities naturally lead to an increase in public vulnerability counts.
More Projects Enter the Vulnerability Disclosure System #
Another easily overlooked reason for the growth in CVE numbers is:
An increasing number of organizations are participating in vulnerability disclosure.
More vendors, open-source projects, and security teams are submitting vulnerability records.
Some issues that were previously only patched internally within projects may now enter public databases and receive their own CVE identifiers.
This makes vulnerability information more transparent while keeping statistical figures on an upward trajectory.
CVE Count Does Not Equal Actual Risk #
CVE counts are useful for observing macro trends, but they do not directly represent risk.
Determining whether a vulnerability requires priority handling also requires factoring in:
- Whether it affects components currently in use;
- CVSS severity level;
- Whether public exploits exist;
- EPSS exploitation probability;
- Whether it has entered the KEV list.
A low-risk vulnerability with a high count and a core component vulnerability that has already been exploited by attackers require completely different triage priorities.
What Do AI Builders Need to Focus On? #
AI applications rely on an expanding number of components, making the impact of CVE growth much more direct.
However, developers do not need to track every single vulnerability.
What is more practical is focusing on your own technology stack:
Are there related vulnerabilities in the model runtime you use?
Have security issues emerged in your agent framework?
Does tool invocation involve permission risks?
Does the execution environment present possibilities for code injection?
The value of CVE data is not to have people browse vulnerability lists daily, but to enable quick information retrieval when problems arise.
What Else Can Be Seen from CVE Data? #
We have compiled a set of CVE intelligence data tailored for AI builders:
[x-cmd.com/cve](https://x-cmd.com/cve)
It currently contains approximately 370,000 CVE records and continuously synchronizes public vulnerability data.
While compiling this data, one prominent realization is: A single CVE is merely an isolated vulnerability record.
However, when massive records are brought together, you can observe which problems persist long-term and how new risks emerge as the software ecosystem evolves.
Later, we will discuss the data curation process behind this dataset and how these statistical results are generated.
Please indicate the source and link of this article when reprinting.
Help us make these docs great!
All X-CMD docs are generated from command help and multiple data sources. See something that's wrong or unclear? Feel free to let us know through any of these ways~