The CVEs That Keep Coming Back: Lessons from the Most Exploited Vulnerabilities

Every year, security agencies publish lists of the most exploited vulnerabilities. And every year, the lists look remarkably similar. The specific CVE numbers change, but the underlying patterns repeat. Remote code execution through deserialization flaws. Authentication bypasses in enterprise appliances. Server-side request forgery in cloud metadata services. SQL injection in legacy applications.

If attackers keep exploiting the same types of flaws, why do organizations keep falling for them? The answer says less about attacker sophistication and more about defender blind spots. Understanding those blind spots is the first step toward closing them.

Which Vulnerability Classes Keep Getting Exploited?

CISA's Known Exploited Vulnerabilities catalog is the most authoritative list of CVEs actively used in attacks. Analyzing the entries reveals clear patterns:

Authentication and Access Control Failures

CVEs in VPN appliances, firewalls, and remote access gateways consistently top the list. Products from major vendors have had critical authentication bypass vulnerabilities that allow attackers to walk straight through the perimeter. These are especially dangerous because these devices sit at the network edge and are designed to be internet-facing.

Examples include bypasses where attackers craft requests that skip authentication entirely, or exploit default credentials that were never changed. Once past the gateway, the attacker has the same access as a legitimate user. The irony is hard to miss: the products organizations buy to secure remote access are frequently the products that let attackers in.

Remote Code Execution via Deserialization

Deserialization vulnerabilities allow attackers to execute arbitrary code by sending specially crafted data to an application that deserializes untrusted input. Log4Shell (CVE-2021-44228) was the most famous example, but the pattern extends far beyond Java. Any language or framework that deserializes user-controlled data without strict validation is at risk.

These CVEs are particularly dangerous because they often require no authentication. An attacker sends a single crafted request and achieves full remote code execution on the server. Worse, the vulnerable component is often buried deep inside applications, arriving through your software supply chain rather than through anything your team wrote, which makes affected systems hard to identify without deep technology fingerprinting.

SQL Injection in Legacy Systems

Modern web frameworks provide parameterized queries and ORM layers that prevent SQL injection by default. But legacy applications, custom-built tools, and poorly maintained systems still construct SQL queries through string concatenation. Attackers know this and actively scan for injection points in older applications.

SQL injection CVEs appear in commercial products you would expect to know better: content management systems, e-commerce platforms, and enterprise applications that have been in production for years.

Server-Side Request Forgery

SSRF vulnerabilities allow attackers to make the server send requests on their behalf. In cloud environments, this often means accessing the instance metadata service to steal credentials. The Capital One breach was enabled by an SSRF vulnerability that allowed the attacker to retrieve AWS IAM credentials from the metadata endpoint.

As more applications move to cloud infrastructure, SSRF has become one of the most impactful vulnerability classes.

Why Does Patching Keep Failing?

If patches exist for known CVEs, why do organizations remain vulnerable? The reasons are consistent and predictable:

• Visibility gaps: You cannot patch what you do not know you run. Organizations without complete asset inventories and technology fingerprinting miss affected systems entirely.
• Patch lag: Even when vulnerabilities are identified, patching takes time. Testing, change management, and maintenance windows create delays. Attackers exploit the gap.
• Legacy constraints: Some systems cannot be patched without breaking dependent applications. Others run software that the vendor no longer supports.
• Volume fatigue: Thousands of CVEs are published annually. Without clear prioritization, security teams cannot determine which patches are urgent and which can wait.

Each failure mode has a matching countermeasure, and the organizations that stay off the breach reports are the ones that treat those countermeasures as standing processes rather than annual projects:

How Do You Break the Cycle?

The organizations that handle CVE management effectively share common practices:

Complete technology inventory: You need to know every piece of software running in your environment, down to the exact version. OnScanner's technology fingerprinting identifies products, vendors, and versions across your infrastructure and maps them to CPEs, so when a new CVE drops, you instantly know if you are affected.

Continuous CVE monitoring: Annual vulnerability assessments are not sufficient, and cached scan results describe yesterday's exposure rather than today's. New CVEs are published daily, and the window between publication and active exploitation is shrinking. Continuous scanning that maps your technology stack to current CVE databases is essential.

Risk-based prioritization: Not all CVEs are equal. A critical RCE in an internet-facing application demands immediate action. A low-severity information disclosure in an internal tool can wait. Prioritize by actual risk: severity, exploitability, exposure, and business impact. Signals like EPSS scores and KEV catalog membership tell you which vulnerabilities attackers are actually using, which is a far better ranking signal than severity scores in isolation.

Compensating controls: When immediate patching is not possible, implement compensating controls. Network segmentation, WAF rules, and access restrictions can reduce risk while you plan the patch deployment. Compensating controls are a bridge, not a destination: document them, revisit them, and retire them once the underlying patch lands.

The Pattern Is the Lesson

The most exploited CVEs are not exotic zero-days. They are known vulnerabilities with available patches in systems that organizations failed to inventory, monitor, or update. The tools and processes to prevent these exploitations exist. The question is whether your organization has implemented them.

Start by knowing what you run. Then know what is vulnerable. Then fix it before someone else finds it first.

Frequently asked questions

Why do the same vulnerability classes get exploited year after year?

Because the conditions that make them exploitable persist. Edge appliances remain internet-facing by design, legacy applications keep concatenating SQL strings, and deserialization flaws hide inside dependencies most teams never audit. Attackers reuse what works, and until organizations fix the underlying process failures of inventory, monitoring, and prioritization, the same classes of known CVEs will keep delivering results.

How should you prioritize which CVEs to patch first?

Rank by real-world risk rather than severity score alone. A CVE that appears in CISA's Known Exploited Vulnerabilities catalog, has a working public exploit, and affects an internet-facing system should jump the queue over a higher-scored flaw in an isolated internal tool. Combine severity, exploitability, exposure, and business impact into one prioritization decision.

What should you do when a system cannot be patched?

Apply compensating controls that reduce exposure while you plan a permanent fix. Network segmentation limits what an attacker can reach, WAF rules can block known exploit patterns, and access restrictions shrink the population that can touch the vulnerable service. Treat these as temporary measures, and put unsupported legacy systems on a documented decommissioning path.