5 real CVE examples, and how to prevent them

The number of CVE records published each year continues to rise, with supply chain attacks and dependency-based exploits now accounting for an increasing share of serious cybersecurity vulnerabilities. In 2024, over 40,000 CVE records were published, a 38% jump from the previous year. For security teams, this ramp up creates an exhausting reality: constant notifications, reactive patching cycles, and the feeling that you're always one step behind.

But each CVE tells a story about how software gets built and where trust breaks down. Understanding these patterns helps you build software that avoids these risks from the outset.

What is a CVE?

You'll hear "CVE" used casually to mean any security vulnerability, but it has a specific meaning. A CVE (Common Vulnerabilities and Exposures) is a standardized identifier for a publicly known security flaw. The CVE program is a U.S. government-sponsored initiative managed by the MITRE Corporation and sponsored by the Cybersecurity and Infrastructure Security Agency (CISA). Once a vulnerability gets a CVE ID, it is cataloged in the National Vulnerability Database (NVD), which is maintained by NIST.

The CVE system gives security professionals a common language for tracking vulnerabilities. When someone mentions a CVE ID, such as "CVE-2021-44228," everyone knows exactly which issue is being discussed, as they can all look up the cause and associated information regarding the vulnerability in the NVD.

CVE Numbering Authorities (CNAs) are organizations authorized to assign CVE identifiers. Major tech companies, such as Microsoft, Red Hat, and GitHub, serve as CNAs. Occasionally, research organizations like US-CERT also do so. Some of these companies even offer bug bounty programs that collaborate with CNAs to ensure that discovered flaws are documented in the CVE database.

Each CVE entry typically includes a severity rating based on the Common Vulnerability Scoring System (CVSS). CVSS scores quantify risk based on factors like how easily the flaw can be exploited, how much damage it can cause, and whether an attacker needs existing credentials to pull it off. Many entries also reference Common Weakness Enumeration (CWE) categories, which classify the type of coding or design mistake involved, such as buffer overflow, SQL injection, or cross-site scripting.

However, just the CVE ID does not provide sufficient context for your engineers. A critical CVE in a component you don't use might pose zero real-world risks. Meanwhile, a "medium" severity issue in an endpoint you’ve exposed publicly could enable a malicious actor to gain unauthorized access to your users’ data in practice. Thus, understanding what CVEs actually mean for your situation matters more than chasing CVSS scores.

The consequences of CVEs

When a security researcher or vendor discloses a critical CVE, security teams scramble to assess exposure. Developers at affected organizations get pulled off their roadmaps to patch vulnerable components in their own software. And if the vulnerability enables something scary (like ransomware distribution or data theft) suddenly the C-suite wants to know how bad it is and when it'll be fixed.

According to Chainguard's research on the hidden costs of CVEs, organizations running containerized software environments spend an average of $2.1 million annually on CVE remediation. The 2026 Engineering Reality Report found that 79% of engineers say maintenance work limits innovation. That kind of drag on your team only compounds over time.

Then there's compliance. Frameworks like FedRAMP, SOC 2, and NIST require organizations to demonstrate effective risk management strategies for addressing CVEs. Every unpatched CVE becomes a potential audit finding. Clean scans and rapid remediation aren't optional in regulated industries.

CVE examples: Learning from real-world vulnerabilities

Every major CVE reveals something about how modern software fails. Here are five that shaped how the industry thinks about security.

Log4Shell (CVE-2021-44228)

Log4Shell was a remote code execution vulnerability in Apache Log4j, a ubiquitous Java logging library. Attackers could execute arbitrary code simply by getting a vulnerable system to log a specially crafted string. CVSS score: 10 out of 10.

Log4j was buried deep in dependency trees across millions of applications, often five or six layers down from the code developers actually wrote. Many organizations didn't realize they were using it until security advisories circulated, forcing them to scramble through their software bills of materials (SBOMs) to assess their exposure.

