We Will Always Have CVEs

Between October 17 and November 5, 2026, four ecosystems shipped urgent security fixes. A certificate authority's intermediate keys turned out to be guessable, and Go, Node.js, Java and several Linux distributions each shipped a fix to distrust them. PHP fixed two critical remote code execution bugs. Node.js fixed ten vulnerabilities in one release. OpenSSH fixed an authentication bypass that attackers were already trying within hours (The Hacker News).

Any one of those is an ordinary week of security work. Together, in under three weeks, they are the argument of this post: there are a lot of these, there are more every month, and the time we get to deal with them is shrinking. We should plan as if that is permanent, because I think it is.

The count only goes one way

I counted CVE records published in NVD, year by year. To compare years fairly I used the same span for each, January 1 to November 6:

From 2016 to 2025 annual publications grew from 6,449 to 48,150, about 7.5 times. 2026 has not slowed down. It stands at 92,345 with eight weeks left, 2.3 times the same span of 2025. It did not arrive as a single spike either:

Monthly publications rose in eight of the nine months since January. October alone was 17,056 records, four times October 2025. At that pace it is about 550 new records a day. Almost none of them touch any given stack, but nobody can know which without tooling.

Who is publishing? I sampled 2,000 records from each of three periods, in random blocks of 200, so treat the shares as a rough guide. No single source or bulk import explains the rise. July to September is spread across Oracle (14%), GitHub (13%), VulnCheck (11%) and VulDB (10%). In October, Chrome's CNA is about 27% of the sample, so the mix shifts from month to month. Linux kernel records fell from 9% of the sample to 3%, so it is not the kernel CNA flooding the feed.

I cannot tell you from this data why it is rising. The candidates are more software, more CNAs, more researchers and more automated discovery: fuzzers, static analysis and now LLMs. Records are also not risk. Some are duplicates, some are low severity, and some are in software you will never run. But whoever carries the pager does not get to choose which kind the next one is.

Where does it go from here? I do not have a model and I would not trust one. A nine-year climb, followed by a year running at more than double the last with no clear sign of levelling off in ten months, is not something I would plan against. The first six days of November are running at about 416 a day, below October's 550. That is six days, and I will not read a trend into it. Plan for more.

The clock is shrinking faster than the count

A count measures how much is published. The harder number is how fast the dangerous ones get exploited. CISA's Known Exploited Vulnerabilities catalog (KEV) lists CVEs with confirmed exploitation, and gives each a due date for US federal agencies. The gap between "added" and "due" is a public signal of how little time CISA thinks defenders have.

*2026 is through November 4.

From 2022 to 2025, 84% of entries gave agencies 21 days. In 2026 only 15% did, more than half got three days or less, and since June that is 125 of 161 (78%). CISA sets deadlines for agencies, not for you, but I read the shift as a judgment about speed.

The PHP bugs show what that looks like. The fixes shipped on October 21. By October 26 both CVEs were in KEV, due October 29. The Brotli overflow fixed in the same Node.js release was added the next day. SSHole's first exploitation attempt was reported under nine hours after its CVE was published.

What does not scale

Take one incident. The eMudhra compromise carries at least six CVE IDs in NVD, from Go, Oracle, Red Hat, NetApp and others, for a single root cause. The fix lives in many places: OS ca-certificates packages, language bundles (certifi 2026.10.19, composer/ca-bundle 1.4.16 and 1.6.0, per Konfirmity), runtimes, and Go binaries, which only change when you rebuild (The Hacker News). For a team with services in four languages that is a dozen fix paths for one problem, and that was one advisory in a week of several.

Patching also assumes someone is shipping patches. Ingress NGINX got best-effort maintenance only until March 2026, and after that no releases, bug fixes or security patches (Kubernetes blog). Some CVEs will never get a fix, only a replacement.

None of this is a reason to despair. It is a reason to stop treating patching as a project.

Make it boring

If CVEs are the weather, the job is to build for it. Here is what I would automate first.

1. Know what you run. One query, not a meeting:

kubectl get pods -A \
  -o jsonpath='{.items[*].spec.containers[*].image}' \
  | tr -s '[:space:]' '\n' | sort -u

Feed that to a scanner such as Trivy or Grype, keep the SBOMs, and re-scan them whenever an advisory lands. Scanning yesterday's image against today's CVEs is how "are we affected?" becomes a query.

2. Treat one incident as one incident. Group by root cause, not by ID. eMudhra is one task with many fixes.
3. Prioritize by exploitation, not by score. Start with KEV and EPSS, and with whether the vulnerable code is reachable, recorded in VEX as "affected but not exploitable". Three of this cluster's CVEs were in KEV within six days of their fixes.
4. Make the fix a pull request. Let bots bump versions and image digests, and let CI rebuild what only a rebuild can fix. Trust data belongs in the pipeline too, because the eMudhra fix was data, not code. The check for the distrusted root is one command, so write it once and run it against every image:

# Prints a line if the bundle still trusts the distrusted root
openssl storeutl -noout -text -certs /etc/ssl/certs/ca-certificates.crt \
  | grep -E "CN ?= ?emSign ECC Root CA - G3" \
  || echo "root not present"

5. Make rollout dull. Pin images by digest, enforce it at admission, roll out progressively and roll back automatically.
6. Contain what you cannot patch yet. Run pods as non-root with a read-only filesystem and no privilege escalation, default-deny the network, and at the ingress use a temporary rule to buy hours. Containment does not fix anything. It buys the pipeline time.
7. Run less. SSHole needed musl, no PAM and a running sshd, and nothing in a pod should run sshd. Every dependency is a subscription to someone else's advisory feed, and the cheapest CVE to patch is the one in software you deleted.

Where AI fits

AI cuts both ways, and I would rather say only what I can support. I found nothing attributing this cluster to AI-assisted discovery, so I will not claim it. What I can say is that finding bugs keeps getting cheaper, which I would expect to push the count up, and that exploitation can now be measured in hours.

The same tools can help defenders: summarizing advisories, matching them to inventory, proposing the patch pull request. But an advisory is text written by whoever filed it, and an agent that reads advisories while holding cluster credentials is a prompt-injection path. Give it read-only access, let it propose, and let policy and people approve.

The new norm

We will still have CVEs next year, and more of them. That is not a failure of any team. It is what a world with this much software looks like once more of it is being looked at. The number worth tracking is not how many CVEs we have. It is how long it takes to get from advisory to production, and how much of that time needed a human. Make that number small and boring. The next cluster should be a Tuesday.

Method and sources

Counts are CVE records published, from the NVD API with rejected records excluded and windows of at most 120 days summed, as of 2026-11-06. A quarter can be reproduced like this (July to September 2026 returns 36,954 today, though counts can drift as records are revised):

curl -s -G https://services.nvd.nist.gov/rest/json/cves/2.0 \
  --data-urlencode pubStartDate=2026-07-01T00:00:00.000 \
  --data-urlencode pubEndDate=2026-09-30T23:59:59.999 \
  --data-urlencode resultsPerPage=1 \
  --data-urlencode noRejected= \
  | jq .totalResults

KEV figures use the catalog feed (version 2026.11.04), with the due date minus the date added. The publisher shares come from the sample described above.

• NVD API documentation
• CISA Known Exploited Vulnerabilities feed (JSON)
• The Hacker News: SSHole exploited
• The Hacker News: Go emergency update
• Konfirmity: eMudhra intermediate CA compromise
• Courier: eMudhra and the PHP security release
• Checkmarx: after PHP and eMudhra, Node.js
• Kubernetes blog: Ingress NGINX retirement