Vulnerability Management in 2026: 48,185 CVEs, a Triaged NVD, EPSS v5

Every few weeks someone sends me a scanner report with four figures of findings and asks which ones matter. The honest answer in 2026 is that almost none of them do, and the hard part is proving which few do. Vulnerability management has changed more in the last eighteen months than in the previous ten: CVE volume broke records again, the NVD formally stopped trying to enrich everything, the CVE program itself came within a day of losing its funding, and the scoring signals we prioritise with (EPSS, CISA KEV, VEX, reachability) all moved. This post walks through what changed, what each signal actually tells you, and the order I would triage in today.

How many CVEs were published in 2025, and how many in 2026?

Jerry Gamblin's annual review counts 48,185 CVEs published in 2025, excluding rejected entries, a 20.6% rise on 2024's 39,962. That is about 132 a day, every day. Of those, 3,984 carried a critical CVSS score and 15,003 a high, so 39.4% of the year's output landed in the two bands most policies tell you to fix fast. The biggest assigners were not the vendors you might guess: Patchstack (7,007) and Wordfence (3,451), both WordPress plugin specialists, sit alongside VulDB, the Linux kernel CNA and MITRE in the top five.

2026 is running hotter. CyberScoop reported on 23 September that more than 67,000 new CVEs had already been published this year, and Gamblin's forecast quoted by Infosecurity Magazine was 70,135 by year end. Part of the jump is AI-assisted discovery, which I covered in AI Found the Bugs and part is simply more CNAs assigning more IDs.

The consequence is arithmetic. If 40% of a 60,000-a-year stream is "critical or high", a policy of "fix all criticals and highs within 30 days" is a policy nobody is following. Most teams already know this. Their scanners have not been told.

What happened to the NVD backlog?

The National Vulnerability Database is where most scanners historically got CPE product matches and a NIST CVSS score. Since early 2024 it has been behind, and in 2026 NIST stopped pretending otherwise. Its own NVD news page says submissions grew 263% between 2020 and 2025, Q1 2026 was nearly a third higher than Q1 2025, and NIST enriched about 42,000 CVEs in 2025, 45% more than any previous year. It still fell further behind.

So on 15 April 2026 NIST moved to risk-based enrichment. Full enrichment now goes first to CVEs in CISA's KEV catalog (with a goal of one business day), software used by the federal government, and critical software as defined under Executive Order 14028. Everything else is labelled "Lowest Priority, not scheduled for immediate enrichment", and every backlogged CVE with an NVD publish date before 1 March 2026 was moved into a "Not Scheduled" bucket. NIST also stopped adding its own CVSS score when the CNA already supplied one, and only re-analyses modified records when the change matters. Two weeks later it had to correct about 4,500 CVSS v4.0 scores (19% of records with a v4 score) that were too high.

What this means in practice: if your tooling depends on NVD CPE data to match a CVE to a product, a growing share of CVEs will never match. Scanners that use distro security trackers, GitHub Security Advisories, OSV and vendor feeds (Trivy and Grype both do) are less exposed than ones that lean on CPEs. It is worth asking your commercial vendor which bucket they are in.

Did the CVE program lose its funding?

Almost. On 15 April 2025 MITRE warned that its contract to run the CVE program would expire the next day. CISA exercised an option on the $57.8 million contract hours before the deadline, extending it for 11 months to March 2026. In the same week a group of CVE Board members launched the CVE Foundation, a nonprofit meant to end the program's dependence on a single government. By September 2025 CISA had published a short vision document asserting it would keep leading the program, and The Record reported that board members were still asking for the contract terms without an answer. That piece also noted that roughly 90% of CVE records come from the program's roughly 470 voluntary contributors, not from US-funded work.

The program kept running past March 2026: CVE IDs are still being assigned at record pace, and on 23 September 2026 CISA published a white paper describing a "Quality Era" for CVE, covering governance, participation, infrastructure and record content. I could not find a public statement of the contract terms after March 2026, so I will not guess at them. The lesson I took from the scare is narrower: your vulnerability pipeline should not have a single upstream. Use scanners that merge several feeds, and keep identifiers like GHSA and OSV IDs, not only CVE IDs.

CVSS, EPSS, KEV, VEX, reachability: what does each signal tell you?

These get treated as competing scores. They are not. Each answers a different question, and the useful thing is to stack them.

Signal	Question it answers	Who publishes it	Blind spot
CVSS	How bad is it if exploited, in a generic setting?	CNA or NVD	Says nothing about likelihood. 39.4% of 2025 CVEs scored critical or high (Gamblin)
EPSS	Probability of exploitation activity in the next 30 days	FIRST	Model retrains shift scores; weak on brand-new and supply-chain cases
CISA KEV	Has it been exploited in the wild?	CISA	Lagging and deliberately conservative; 1,748 entries
VEX	Is this product actually affected?	The software supplier, or you	Only as good as the author's analysis
Reachability	Does my code ever call the vulnerable function?	Your SCA tool	Language support varies; dynamic calls are hard

EPSS moved twice. Version 4 (model v2025.03.14) started publishing on 17 March 2025 and version 5 (v2026.06.15) on 15 June 2026, according to FIRST's data page, which warns that every model change causes a one-day shift in scores. If you trend EPSS over time, mark those dates. When I queried the EPSS API on 20 October 2026 it held scores for 391,411 CVEs, of which 17,323 (4.4%) were above 0.1. That ratio is the point: EPSS lets you push most of the queue down with a straight face.

KEV is the closest thing to ground truth. I pulled CISA's JSON feed (catalog version 2026.10.16): 1,748 entries, 245 added in 2025 and 264 so far in 2026, 361 marked as known to be used in ransomware campaigns. US federal agencies have to remediate KEV entries under BOD 22-01 deadlines; everyone else should treat KEV as "fix now, not this sprint".

Here is the caveat I want people to absorb. When Trivy itself was compromised in March 2026 (more below), the resulting CVE-2026-33634 went into KEV on 26 March with a remediation due date of 9 April. On 19 October its EPSS score was 0.017, around the 77th percentile. Log4Shell, for comparison, sits at 0.99999. EPSS is trained on exploitation telemetry against network services; a poisoned CI action does not look like that. Supply-chain compromises need their own path in your process.

VEX (Vulnerability Exploitability eXchange) is a machine-readable statement from a supplier that a product is or is not affected by a CVE, with a justification such as "vulnerable code not in execute path". There are three formats in use: OpenVEX, CycloneDX VEX and CSAF. Trivy accepts all three with some target limits; Grype supports OpenVEX. VEX is how a base-image vendor says "yes, the scanner sees that library, no, it cannot be triggered here" without you writing a hundred ignore rules.

Reachability is the SCA vendors' answer to the same noise. The best independent number I have found is a study of 2,414 repositories that measured a 92.0% false-positive rate in downstream vulnerability scanning, mostly from vulnerabilities in code the application never calls; function-call analysis pruned 61.9% of those alarms. Vendor claims run higher. Treat reachability as strong evidence for deprioritising, not as proof of safety.

How should you prioritise vulnerabilities in 2026?

This is the order I use. It is not novel; CISA's SSVC decision trees say much the same thing in more formal language. The value is in writing it down and wiring it into tooling so the scanner output arrives pre-sorted.

1. Supply-chain compromise of something you run or build with. Malicious package, poisoned action, hijacked image tag. Treat as an incident: rotate credentials, not just versions. EPSS will not flag these for you.
2. In KEV, or vendor-confirmed exploitation, on an internet-facing or privileged path. Days, not weeks.
3. EPSS above your threshold (I start at 0.1) and reachable or exposed. Next sprint.
4. Critical or high CVSS, fix available, no exploitation signal. Batch it into routine base-image and dependency updates; a weekly rebuild clears most of these without anyone opening a ticket.
5. Covered by a VEX not_affected statement or proven unreachable. Record the decision with an expiry date and move on.
6. No fix available and none of the above. Accept, document, revisit when a fix lands.

The fourth bucket is where the volume lives, and the cure is boring platform work rather than triage: minimal or hardened base images, automated dependency PRs, and rebuilding on a schedule so fixes ship whether or not a human looked. Here is a small script that does the first three sorts for a container image. It uses only the public KEV feed and the EPSS API.