The lesson: You can't secure what you can't see. Organizations with robust SBOMs assessed their exposure in hours. Everyone else spent weeks in triage. This CVE vulnerability highlighted why “default-on behavior” (such as Log4j's JNDI lookup) can become a significant liability.

NVD entry: CVE-2021-44228

Heartbleed (CVE-2014-0160)

Heartbleed was a buffer overflow vulnerability in OpenSSL allowing attackers to harvest up to 64KB of server memory per request, potentially exposing sensitive data, such as private keys and passwords.

OpenSSL secured a huge portion of internet traffic, yet it was maintained by a small team with limited funding. The vulnerability existed undetected for over two years. This CVE record served as a wake-up call about how critical open-source infrastructure is often treated.

The lesson: You can't audit your way out of this. Even widely trusted, heavily used libraries can hide critical flaws for years. The safer bet is reducing your dependency on complex cryptographic libraries you don't control, and choosing dependencies that are minimal, well-funded, and transparent about how they're built.

NVD entry: CVE-2014-0160

Dirty Pipe (CVE-2022-0847)

Dirty Pipe was a Linux kernel vulnerability that allowed unprivileged users to overwrite data in read-only files. In practice, this meant a low-level user could grant themselves root access and take over an entire system.

Kernel vulnerabilities are especially dangerous because they affect the foundation on which everything runs. Container escapes and complete system takeovers become possible when the kernel is compromised. The codebase complexity of long-lived projects, such as the Linux kernel, makes these security flaws difficult to detect.

The lesson: Defense in depth matters. You can't secure containers without securing what they run on. A perfectly hardened container image won't save you if the host kernel is vulnerable. Security has to happen at every layer.

NVD entry: CVE-2022-0847

Spring4Shell (CVE-2022-22965)

Spring4Shell was a remote code execution vulnerability in the Spring Framework. Under specific conditions (JDK 9+ and deployed as a WAR to Tomcat), attackers can manipulate class loader attributes to execute arbitrary code.

The vulnerability exploited interactions between Spring's data binding, Java's class loading, and Tomcat's deployment model. No single component was broken, but their combination created an exploitable path. This pattern is increasingly common: vulnerabilities emerging from the seams between systems.

The lesson: Framework complexity creates hidden attack surfaces. Simpler architectures with fewer dependencies have fewer unexpected interactions.

NVD entry: CVE-2022-22965

XZ Utils Backdoor (CVE-2024-3094)

In early 2024, a sophisticated backdoor was discovered in XZ Utils, a compression library included in most Linux distributions. A maintainer who had gradually gained trust over several years inserted malicious code that would have allowed unauthorized access to affected systems. A Microsoft engineer caught it during routine performance testing.

The code wasn't in the source repository; it was injected during the build process, invisible to code review. This means traditional security practices like auditing source code wouldn't have caught it.

The lesson: Verifiable builds matter. With reproducible builds, anyone can rebuild from source and compare the output to the distributed binary. If they don't match, something's wrong. SLSA compliance and cryptographic attestations create a verifiable record of what went into a build and how it was produced, making attacks like this much harder to hide.

NVD entry: CVE-2024-3094

How to identify and prevent CVEs

There’s a pattern to these CVE examples: Organizations that weather CVE storms best aren't necessarily those with the biggest security teams. They're the ones who've invested in foundations that make vulnerabilities easier to find, assess, and fix.

Maintain comprehensive SBOMs. A Software Bill of Materials inventories everything in your software: direct dependencies, transitive dependencies, and versions. When Log4Shell hit, organizations with accurate SBOMs queried their exposure in minutes. Automation helps keep SBOMs up to date, so you're not generating them during a crisis.

Minimize your attack surface. Every package in your container image is a potential vector. Traditional base images include shells, package managers, and utilities that applications rarely use but attackers often exploit. Minimal images strip away unnecessary functionality, reducing both potential CVE entries and blast radius.

Rebuild continuously. Software doesn't stay secure on its own. New vulnerabilities are discovered daily. 35,448 have been discovered just this year(over 120 a day) and we’re not even done with Q4 at the time of writing. Continuous rebuilding ensures you're always running on the latest patched versions rather than discovering months later that you've been exposed.

Verify your supply chain. After XZ Utils, "trust but verify" is no longer enough. You need cryptographic proof of how the software was built. SLSA provides a framework for building provenance. When auditors ask how you know your software hasn't been tampered with, "we trust our vendors" won’t cut it.

The theme across all of these: work smarter, not harder. Investing in the right foundations up front means spending less time scrambling when the next big CVE drops.

How Chainguard helps with vulnerability management and prevention

Minimal images, continuous rebuilding, comprehensive SBOMs, verified builds: implementing all of this from scratch requires significant engineering investment. Most organizations lack the resources to create this infrastructure.

Chainguard Containers are built from the ground up to be secure by default. They're continuously rebuilt with the latest patches, stripped of unnecessary components, and ship with zero or near-zero CVEs. Each image includes a detailed SBOM and cryptographic attestations, so you always know exactly what you're running.

For organizations tired of the reactive patching treadmill, this means reclaiming engineering time for actual product development instead of chasing vulnerability alerts.

Want to see what zero CVEs look like? Contact a Chainguard expert to discover how secure foundations can enhance your security posture.