A Common Vulnerability and Exposure (CVE) is a known, cataloged security flaw. When a vulnerability gets a CVE, it means the security community has identified it, named it, and added it to a public database (primarily cve.org with scoring and context added by NIST's National Vulnerability Database (NVD)) so anyone can look it up and act on it. Tracking CVEs gives the security world a common reference point, so teams can prioritize and respond to known flaws before attackers exploit them. Simple in theory, right?
Here's the catch: 48,000+ CVEs were published in 2025 alone. That's 131 new vulnerabilities every single day. AI models and scanning capabilities are making vulnerability discovery faster and more accessible than ever, but validating findings at scale is harder because the sheer volume of submissions is outpacing the infrastructure built to handle them. The NVD is buckling under the volume, and a growing number of real vulnerabilities never get reported at all.
This guide covers how CVEs work, how they're scored, where the system is breaking down, and what teams are doing to stay ahead of it.
What does a CVE record include?
A CVE ID is like a serial number, formatted as: 'CVE-YYYY-#####'.
Each record contains:
- CVE ID
- Description
- References
- Assigning CNA
- Date Record Created
Older CVE records may also include legacy fields, such as phase, votes, comments, and proposed, which are no longer used in new entries.
Who maintains the CVE database?
The short answer is: no single organization does. And that's increasingly the problem.
The MITRE corporation oversees the CVE program itself, assigning IDs and maintaining the official list, and all CVE records are free to search and use. The NVD has historically been where those raw CVE entries get enriched with CVSS scores, patch details, and technical context. It's also where most security tools pull their data. The Cybersecurity and Infrastructure Security Agency (CISA) provides funding support. Other databases, like the CERT/CC Vulnerability Notes Database and GitHub Advisory, fill in additional gaps.
But none of these were ever truly complete, and in 2026, the cracks are hard to ignore. NIST has adopted a 'risk-based' approach that prioritizes CVEs for US government software and those in the Known Exploited Vulnerabilities (KEV) catalog, leaving the rest unenriched, with the growing backlog effectively moved to 'not scheduled.' MITRE's CVE program has faced funding scares. The EU has launched its own alternative, the European Vulnerability Database (EUVD), but it's early days and still relies heavily on syncing with the NVD. There is no single source of truth anymore, and being reliant on any one database means you have less coverage and visibility than you hope. This is exactly the problem Aikido Intel was meant to solve: monitoring millions of open-source packages for security-relevant patches that never make it into any official database, and feeding findings directly into the Aikido platform so users are alerted automatically.
How are CVEs found and assigned?
Anyone can report a vulnerability: security companies, independent researchers, individual developers, even curious users. Many organizations run bug bounty programs that pay researchers for valid findings, and open-source projects typically rely on community disclosure.
Once a vulnerability is reported, a CVE Numbering Authority (CNA) validates it, assigns a CVE ID, writes a short description, and adds references before publishing it to the official CVE list. CNAs are organizations authorized by MITRE to assign CVEs within a defined scope, including major vendors like Microsoft, Google, and RedHat, open-source foundations like Python Software Foundation, security research firms, as well as platforms like Django and GitLab. Typically, a CVE ID is assigned before the vulnerability is made public. Vendors keep the details under wraps while they develop and test a fix, then disclose everything at once. This is known as coordinated disclosure, the widely recommended standard for responsible vulnerability reporting, backed by CISA, ENISA, and FIRST.
Not every reported issue qualifies. Three criteria must be met:
- Independently fixable: The flaw can be fixed on its own, independent of other bugs.
- Acknowledged by the vendor: The vendor confirms the issue poses a security risk, or a third-party report demonstrates its impact.
- Affects one codebase: If a vulnerability affects multiple products, each gets its own CVE. Records are kept as isolated as possible.
How can I find CVE records?
CVE information is free and publicly available. For a live feed of new entries, follow @CVEnew on X. At the current rate of 130+ new CVEs per day, it moves fast. For bulk access to historical records going back to 1999, CVE.org/Downloads offers the full database via a GitHub repository in JSON 5.0/5.1 format, updated approximately every seven minutes. CVEdetails.com provides a more accessible, searchable interface with daily updates.
How do you match your libraries to the right CVE?
When analyzing a vulnerability, the key is to match on the package name and version number to ensure you're looking at the right CVE for your specific dependency. Tools like Aikido handle this automatically by matching package names and versions against vulnerability databases, so you don't have to do it manually.
What is CVSS scoring?
The CVSS (Common Vulnerability Scoring System) is the standard used to rate the severity of a vulnerability on a scale from 0.0 to 10.0. Most CVE entries carry a CVSS score, giving security teams a quick read on how serious a flaw is. CVSS scores are typically assigned by the NVD as part of its enrichment process, though CNAs may also provide scores. Where they disagree, both may be listed.
How is a CVSS score calculated?
CVSS v4.0 is composed of four metric groups:
- Base: captures the intrinsic characteristics of a vulnerability that are constant over time
- Threat: reflects how those characteristics change based on real-world exploitation activity
- Environmental: accounts for factors specific to your organization's setup
- Supplemental: adds extra context without affecting the final score
What is the CVSS scoring scale?
The current (v4.0) CVSS Scoring Scale includes five categories:
- Critical (9.0–10.0)
- High (7.0–8.9)
- Medium (4.0–6.9)
- Low (0.1–3.9)
- None (0.0)
To put the scale in context, here are some real examples:
- Critical: CVE-2021-44228 (Log4Shell). CVSS v3.1 score: 10.0. A remote code execution in Apache Log4j. An attacker could execute arbitrary code on a server by sending a specially crafted log message. One of the most severe vulnerabilities ever disclosed.
- High: CVE-2017-0144 (EternalBlue). CVSS v3.1 score: 8.8. A flaw in Windows SMB (Server Message Block). Originally developed as an exploit by the NSA, it was leaked in 2017 and almost immediately weaponized in the WannaCry and NotPetya ransomware attacks, which caused billions in damages worldwide.
For the lower tiers, well-known named examples are rarer, since low-severity vulnerabilities don't often make headlines. In practice:
- Medium: Typically includes flaws that require specific conditions to exploit, for example, a cross-site scripting vulnerability that needs user interaction, or a misconfiguration exposing non-critical data.
- Low: Flaws that require local access or unusual conditions, for example, a configuration file with default credentials that can only be accessed locally.
- None: A reported issue with no security impact confirmed
Download a copy of the full CVSS scoring system user’s guide.
How do I find a CVSS score for a CVE record?
CVSS scores are displayed directly on each CVE's record page in the NVD, with support for both v3.x and v4.0 scores where available. Bear in mind that as NVD's enrichment coverage narrows, scores may be missing or based solely on the submitter's assessment rather than independent analysis. Aikido's vulnerability database is a useful cross-reference, drawing on multiple sources rather than NVD alone.
What is a CWE?
Common Weakness Enumeration (CWE) is a community-developed list of common software and hardware weaknesses, maintained by MITRE. The main goal of CWE is to stop vulnerabilities at the source, eliminating the most common mistakes before products are delivered. It also gives developers a shared framework for discussing and addressing security threats, with direct mappings to vulnerability databases like CVE.
The key distinction: CWE describes the underlying weakness that leads to a vulnerability, while CVE identifies a specific instance of a vulnerability. Think of CWE as the category, CVE as the occurrence. Like CVE, CWE has its own severity scoring system via CWSS and CWRAF.
Have a look at the top 25 most dangerous CWEs for 2025.
Why CVE monitoring is getting harder
The volume problem is real: CVE submissions increased 263% between 2020 and 2025, and submissions in the first three months of 2026 are nearly one-third higher than the same period last year. That growth is only accelerating, and open-source registries are a big reason why.
AI has dramatically lowered the barrier to publishing open-source packages, and the registries are feeling it. The number of packages flowing in means that meaningful review is increasingly rare, and the infrastructure built to track and contextualize vulnerabilities is under the same strain.
The NVD was built to enrich every CVE, adding CVSS scores, product lists, and technical context that make raw CVE records actually usable. NIST enriched nearly 42,000 CVEs in 2025, which is 45% more than any prior year. But that increased productivity wasn't enough to keep up with growing submissions. As we covered above, NIST has now deprioritized enrichment for the majority of CVEs. The tools your team relies on to surface and score vulnerabilities are, for a growing chunk of the CVE universe, operating on incomplete data without telling you.
The limits of CVEs: what doesn't get reported
The NVD problem is only part of the story. The deeper issue is that CVEs only cover what gets disclosed, and a lot doesn't.
In a single week of Aikido Intel monitoring, 12 out of 16 flagged vulnerabilities had no CVE assigned at all. These weren't obscure edge cases either. Axios, with 56 million weekly npm downloads, silently patched a prototype pollution vulnerability that still has no CVE. Apache ECharts patched a cross-site scripting issue and never disclosed it. Of the vulnerabilities that did eventually get a CVE, the average time from patch to disclosure was 27 days, with some taking as long as nine months.
Rather than depending on centralized databases, Intel uses custom-trained LLMs to scan changelogs, release notes, and commit messages across millions of open-source packages, surfacing security-relevant patches before they ever get a CVE ID, and cross-referencing against five key vulnerability databases for broader coverage. If no disclosure exists, Aikido security engineers validate and publish an advisory with an Aikido Vulnerability ID. In its first year, 67% of vulnerabilities Intel flagged had never been disclosed to any public database. Intel feeds directly into the Aikido platform, so when a new vulnerability is found, users are alerted automatically, even before it's been assigned a CVE.
What can I do to maintain a strong security posture?
Not every CVE is your problem. You need a layered approach. CVSS scores are a useful starting point, but they don't account for your specific context. A more actionable signal is CISA's KEV catalog: if a CVE is listed there, it's being actively exploited in the wild. But KEV covers less than 1% of all CVEs and skews toward network-perimeter vulnerabilities, so it’s far from exhaustive.
The Exploit Prediction Scoring System (EPSS) is another useful layer. It predicts the probability that a vulnerability will be exploited in the next 30 days based on real-world threat intelligence, helping you deprioritize the long tail of CVEs that are unlikely to ever be weaponized. Aikido supports EPSS-based prioritization natively, automatically downgrading low-risk issues so your team can focus on what matters.
Before escalating any vulnerability, consider:
- Reachability: The vulnerable function may not be reachable in your application, a key reason why reachability analysis, not raw CVSS scores, should drive your prioritization.
- Business impact: The affected component may not touch critical systems, customer data, or core operations.
- Unique environment: Custom or legacy systems may face different risk profiles than the standard CVE description assumes.
- Existing controls: You may already have defenses in place that neutralize the risk.
- Resource constraints: Fixing everything isn't realistic. Prioritize what's actually exploitable and impactful.
Get a vulnerability scanner
The best place to start is Aikido Security, a platform built specifically to cut through the noise that makes most CVE scanners exhausting to use. Traditional scanners surface hundreds of raw alerts regardless of whether a vulnerability is actually exploitable in your environment. Aikido's reachability analysis traces execution paths through your code to determine which vulnerabilities can genuinely be reached and triggered, filtering out non-reachable issues, false positives, and irrelevant findings, often achieving up to 95% noise reduction.
Get ahead of the CurVE
CVEs describe vulnerabilities that have already been identified and cataloged. By the time a CVE is published, attackers may have had days or weeks to act on it. And as we saw above, many vulnerabilities never get a CVE at all.
Staying ahead means more than reactive patching. Keep dependencies up to date and check your code against the OWASP Top 10 2025 and CIS compliance benchmarks, the standard tools for identifying the most common weaknesses and baseline security misconfigurations. You can check your OWASP and CIS scores directly in Aikido. For threats that haven't been cataloged yet, Aikido Intel monitors over 4.3 million open-source packages to catch vulnerabilities before they have a CVE ID.
See which CVEs actually affect your codebase.
{{cta}}
