What is a CVE and what you should know
A clear explanation of CVEs, CVSS scoring, and their real-world security impact.
Every week brings another “critical vulnerability” headline. Another CVE. Another urgent alert.
After years in application security, I have watched CVE counts accelerate and the pressure on teams intensify.
The conversation has shifted from understanding vulnerabilities to simply reacting to them.
In this article, we will step back. What exactly is a CVE? How did we get from a few thousand per year to nearly fifty thousand?
And what does that growth actually mean?
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. They are unique, common identifiers for publicly known vulnerabilities in publicly released software. The idea is that CVE IDs are used as a reference method when talking about a specific vulnerability.
The benefit is that all future discussions and coordination can refer to the CVE number to make sure all parties are referring to the same vulnerability. That way, it’s easy to track and fix these issues or look up more information about them before attackers might exploit them.
The CVE IDs syntax follows a specific format:
- CVE prefix + YEAR + Arbitrary Digits
- CVE-YYYY-NNNN (the NNNN suffix expands when needed in a calendar year)
For example:
Back in 1999
The MITRE Corporation presented the original concept for what would become the CVE List in January, 1999. From that concept, a working group formed and produced the first 321 CVE records. The CVE List officially launched in September 1999.
Did you know that the first CVE-1999-0001 was a Denial-of-Service (DoS) vulnerability?
During the first 17 years, from 1999 to 2016, the year-over-year growth rate was around ~5000 new entries. But everything changed in 2017.
In the preceding years, there were the first major incidents:
- CVE-2014-0160 (Heartbleed)
- CVE-2014-6271 (Shellshock)
Companies began auditing dependencies aggressively, bug bounty programs expanded, and security researchers shifted significantly toward open-source software. Cloud platforms expanded rapidly with the introduction of Kubernetes and Docker.
Security tooling evolved quickly, and CI/CD integrations started uncovering vulnerabilities at scale. Tons of previously unnoticed bugs started receiving CVE IDs.
MITRE Corporation scaled up the CNA (CVE Numbering Authority) model. Before, MITRE assigned most CVEs centrally. CVEs were often bundled (one CVE per product release), and many minor issues never received IDs. Then hundreds of vendors became CNAs. Companies could assign CVEs to their own products directly.
This decentralization alone dramatically increased volume. Individual bugs (even low-severity issues) started getting individual CVEs. As a result, in 2017, the number of published CVEs more than doubled.
When is it critical?
A vulnerability severity level reflects its overall impact and risk. To calculate that, we use CVSS. The Common Vulnerability Scoring System is an open framework for rating the severity of security vulnerabilities in computing systems. Scores are calculated based on a formula that approximates the difficulty and impact of an exploit. It assigns scores ranging from 0 to 10, with 10 indicating the most severe.
There are several metrics in the formula, different versions, and it’s somewhat difficult to understand that, so that’s for another article. The important thing is that a wide range of organizations has adopted CVSS as the primary method for quantifying the severity of vulnerabilities, and it is the norm for CVEs.
| Severity | CVSS Score |
|---|---|
| None | 0.0 |
| Low | 0.1 - 3.9 |
| Medium | 4.0 - 6.9 |
| High | 7.0 - 8.9 |
| Critical | 9.0 - 10.0 |
Critical counts are higher than at any point in history. 2024 and 2025 show the largest spikes in Critical ever recorded.
We have observed a new trend over the past 5 years. While medium-severity vulnerabilities are growing fastest, High- and critical-severity vulnerabilities are also rising in absolute terms. This trend suggests both improved detection and a growing attack surface. As a result, overall exposure risk is increasing.
Why so many CVEs?
We are now in the area of AI agents and machine learning, and there is massive growth in total software and digital services. Bug bounty programs matured, we have more security researchers than ever, and the tooling improved exponentially.
Security testing is becoming a standard practice across organizations, driven in part by evolving laws and regulatory requirements.
As the ecosystem expands (cloud, APIs, SaaS, IoT), the broader attack surface naturally increases the total number of vulnerabilities.
Is the risk growing?
In the 5 years preceding 2017,
we saw around ~5k new CVEs every year. In the five years that followed,
we saw around ~20k new CVEs every year.
Now, let’s take a look at the past 3 years. The growth is around ~40k, with 2025 breaking an absolute record of ~48k new CVEs.
It took us 19 years to cross the total of 100k CVEs, 5 years to cross 200k, and just a little over 2 years to reach 300k+.
The volume of vulnerabilities is growing because the digital ecosystem is growing. Whether risk is growing depends on how well organizations manage exposure, but the attack surface is undeniably expanding.
If you are not monitoring CVEs in 2026, you are massively increasing the risk to your organization.
Exploited in days
The “will patch next quarter” mindset no longer works.
Security researchers now discuss findings publicly, and exploitation of new vulnerabilities can occur within days (sometimes within hours).
We already shifted from the typical timeline of:
CVE disclosure → Analysis → long patch cycles within organizations.
What we are seeing now is typically:
CVE disclosure → Analysis → Proof of Concept → Exploitation.
With AI agents doing public patch diff analysis and automating the whole workflow efficiently.
Now what?
These are not new problems, but their scale is increasing rapidly:
- The volume challenge (tens of thousands of new CVEs annually)
- The prioritization challenge (not all CVEs matter equally)
- The shift from “patch everything” to “prioritize intelligently”
- The need to focus on relevance, exposure, and exploitability
- A subtle transition to better visibility and filtering
- Alert fatigue within security teams.
That’s why we are building CVEalert, to help small organizations establish a software catalog and kick-start their vulnerability management.
CVEalert.io provides visibility and tracking of an organization’s software assets and their CVEs.
It’s not whether CVEs are growing. It’s how teams handle the growth effectively.
We are still in a very early stage, but we are here to help you.
References: