Six Reasons Why Low-Severity CVEs Become High Risk

Every security and engineering team carries a backlog of vulnerabilities it has consciously chosen not to fix. Just a few years ago, deprioritizing them was defensible risk management. Today, the same decisions are quietly accumulating into structural exposure.

The reason is that vulnerability severity is not static in practice. A CVE that was once difficult to exploit, unlikely to be targeted, or buried among thousands of other findings can become materially more dangerous as attackers gain better tooling, more information becomes available, and vulnerable software stays deployed. The underlying flaw is unchanged, but its likelihood of exploitation, its exposure, its value inside an attack chain, and its business impact have all moved since the original triage decision.

This post lays out six interconnected reasons the calculus has shifted and a practical model for reassessing the backlog.

‍

1. Exploitation Is Faster, Cheaper, and Automated

Historically, a medium-severity CVE in a niche library might never see a working exploit because writing one was not worth an attacker's time. That economic barrier is eroding. Attackers can now scan large address ranges, fingerprint vulnerable products, pull public proof-of-concept code, and adapt exploits at scale. Automated exploit generation and AI-assisted research have compressed the gap between disclosure and exploitation from months to days.

A CVSS 5.1 issue with a public PoC and a scriptable attack path is often more dangerous in practice than a CVSS 8.0 issue that requires deep, target-specific expertise.

‍

2. AI Is Widening the Gap Between Discovery and Remediation

The same shift is happening on the discovery side. AI-assisted security research can analyze enormous volumes of source code, dependencies, and binaries far faster than human researchers. The uncomfortable arithmetic: the number of vulnerabilities being discovered is increasing, but the capacity to remediate them is not increasing at the same rate. 

Traditional approaches such as "fix critical and high, then work down the list" become less effective when the list grows faster than the team can burn it down. For many medium- and low-priority findings, a patch exists, but organizations lack the bandwidth to apply and test it, so the findings accumulate as security debt.

Meanwhile, the same technologies that help defenders find flaws help attackers identify promising targets, understand unfamiliar code, develop exploits, and automate reconnaissance. A vulnerability that previously drew no attention may now be economically attractive to exploit, precisely because AI has lowered the cost of figuring out which "uninteresting" findings are worth the effort.

‍

3. Chained Exploitation Turns Low Findings Into Critical Paths

Modern intrusions rarely hinge on a single critical flaw. Attackers commonly combine several weaknesses: a low-severity information disclosure reveals usernames or tokens, a path traversal or SSRF flaw reaches an internal service, an authentication or authorization weakness enables privileged access, and a misconfiguration or second vulnerability produces code execution or data theft.

Each link might individually score low or medium severity. CVSS describes the technical characteristics of an individual vulnerability; it does not fully represent the combined impact of attack paths across applications, identities, cloud resources, and dependent systems. The Forum for Incident Response and Security Teams (FIRST) definition explicitly distinguishes the vulnerable system from subsequent systems that can be affected through it. The result: a "low" vulnerability sitting near a trust boundary can be more dangerous than a "high" vulnerability on an isolated, low-value host.

‍

4. Threat Intelligence Can Change the Priority Overnight, Even Decades Later

A vulnerability's original rating reflects its characteristics at disclosure time. Its real priority can jump when it is added to CISA's Known Exploited Vulnerabilities (KEV) catalog, when a reliable exploit or weaponized module is published, when threat actors begin targeting the affected product, when exploitation shows up in incident-response or honeypot telemetry, or when the vendor recommends emergency mitigation.

Age offers no protection. Attackers do not need new vulnerabilities; they revisit old ones when they discover large populations of vulnerable systems or develop more reliable exploitation techniques. In May 2026, CISA added vulnerabilities dating back to 2008, 2009, and 2010 to the KEV catalog based on evidence of active exploitation, including CVE-2008-4250 in Microsoft Windows and CVE-2010-0249 in Internet Explorer. A flaw disclosed nearly two decades ago can become an urgent remediation mandate overnight.

KEV and the Exploit Prediction Scoring System (EPSS) are complementary signals: KEV records confirmed exploitation in the wild, while EPSS estimates the probability of exploitation in the next 30 days. A vulnerability with a modest CVSS score but confirmed exploitation should normally outrank a critical-scoring vulnerability that is unreachable, absent from the environment, and unsupported by exploit intelligence. Exploitability in the wild, not theoretical severity, determines real risk. "Medium severity" does not mean "medium risk forever."

‍

