TL;DR: Based on data for nearly 40 popular software projects, EOL software accumulates — on average — 218 CVEs every six months. You’re SOL if you’re running EOL container images.
Attackers recently compromised a U.S. government agency through exploiting a vulnerability in outdated or ‘End-of-Life’ (EOL) Adobe software, highlighting the importance of using supported software versions. Supported software offers users peace of mind: users get security and bug updates as needed without worrying about breaking changes from major version updates.
Typically, there's a schedule for how long a specific software version gets updates. This is common for both open source software and proprietary software. However, eventually, every version of software will stop receiving support. This is known as the End-of-Life (EOL) stage, when project maintainers stop providing updates, including those for security or bug fixes.
So what happens when that support ends? As you might expect, the software begins to collect vulnerabilities. Older software has been out in the world for longer, which has given people more time to find flaws within that software.
And the problem becomes aggravated when using container images, a modern way of packaging a software application and its dependencies for deployment on cloud platforms. Using a container often means adding additional components from underlying “base images,” which can easily lead to images with hundreds of components, each a part of the attack surface.
Because of this, it raises a handful of questions for images containing EOL projects: How fast are these vulnerabilities accumulating? Where do these vulnerabilities accumulate? Are they in the software application itself, the additional libraries it depends on, or perhaps within parts of the container image?
Here's what we found when we scanned a set of official EOL Docker images:
- Takeaway 1: The longer a project has been EOL, the more vulnerabilities that image will have. Specifically, every six months after the EOL date — on average — 218 vulnerabilities accumulate within that image.
- Takeaway 2: 98.4% of the vulnerabilities accumulate within image components, 1.4% in the application dependencies, and only 0.2% of vulnerability accumulation every six months are directly within the application.
In short, images with EOL software rack up security risks quickly. Not only does the target application accumulate vulnerabilities, but so do the dependencies and additional image components. When a vulnerability appears directly in the source code of the application, you’re truly s*** out of luck (SOL). That application isn’t going to receive a patch from upstream, essentially forcing you to update. Regardless, you need to move on from your EOL projects fast because you're in for a heap of vulnerabilities otherwise.
The details on vulnerability accumulation in EOL images
To perform this analysis, we looked at a set of software projects listed on https://endoflife.date/, a website that keeps track of when products are no longer supported. We matched these projects directly with their official Docker Hub images, finding 38 projects (across 237 EOL version releases from 2020–2024). This includes popular images such as Traefik, NGINX, Rust, and Python. Each version is the last within the project lifecycle right before the EOL date, representing the final updates to the project before it goes EOL. We used Grype to scan each release to determine where vulnerabilities are appearing in the projects.
When scanning an image for vulnerabilities, we classify the vulnerability as being in one of three locations:
- Application: The core software intended for execution, fulfilling the container's primary purpose. Think of images such as Traefik, Consul, or Nginx.
- Application dependencies: Software or libraries the application requires to function and are dependent on the core application source code. For example, Traefik depends on a TOML parser for Golang.
- Image components: Additional packages or libraries included within the image, often influenced by the base image. Think Alpine or Debian packages. For example, Traefik uses the base image Alpine.
Typically, within our dataset, the support lifespan for these projects was almost two years, with the median support duration of one year. By aggregating vulnerability counts in six-month intervals based on the EOL date, we calculated the average number of vulnerabilities per project. We note these versions are the last version prior to the EOL date, representing the final updates for that project lifecycle.
The number of vulnerabilities between older EOL versions and recently EOL versions drastically differ, as shown in Figure 1. For example, the average number of vulnerabilities of an image that went EOL in early 2020 now contain 2,065 vulnerabilities, compared to images with an EOL in 2024 contain 323 vulnerabilities. On average, we see an accumulation rate of 218 vulnerabilities every six months in EOL images.
Where are the vulnerabilities?
Application vulnerabilities
Less than 1% of vulnerability accumulation occurs directly in the application of an image. We only saw 14% of the versions containing a vulnerability directly in the application within the first six months post-EOL. However, project maintainers won't patch these CVEs. Updating to the application's newer version or rolling up your sleeves and patching it yourself in the source code is the only way to address these vulnerabilities.
Dependency vulnerabilities
In the first six months post-EOL, 40% of versions contain a vulnerability in the application dependencies. On average, dependencies have three vulnerabilities within the first six months post-EOL, then 11 in the next six months, and soaring to 32 vulnerabilities for versions older than a year. Fixing these would involve upgrading dependencies and rebuilding the target application. No easy task.
Image component vulnerabilities
Ninety-eight percent of vulnerability accumulation occurs within the components of the image. With vulnerability averages of 340 in the first six months, 501 up to a year, and 1,552 past a year. Ninety-seven percent of these vulnerabilities are within Debian packages; check out our Zero-CVE challenge if you think you can apt-get update those away. Spoiler…you pretty much can't.
A deeper look at Traefik
When scanning the official alpine-based image for Traefik with Grype, we see the image versions are on the smaller side of vulnerability accumulation, with an average of 25 vulnerabilities identified every six months, as shown in Figure 2.
Take version 2.9 of Traefik as an example. It was released on October 3, 2022, with security support provided until April 24, 2023, which is roughly six months. The final update for this version, 2.9.10, was made available on April 6, 2023, just three weeks before the end of its support lifecycle. Following the release of version 2.9.10, 55 vulnerabilities were reported: four within Traefik itself, 31 associated with its application dependencies, and 20 related to the Docker image components. Below are example CVEs within the various locations of v2.9.10 of the official Traefik Docker image:
Example CVE within Traefik
- CVE-2023-47633: Traefik docker container using 100% CPU. This issue was addressed in versions 2.10.6 and 3.0.0-beta5. Users are advised to upgrade. There are no known workarounds for this vulnerability; your only option is to update.
Example CVE within a dependency (Docker) of Traefik
- CVE-2023-28840: Docker Swarm encrypted overlay network may be unauthenticated. The affected project is github.com/docker/docker, a dependency of Traefik. We fixed this vulnerability in the Chainguard Image of the Traefik 2.10 cycle.
Example CVE within an image component of Traefik
- CVE-2023-5363: An out-of-bounds write within OpenSSL, a dependency of the base image Alpine 3.17 used by Traefik (impacts libcrypto3 and libssl3). The Chainguard Image of Trafeik uses the wolfi-base image, which runs the updated versions of libcrypto3 and libssl3.
Final thoughts
EOL software represents a significant security risk. As vulnerabilities appear, they will not receive patches from upstream once the application is no longer supported. This issue becomes particularly critical when vulnerabilities are found directly in the target application of the image.
The only option when that occurs is to update. However, the vast majority of vulnerabilities are showing up in your additional components of images, further emphasizing the need to slim down those images. Regardless, the best option is to have a plan to keep your software updated to the latest versions promptly. Because every six months you keep using that EOL project, that software accumulates — on average — 218 vulnerabilities.
If you are interested in streamlining your container image lifecycle approach, Chainguard Images provide rapid updates for security fixes and bugs in open source software. Reach out to our team today to learn more or visit images.chainguard.dev to get started pulling Chainguard Images.