#!/usr/bin/env bash
# triage.sh IMAGE  -> prints KEV hits first, then CVEs with EPSS >= 0.1
# Requires: docker, jq, curl. Trivy pinned to v0.76.0 (released 2026-10-14).
set -euo pipefail
IMAGE="${1:?usage: triage.sh IMAGE}"

# 1. Scan once, JSON out. --scanners vuln skips secret scanning for speed.
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy:0.76.0 image --scanners vuln --format json --quiet "$IMAGE" > scan.json

jq -r '[.Results[]?.Vulnerabilities[]?.VulnerabilityID | select(startswith("CVE-"))]
       | unique | .[]' scan.json > cves.txt

# 2. Known exploited: intersect with CISA KEV.
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | sort > kev.txt
echo "== In CISA KEV (fix now)"
sort cves.txt | comm -12 - kev.txt

# 3. Likely to be exploited: EPSS in batches of 100 CVEs per request.
echo "== EPSS >= 0.1 (next sprint)"
xargs -n 100 < cves.txt | tr ' ' ',' | while read -r batch; do
  curl -s "https://api.first.org/data/v1/epss?cve=${batch}" \
    | jq -r '.data[] | select((.epss|tonumber) >= 0.1) | "\(.cve)\t\(.epss)"'
done | sort -t$'\t' -k2 -nr

The companion guide on scanning images with Trivy and Grype covers installation, CI gates, ignore files and VEX in detail.

What the Trivy compromise taught about scanner trust

The most widely used open-source image scanner was itself a supply-chain victim this year. According to Aqua's incident write-up, attackers abused a GitHub Actions misconfiguration in late February to take a privileged token; the 1 March credential rotation was incomplete; and on 19 March they published a malicious Trivy v0.69.4 binary, force-pushed 76 of 77 tags in aquasecurity/trivy-action and all tags of setup-trivy to credential-stealing code. Malicious Docker Hub images tagged 0.69.5 and 0.69.6 followed on 22 March. Only trivy-action v0.35.0, protected by GitHub's immutable releases, was untouched.

The irony writes itself, but the lesson is ordinary. Your security tooling runs in CI with the same secrets as everything else, so it needs the same controls: actions pinned to full commit SHAs, binaries verified against their Sigstore bundles, least-privilege tokens, and egress you can see. This is the same pattern as the npm worms that targeted developer tooling, and it is why SBOM and provenance requirements like those in the EU Cyber Resilience Act matter even for teams who never sell into Europe. Platform discipline is what makes the AI-era volume survivable; it does not get less important because the bugs are found faster.

FAQ

What is the difference between EPSS and CVSS?

CVSS estimates how severe a vulnerability would be if exploited, using properties of the bug. EPSS estimates the probability that it will see exploitation activity in the next 30 days, using observed threat data. Use CVSS to understand impact and EPSS to decide what to do first.

Is the NVD still useful in 2026?

Yes, but not as a single source. Since 15 April 2026 NIST fully enriches only KEV entries, federal software and EO 14028 critical software first, and older backlogged CVEs are marked Not Scheduled. Prefer scanners that combine distro advisories, GitHub advisories and OSV with NVD data.

Should I fail CI builds on every critical CVE?

Only on critical or high findings that have a fix available, and preferably only for new findings in the change. Failing on unfixed CVEs blocks work without reducing risk. Pair the gate with scheduled rebuilds so existing fixable findings clear on their own.

What is a VEX document?

A VEX document is a machine-readable statement, usually from a software supplier, saying whether a product is affected by a specific vulnerability and why. Scanners such as Trivy and Grype can consume VEX to suppress findings marked not affected. OpenVEX, CycloneDX VEX and CSAF are the common formats.

This quarter I would do three things on any platform I was responsible for: wire KEV and EPSS into the scanner output so nobody reads an unsorted list again, put every scanner and security action behind SHA pins and signature verification, and move base images to a weekly automated rebuild so the fixable-high backlog shrinks without meetings. Everything else can wait for a VEX statement.

Related: AI Found the Bugs: 23,000 Findings in a Month, a 3-Day Patch Mandate, and the End of curl's Bounty, CRA Reporting Went Live on 11 September: 24 Hours to ENISA, 3.08 Billion Rekor Entries, 17% of PyPI Attested, 92% SBOM False Positives and The Worms Learned to Use Your AI Agent: A Year of npm Supply-Chain Attacks.