5. Regulatory and Contractual Scrutiny Has Raised the Floor

Frameworks like PCI DSS 4.x, DORA, NIS2, and the EU Cyber Resilience Act increasingly require organizations to remediate or formally justify all known vulnerabilities, not just criticals. Cyber insurers and enterprise procurement teams ask the same questions during renewals and vendor reviews.

For a patchable finding, these frameworks accept "patch applied" as closure; for an EOL component, no patch will ever exist, so the organization inherits the vendor's obligation; it must demonstrate its own remediation path, compensating controls, or documented risk acceptance for a finding that upstream will never resolve.

A backlog of unremediated low-severity findings in EOL components is now a compliance finding, a deal blocker, and a breach-litigation liability, independent of whether it is ever exploited. The exposure exists on paper before it exists in an attacker's toolkit.

‍

6. End-of-Life (EOL) Software Converts Every Vulnerability Into a Permanent One

This is the forever-day problem, and it is where the entire risk model breaks. For organizations carrying large open source estates, it is arguably the most important change of all.

With supported software, the vulnerability lifecycle is predictable: discover, disclose, fix, release, upgrade. With an EOL version, that lifecycle breaks. The vulnerability may be publicly disclosed, the affected code may be well understood, and a fix may even exist upstream for a newer version, but there is no patch for the version the organization is actually running. An EOL vulnerability is not simply "unpatched today." It can be permanently unpatched upstream.

The scale is documented. Research HeroDevs contributed to the 2026 Sonatype State of the Software Supply Chain Report found more than 81,000 open source package versions with known CVEs that are both EOL and unpatchable, with 5 to 15 percent of the dependencies in the enterprise graphs analyzed already past end of life. HeroDevs estimates the true number across all registries is closer to 400,000; the full analysis is in 81,000 Open Source Package Versions Have Known CVEs and No Patch. This creates a distinctly dangerous category of vulnerability: known, potentially exploitable, and without an upstream remediation path.

The pattern is visible framework by framework. Since AngularJS reached EOL in December 2021, multiple vulnerabilities of all severity levels, including CVE-2022-25844, CVE-2024-8372, and CVE-2024-8373 have been disclosed with no official patch, as documented in our Angular version history and EOL reference. Node.js follows the same rhythm on a faster clock; the full timeline is in our Node.js EOL reference.

Scanners keep flagging the finding. Attackers keep probing it, knowing the window never closes. The standard remediation workflow produces a ticket that can never be closed, and the organization's only options are migration, compensating controls, or third-party patching. Risk that was accepted as transient becomes structural. The white paper Mitigating Open Source Software Risks with HeroDevs Never-Ending Support examines this transition in depth.

‍

A Practical Risk Model

Do not promote every low-severity finding automatically. Instead, reassess each one against six questions:

1. Presence: Is the vulnerable component actually installed, loaded, and active?
2. Reachability: Can an untrusted actor reach the vulnerable function?
3. Exploitability: Is there active exploitation, public exploit code, KEV membership, or a high EPSS signal?
4. Chaining: Can the flaw expose credentials, cross a trust boundary, or reach another vulnerable system?
5. Consequence: What data, identity, service, or business process becomes accessible?
6. Support status: Will an official patch ever exist, or is this component past the EOL?

CVSS describes technical severity, but it should be supplemented with exposure, asset criticality, attack-path data, KEV status, EPSS, exploit maturity, compensating controls, and support status. 

In a supported component, exploitability is a window that closes when the patch ships. In an unsupported or EOL component, the window never closes, so any "yes" on reachability, chaining, or consequence compounds indefinitely. And as AI-scale discovery surfaces more vulnerabilities in unmaintained code that no maintainer will ever patch, the EOL portion of the backlog grows in exactly the category that remediation workflows cannot resolve.

‍

Taking Action

For components that have already crossed the EOL line, that question has a permanent answer, and teams have three real options: upgrade to a supported version, migrate off the technology, or adopt commercial extended support. Where upgrade timelines are measured in quarters, and the vulnerability window is measured in days, HeroDevs Never-Ending Support closes the gap with drop-in replacements that receive ongoing security patches for frameworks and runtimes the community no longer maintains. Including fixes for all low- and medium-severity CVEs.

If your risk register includes findings in EOL components, that portion of the backlog deserves a different conversation than the rest. Contact HeroDevs to review which of your EOL dependencies carry the highest exposure, or start with the Quantifying the Real Risks of Unsupported Open Source Software guide.