Everything is a critical CVE now, which means nothing is

Counted them this morning out of morbid curiosity: eleven “critical” CVEs crossed my feeds this week. Eleven. Scored 9-point-something, “patch immediately,” the whole liturgy. I checked three of them properly. One needed local root access and physical presence at the console to exploit, which is a threat model I believe we used to call “someone’s already in your house.”

This isn’t a rant about any single vendor’s PR team overselling a bug to get ahead of the news cycle, though sure, that happens too. It’s about the scoring system itself quietly losing all signal value, one inflated CVSS number at a time.

How you get here

CVSS was built to be objective: attack vector, complexity, privileges required, user interaction, scope, the whole vector string. In practice, the incentive on every side points toward a higher number:

• Researchers get more attention for a 9.8 than a 5.4, and attention is currency now.
• Vendors would rather announce “we patched a critical vuln fast” than “we found a moderate issue eventually,” and the first sounds responsible while the second sounds like you shipped garbage.
• Compliance tooling treats the number as gospel and auto-generates tickets off it, so a high score creates organizational motion regardless of actual exploitability.

Every one of those incentives is individually reasonable. Stacked together they produce a scoring system where “critical” has been diluted into “notable.”

What I actually do with a CVE now

I stopped reading the headline score somewhere around 2019 and started reading the vector string first, every time, no exceptions. AV:N/AC:L/PR:N/UI:N gets my attention immediately: unauthenticated, network-reachable, no user interaction required, that’s a real fire. AV:L/AC:H/PR:H with a 9-point score gets filed and read later, because whatever produced that number, it isn’t urgency.

The other thing I do, and this is the part that’ll actually save you time: check whether the vulnerable code path is even reachable in your deployment. A critical RCE in a library feature you don’t use, behind a config flag you don’t set, compiled out of the binary you actually ship, is not your incident. It’s a line item for the next dependency bump, not a 2am page.

Score inflation isn’t going to fix itself. Nobody benefits from fixing it. So the job falls to whoever’s triaging the alert, same as it always has: read past the number, model the actual attack path, and reserve your panic for the CVEs that have earned it.

The tooling that actually helps triage

The CVE ecosystem has quietly grown a set of supplemental scoring schemes to patch the holes CVSS leaves. EPSS (Exploit Prediction Scoring System) is the useful one: it combines CVE metadata with observed exploit activity and historical data to produce a probability that a given vulnerability will be actively exploited in the next 30 days. A 9.8 CVSS with a 0.3% EPSS is different from a 9.8 with a 42% EPSS. The number you were given tells you severity in theory. EPSS tells you what’s actually burning in the wild right now.

CISA’s Known Exploited Vulnerabilities catalog is the bluntest instrument and often the most useful one for exactly that reason: it is a flat list of CVEs with confirmed in-the-wild exploitation, ordered by the federal deadline for patching. If something lands there, it earned the urgency. Anything on that list with AV:N/PR:N in the vector string is a real fire.

Neither replaces reading the vector string yourself. But if you’re trying to explain to a manager why the 9.8 you just closed matters less than the 7.2 you just opened a P0 for, EPSS gives you a number to point at. Managers respond well to numbers.

For the operational side: the bpftrace IO latency tip covers using live tracing to confirm whether a vulnerable code path is actually running. If you can show the path is cold in production, that’s the fastest way to downgrade an incident to a scheduled patch.