In the age of digitization, there's an imperative for companies, developers, and users to prioritize security. The Common Vulnerabilities and Exposures (CVE) system, and its associated CVSS scores, have played a pivotal role in helping the industry identify, categorize, and react to security issues. However, when every potential flaw is rated with a sky-high CVSS score, or when bugs are reported as CVEs even when they lack genuine exploitability, we find ourselves grappling with an alarming dilution of trust. In such a scenario, a pertinent question arises: If everything is considered a critical security flaw, how do we discern what truly demands our immediate attention?

Two recent examples serve as eye-opening case studies. First, the PostgreSQL's response to CVE-2020-21469, wherein the CVE claims a possible DoS in PostgreSQL 12.2. However, the PostgreSQL Security Team refuted this, noting that one would need elevated privileges to exploit the said flaw, hence effectively rendering it a non-issue from a security perspective. As Dan Lorenc pointed out, this same Denial of Service capability could be applied to, say…the shutdown command if an administrator were to turn off the database server.

Similarly, the curl project received an unwarranted alarm with CVE-2020-19909. What was once identified as a "plain bug" back in 2019 was resurrected in 2023 as a potential integer overflow vulnerability, causing unnecessary chaos and resource diversion for the curl team. To make matters worse, when the curl team explained this to MITRE, they initially still refused to remove or update the CVE – though it now does show as “disputed” on the NVD. This led to Daniel Stenberg of the curl project to state that this CVE was “everything that is wrong with CVEs.”

These incidents spotlight two significant challenges facing the cybersecurity landscape:

Firstly, there's an increasing trend where bugs, not inherently security vulnerabilities, are being reported as CVEs. In fact, some even theorize that there may be automated processes at work wherein folks are reporting as a CVE any commit message that mentions security related terminology. This mislabeling can muddy the waters, making it harder for teams to discern genuine threats from routine bugs.

Secondly, the issue of overstated CVSS scores compounds the problem. In the chaos created by these inflated ratings, real and critical security issues might get lost. This can lead to the misapplication of resources, false alarms, and potentially devastating oversights.

With the apparent dilution of trust in the traditional CVE-CVSS system, there has been a steady rise in use of the term "exploitable vulnerabilities." This is reflective of the industry's evolving priority – not every vulnerability will be exploited, and it's the genuinely exploitable ones that we need to be wary of.

Enter the Exploit Prediction Scoring System (EPSS) – a system focusing on exploitability and the probability of exploitation. EPSS serves as an important counterbalance, forcing us to assess not just the vulnerability but also the feasibility of it being exploited in real-world scenarios.

At ProjectDiscovery we take this a step further, focusing our teams on exploitable vulnerabilities entirely. By looking from the “outside in” – our open source tools like nuclei provide a unique perspective on the attack surface that an entity may have exposed to the outside world. And our community-driven templates ensure that scanning with nuclei is focused on what’s actually exploitable over what a compliance check may require. In addition, this year we added CPE and EPSS data as well as EPSS probability to all of our CVE related nuclei templates, to provide more information about the vulnerabilities they look for than just a simple CVSS score.

While it's commendable to err on the side of caution, the danger of crying wolf too many times is that genuine threats may be overlooked or underestimated. Projects like PostgreSQL and curl are not anomalies; many other projects grapple with similar concerns. This begs the need for a more discerning, balanced approach to vulnerability assessment.

• First, we need greater scrutiny at the CVE filing stage, and all the CVE Numbering Authorities (CNAs), ensuring that what gets tagged as a security vulnerability has genuine merit.
• Second, augmenting CVSS scores with EPSS can provide a more holistic view, enabling organizations to prioritize issues that have a high probability of being exploited.
• Third, it's essential to foster open lines of communication. Before a CVE is made public, entities like MITRE and/or the respective CNS should work more closely with project maintainers to verify and validate the concerns.

Security is paramount, but in our quest for a secure digital ecosystem, we must ensure that our metrics and systems remain trustworthy. Overstated CVSS scores and mislabeled CVEs risk creating an environment of confusion and mistrust. By refining our approach and embracing new metrics like EPSS, we can chart a path to a more accurate, actionable, and reliable security landscape.

To learn more about exploitable vulnerabilities – join our Discord!