Going deep: Upstream distros and hidden CVEs

CVEs serve as our shared industry shorthand for software risk, providing a critical measurable baseline for security posture, with vulnerability counts and remediation SLAs included in procurement security questionnaires and compliance audits. This has driven a massive industry shift, with "zero-CVE" container images moving from a novel “shift left” starting point to almost an expectation when building containerized applications or running containerized workloads. While companies like Chainguard have proven that achieving zero CVEs without sacrificing functionality is possible, vendors tethered to traditional Linux distributions face a steeper, more compromised climb.

The core of the struggle lies in the long dependency chains and slower release cycles of upstream distro maintainers. They simply cannot keep pace with today’s explosive growth in reported vulnerabilities. Because these vendors rely on upstream distros to patch and rebuild, there is an inevitable lag between disclosure and a fix. This puts vendors that rely on distros like Debian or Alpine in a bind: they inherit vulnerabilities they didn’t create and can’t easily control.

While Debian is an impressive community distribution, offering a hardened container product based on a relatively slow-moving community base limits a downstream hardened image vendor’s ability to quickly pull in fixes from upstream.

Let’s look at an example in Docker Hardened Images, which relies on Debian and Alpine as its distro. DHI appears to suppress CVEs that have fixes merged upstream by the original maintainers, but have not been pulled into DHI images. When suppressing these CVEs, they point to their no-DSA (where DSA is Debian Security Advisory) status in the Debian project. However, no-DSA simply means that Debian is not immediately prioritising a fix for the CVE, not that Debian isn’t affected.

To put it simply: the vulnerability exists in DHI, and a fix is available upstream, but it has not been pulled into DHI. The CVE is automatically suppressed in scans by Docker Scout and in other scanners using the VEX document (explained in a moment). Neil Carpenter from Minimus recently published an article that also details this process.

Below are three CVEs that follow this pattern. We’ll also share some thoughts on how Docker may have painted itself into a corner by basing DHI on existing distributions over which it has no control.

DHI and VEX

First, a little context on DHI and the VEX format they use to publish information on how CVEs affect their images.

DHI is built on Debian. This means that, by default, they inherit Debian’s packages, Debian’s security posture, and Debian’s release timelines.

Docker publishes VEX documents for their DHI images. VEX stands for Vulnerability Exploitability eXchange. These are JSON documents that provide further information and context on CVEs linked to a given artifact. For example, you can pull a VEX document for the nginx:1.27 image with the following:

docker pull dhi.io/nginx:1.27 &&  docker scout vex get registry://dhi.io/nginx:1.27 --output nginx-vex.json

(Yes, you do seem to need to pull the image first.)

Their VEX documents primarily consist of Debian-sourced info (no-dsa). Many of the CVEs flagged as no-DSA are completely unexploitable and can be addressed reasonably in this way.

Fixed upstream (but not in DHI)

This issue arises with specific CVEs that have a legitimate fix merged by upstream maintainers, but the fix has not yet been incorporated into DHI. In these cases, Debian has marked these CVEs as no-DSA with messages indicating that remediation has not been prioritized. Notably, these CVEs remain present and affect the image, but will not be prioritized by Debian until a later release. Another way of saying this is that the CVE is present and legitimate, but Debian does not consider it worth rushing out a patch outside its usual release cycle.

Let’s take a look at a couple of these CVEs.

CVE-2026-0861

This CVE affects glibc and various memory functions. It is a real CVE that can result in integer overflow & heap corruption. NVD rates this 8.4 HIGH. It is difficult to exploit, so the fix was not prioritised by Debian, which marked it “no-dsa”. But it is definitely a security flaw, and a patch exists.

Docker is in a bit of a difficult spot on this, since Debian has decided not to prioritize this fix. Docker could cherry-pick the upstream commit to apply to their DHI images, but then they’d be effectively maintaining a fork of Debian. Alternatively, they could take the hit, not suppress the CVE in published VEX documents, and let Docker Scout detect the CVE, which legitimately applies to many DHI images (golang, python, postgres, nginx, and many others).

In this case, Docker chose a third path. They did not apply any patches and continued using the standard Debian version of glibc. To suppress the CVE, they added the following VEX statement:

{
      "@id": "debian-nodsa-CVE-2026-0861",
      "vulnerability": {
        "name": "CVE-2026-0861"
      },
      "products": [...],
      "status": "not_affected",
      "status_notes": "Marked no-dsa by Debian Security Team; see https://security-tracker.debian.org/tracker/CVE-2026-0861",
      "justification": "vulnerable_code_cannot_be_controlled_by_adversary",
      "timestamp": "2026-01-19T22:28:53Z"
    },

Retrieved via docker scout vex get --output redis.vex dhi.io/redis:8@sha256:b9f14448dcb4eaeeab5915c99b29583ee14b199a1b429cff8b258936b9cb3617

