I Am Not a Fan of CVEs

9 May 2025

To be clear, I do understand and like the idea behind CVEs. A centralized, platform-agnostic system for disclosing security vulnerabilities is exactly what the software world needs. It gives us a consistent format, a common language, and a shared repository for tracking security issues across the ecosystem.

But in practice, CVEs are increasingly doing more harm than good.

Take the case of the node-IP [1] project, a lightweight IP address utility for Node.js. When a CVE (CVE-2023-42282) was filed because the ip.isPublic() and ip.isPrivate() functions did not correctly classify some obscure, non-standard representation of IP addresses. The implication was that a bad actor could trick a system into thinking a public IP address was actually private and thus bypass protections to private spaces.

But that raises a critical question: Does anyone use an IP address utility library as an access control mechanism?

The bug was promptly fixed but the fallout was overblown. The CVE was given a score of 9.8 out of 10. To put that into context, a Windows Remote Code Execution exploit was given a 8.8 [2]. Suggesting that mislabeling IP addresses is much worse than an RCE.

And because tools like npm audit rely on CVE scores, the result was that any project depending (directly or indirectly) on node-ip (which is a lot, node-ip has over 11 million downloads a week on npm [3]) suddenly had alarming security warnings. As expected, users panicked. The main developer was inundated with questions, criticisms and pressure, despite the fix already being available.

Efforts by the main developer to lower or remove the CVE score was met with a brick wall. The CNA (CVE Numbering Authority) that issued the CVE did not respond to requests. Github, who aggregates CVEs, eventually downgraded their internal severity rating [4], but the official CVE still shows a 9.8 [5].

A similar situation occurred with cURL. The cURL team, who are famously proactive about security vulnerabilities, even going as far as issuing their own CVEs and maintains a list of all CVEs associated with cURL [6], were blindsided by an externally filed CVE [7] about an integer overflow in cURL triggered by using a time delay parameter. This was in 2023.

The problem? The integer overflow bug was fixed in 2019 [8].

So why did it get a fresh CVE, and why was it rated a 9.8 (an integer overflow is worse than an RCE) for a bug that was already fixed? The CVE entry even linked directly to the years-old fix. The cURL team tried to get the CVE removed. Denied. They tried to get the score reduced. Denied again. Until enough community pressure finally brought it down to a 5.9.

Following this, cURL applied for and became a CNA [9], giving them control over how CVEs for their project are issued and managed. Others, like the Python Software foundation [10], have done the same.

Then there’s ReDoS (Regular Expression Denial of Service), the poster child for theoretical attacks with little real-world impact. The idea is that certain regex engines can be tricked into catastrophic performance on carefully crafted input, causing a denial of service.

Technically sound. But practically irrelevant.

ReDoS attacks almost never happen in the wild. It’s far easier to perform a traditional DoS attack than to reverse-engineer the perfect regex payload. Plus, most production systems already mitigate this with timeouts or input limits. And also, why are you not sanitizing user input?

Yet CVEs for ReDoS keep appearing. Mostly flagged by automated scanners, not security researchers. Scores get assigned, tools go haywire, and developers are left defending against imaginary threats. One recent example involved the micromatch library. When the developer demanded the CVE reporter give a real-world exploit example [11], the reporter gave up and defaulted to a vague hypothetical.

ReDoS CVEs aren’t helping anyone. They illustrate the deeper issue: the system favors checklists and scanners over context and judgment.

What’s going wrong here is not the concept of CVEs, but the execution and incentives. The current system:

Encourages quantity over quality. Anyone can file a CVE, and it’s not always vetted. Even by the organizations hosting them. [12]
Relies on arbitrary scoring, often with minimal context or real-world impact assessment.
Feeds into automated tools like npm audit, which treat every CVE as equally urgent, amplifying panic.
Provides no clear way for maintainers to challenge or revise CVEs, leaving them stuck with inflated or outdated scores.

The result is that developers get burned. Users get misled. And the ecosystem becomes less secure as the signal gets buried under noise.

More and more projects are pushing back. SQLite has publicly stated that they no longer trust CVEs and evaluate every disclosure manually [13]. Greg Kroah-Hartman, a Linux kernel maintainer, has said that the Linux project no longer considers Linux CVEs relevant [14]. And alternatives to CVSS (the standard CVE scoring system) are gaining traction, like EPSS, which scores vulnerabilities based on exploit probability.

I am not a fan of CVEs.

Fun fact: Bad documentation will get you a CVE score of 7.5 [15].

[1] https://github.com/indutny/node-ip

[2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30078

[3] https://www.npmjs.com/package/ip

[4] https://github.com/advisories/GHSA-78xj-cgh5-2h22

[5] https://nvd.nist.gov/vuln/detail/CVE-2023-42282

[6] https://curl.se/docs/security.html

[7] https://curl.se/docs/CVE-2020-19909.html

[8] https://github.com/curl/curl/pull/4166

[9] https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/

[10] https://pyfound.blogspot.com/2023/08/psf-authorized-as-cna.html