The Vulnerability Came Back: Why Old CVEs Still Demand Attention - Atomicorp - Own Your Security. Protect Your Data.

The Vulnerability Came Back: Why Old CVEs Still Demand Attention

Old vulnerabilities do not necessarily disappear from attackers’ playbooks. Instead, older CVEs can remain actively exploited years after their initial disclosure, particularly when vulnerable legacy and end-of-life (EOL) systems remain in operation. As artificial intelligence (AI) and automation accelerate vulnerability exploitation, organizations need to identify and protect weaknesses regardless of their age. Atomicorp helps organizations protect current, legacy, and unsupported systems with vulnerability detection, virtual patching, continuous monitoring, EDR, and other layered security controls.

Visit our Legacy System Security page.

Contact Us.

 

New CVEs Get the Headlines, Old CVEs Still Get Exploited

Newly discovered vulnerabilities and zero-days naturally command attention. But attackers have little reason to abandon an older vulnerability if it still works.

The 2026 Verizon Data Breach Investigations Report (DBIR) illustrates the problem. Verizon examined what it calls “resurgent vulnerabilities,” i.e., older vulnerabilities that can suddenly experience renewed exploitation.

Of the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog entries Verizon identified as persistently exploited, only 20 percent were registered as CVEs in 2024 or 2025. The remaining 80 percent were older vulnerabilities. Verizon also found that nearly half of KEVs fell into its persistent exploitation category.

That matters because vulnerability exploitation itself is becoming more important. According to the 2026 DBIR, exploitation of vulnerabilities accounted for 31 percent of breaches, surpassing stolen credentials as the leading initial access vector for the first time in the report’s history.

The lesson is straightforward: An old CVE is not necessarily an obsolete CVE.

 

Why Do Old Vulnerabilities Come Back?

Vulnerabilities do not expire simply because years have passed since their discovery. Vulnerable systems can remain in production, while exploit techniques and information about known weaknesses may become increasingly accessible.

Automated scanning also enables attackers to search large numbers of Internet-connected systems for known weaknesses. An attacker does not necessarily need a sophisticated zero-day if a five-year-old vulnerability provides the access they need.

This can become especially problematic with legacy and EOL technology. Organizations may depend on older operating systems, applications and equipment because of specialized applications, hardware dependencies, production requirements, or the cost and disruption of replacement. Vendor patches may no longer be available, and many security products eventually stop supporting older platforms.

The result can be a persistent security gap: the system remains important to the organization, the vulnerability remains useful to attackers, but conventional security remediation options are disappearing.

 

CISA KEV: Evidence That Older CVEs Still Matter

CISA’s KEV Catalog provides another useful perspective. It is not solely a list of vulnerabilities that could theoretically be exploited. CISA describes KEV as an authoritative source of vulnerabilities that have been exploited in the wild and recommends organizations use the catalog when prioritizing vulnerability management.

Recent KEV additions have repeatedly demonstrated that the date on a CVE does not determine whether attackers are finished with it. For example:

  • CVE-2014-3120 (Elasticsearch): Elasticsearch before 1.2 allowed remote attackers to exploit dynamic scripting to execute MVEL expressions or Java code.
  • CVE-2020-20982 (shadoweb wdja): An XSS flaw in wdja 1.5.1 lets remote attackers exploit the backurl parameter to execute code and potentially gain privileges.
  • CVE-2024-58348 (WordPress Background Image Cropper): Background Image Cropper 1.2 allows unauthenticated file uploads that can lead to remote execution of malicious PHP code.

These examples are important not because they are the oldest vulnerabilities in the catalog, but because CISA added years-old CVEs after receiving evidence that attackers were still exploiting them.

 

Stay Current With CVE Research Notes

Keep track of many CVEs, KEVs, and emerging threats with Atomicorp CVE Research Notes, featuring selected testing results, engineering observations, attack-pattern analysis, and WAF rule interactions. 

Visit the Research Notes page for practical findings that can help you better understand individual vulnerabilities and how they interact with web application defenses.

 

An Old CVE Can Start a New Attack

Exploiting a vulnerability is often only the beginning. Once attackers establish an initial foothold, they may attempt to steal credentials, gain higher privileges, establish persistence, move laterally to other systems, access sensitive information, deploy malware or ransomware, or exfiltrate data.

This is why vulnerability management cannot be viewed merely as a race to address the newest CVEs. Organizations also need visibility into older weaknesses that remain exposed across their environments, particularly on systems that cannot easily be upgraded or patched.

AI adds urgency to the problem. Threat actors are using AI across multiple attack techniques, while automation can help attackers work faster in identifying weaknesses and exploiting vulnerable systems. Read the article.

In that environment, yesterday’s vulnerability can still provide tomorrow’s way in.

 

Can’t Patch It? Add Layers of Protection

The first choice for a vulnerable system should generally be to apply an available security update or otherwise remediate the vulnerability. But that isn’t always possible with legacy and unsupported systems.

When conventional patching is unavailable, impractical or would disrupt a critical system, organizations should identify the exposure and apply appropriate compensating security controls.

These can include CVE and KEV vulnerability detection, virtual patching, system hardening, network segmentation, endpoint firewalling, and application allowlisting. Other layers can include antivirus and antimalware, intrusion detection and prevention, file integrity monitoring (FIM), continuous monitoring, data loss prevention, and automated response.

The objective is defense in depth. If one weakness cannot immediately be eliminated, additional controls can make the vulnerability harder to exploit, detect suspicious activity sooner, restrict what an attacker can reach, and help contain an intrusion before it becomes a larger breach.

 

Legacy Doesn’t Have to Mean Unprotected

As an Atomicorp customer, you don’t have to let a legacy or EOL operating system go unmonitored simply because its original vendor or other security providers no longer support it.

The Atomic OSSEC EDR provides vulnerability detection and management across current, legacy, and EOL environments. Additional capabilities include antivirus and antimalware, intrusion detection and prevention, endpoint firewalling, application control, FIM, continuous monitoring, active response, audit controls, and reporting.

For vulnerabilities that cannot be resolved through conventional patching, virtual patching can provide another layer of protection. Atomicorp’s Atomic WAF and Atomic ModSecurity Rules enable virtual patching at the web application layer, blocking exploit attempts before they reach vulnerable applications and helping protect legacy or unsupported software without modifying the underlying application.

Old vulnerabilities can come back. The important question is whether your defenses are still there when they do.

Visit the Atomic OSSEC EDR page.

Request a Demo