This CVE has been marked as “not affected,” but the image is still vulnerable because no patch has been applied.

Fundamentally, this third path (reading Debian’s no-DSA as “not affected” and suppressing the CVE) is not a legitimate choice. The CVE does affect the image and should register in scanner results until it is patched. Debian’s decision not to prioritize patching outside its release cycle is not grounds for suppressing the CVE.

CVE-2026-0915

CVE-2026-0915 is a similar situation to the previous CVE. The security vulnerability is real and can lead to memory contents leaking. NVD rates this 7.5 HIGH. Exploiting the CVE is difficult, so the Debian team chose to wait for the next release rather than rebuild such a fundamental package. But it is a real CVE with a non-zero security risk that should be patched.

Again, the status of “not affected” does not make sense in this context. Until the image is patched and rebuilt, the image is affected, and scanner results should return this CVE against this image until the patch is pulled in. Because this is a CVE in glibc, this also affects many, if not all, of the Debian-based DHI images.

The relevant VEX document can be retrieved with the same command as above:

docker scout vex get --output redis.vex dhi.io/redis:8@sha256:b9f14448dcb4eaeeab5915c99b29583ee14b199a1b429cff8b258936b9cb3617

CVE-2025-6141 (ncurses) - Stack buffer overflow in postprocess_termcap

CVE-2025-6141 affects ncurses and allows buffer overflow when processing termcap entries. It requires local access and so is listed as low severity. It was fixed in March 2025 in ncurses 6.5-20250329.

The VEX statements published by Docker suppressing this CVE in the DHI golang image are a little mysterious.

There are two statements for the CVE. The first is timestamp August 2025, five months after the ncurses fix was released, “Waiting for upstream fix release,” perhaps referring to a Debian fix:

{
  "@id": "b8f5f402-2d39-4e01-b7f7-31f19a85b2ee",
  "vulnerability": { "name": "CVE-2025-6141" },
  "status": "under_investigation",
  "impact_statement": "Waiting for upstream fix release",
  "timestamp": "2025-08-05T20:36:14Z"
}

The second entry is time-stamped January 2026. Instead of patching, a “not affected” status is added. However, no patch has been applied, and the patch has been upstream for ten months at this point:

{
  "@id": "debian-nodsa-CVE-2025-6141",
  "vulnerability": { "name": "CVE-2025-6141" },
  "status": "not_affected",
  "status_notes": "Marked no-dsa by Debian Security Team; see https://security-tracker.debian.org/tracker/CVE-2025-6141",
  "justification": "vulnerable_code_cannot_be_controlled_by_adversary",
  "timestamp": "2026-01-21T21:50:12Z"
}

The relevant VEX document can be retrieved with:

docker pull dhi.io/golang:1.23@sha256:31398e476325627a94bf3c45dd5134f2d891b1456b36bf77b69179a0a0c7c04c  && docker scout vex get registry://dhi.io/golang:1.23@sha256:31398e476325627a94bf3c45dd5134f2d891b1456b36bf77b69179a0a0c7c04c --output golang-vex.json

Misinterpreting DSA

Debian Security issues DSAs for vulnerabilities they consider serious enough to warrant an immediate advisory and patched package release outside the normal release cycle. A no-dsa means Debian won’t issue a standalone security advisory for this CVE and will not prioritize a patch outside of the usual release cycle. It does not mean that the CVE does not affect Debian or distributions or projects downstream of Debian. The Debian Security Team also notes that “[e]ntries in the Debian Security Tracker do not imply anything about how a vulnerability may affect systems other than Debian.”

Debian is a community project. Many Debian users are desktop users, hobbyists, or otherwise have a limited threat model. While Debian is production-ready and a vital part of the ecosystem, it isn’t in any sense a “hardened” OS, nor is its release cycle notably fast.

Using Debian as the basis for DHI has some advantages for Docker. It’s familiar to users and has a good chance of being compatible in existing Dockerfiles. It also means that Docker isn’t on the hook for building, forking, or otherwise maintaining their own OS. However, in this case, the outcome is misleading VEX statements that could lead to real risk.

Final thoughts

Ultimately, pursuing a zero-CVE state on top of traditional distributions often forces a choice between a clean scan and transparency. As zero-CVE container images become the rule rather than the exception, these hidden trade-offs become increasingly unsustainable.

Chainguard’s position remains that security outcomes must be real, verifiable, and achieved without sacrificing functional integrity or supply chain visibility. In an environment where transparency is the foundation of trust, how a vendor reaches zero matters just as much as the number itself. That’s why Chainguard has built and maintained Chainguard OS, providing end-to-end integrity and control over the packages and container images we build and deliver for organizations’ production environments.

To learn more about Chainguard’s approach to supply chain security, check out CEO Dan Lorenc’s recent blog.