CVE-2026-35172: Distribution stale blob access resurrection in Redis cache backend

CVE-2026-35172 · Severity: high · CVSS 7.5 · Published 2026-04-06

Distribution, a toolkit used to manage and store container images, contains a flaw that can restore access to data after it has been deleted. In specific configurations using Redis for caching, a deleted file may become accessible again if another user or repository accesses the same content. This could lead to the unauthorized exposure of sensitive container data that was intended to be removed.

Technologies: github.com/distribution/distribution (Go), github.com/distribution/distribution/v3 (Go). Vendors: Go.

Quick answers

Is CVE-2026-35172 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-35172 being exploited in the wild.
How severe is CVE-2026-35172?
High severity, with a CVSS score of 7.5, published 6 April 2026.
Which products and versions are affected?
Distribution < 3.1.0; github.com/distribution/distribution (Go) SEMVER:introduced=0, SEMVER:introduced=0,last_affected=2.8.3; github.com/distribution/distribution/v3 (Go) SEMVER:introduced=0,fixed=3.1.0.
Is there a fix for CVE-2026-35172?
Yes. github.com/distribution/distribution/v3 (Go): upgrade to 3.1.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-35172 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-35172?
Check whether you run Distribution, github.com/distribution/distribution (Go) or github.com/distribution/distribution/v3 (Go) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • github.com/distribution/distribution/v3 (Go): upgrade to 3.1.0 or later
    go get github.com/distribution/distribution/v3@v3.1.0

Technical details

An improper access control vulnerability exists in Distribution's Redis cache backend. When a blob is deleted from a repository, the `repositoryScopedRedisBlobDescriptorService.Clear` function removes the shared digest descriptor but fails to invalidate the repo-scoped membership set in Redis. If a peer repository subsequently performs a `Stat` or `Get` on the same digest, the shared descriptor is repopulated. Because the original repository still contains the stale membership entry in Redis, it incorrectly trusts the new shared descriptor, effectively resurrecting read access to the deleted blob. This affects versions prior to 3.1.0 when `storage.cache.blobdescriptor` is set to `redis` and `storage.delete.enabled` is true.

Affected products

  • Distribution (formerly Docker Distribution) Distribution < 3.1.0
  • Red Hat OpenShift Container Platform 4.12, 4.13, 4.15, 4.16

Identifiers

  • CVE-2026-35172
  • GHSA-f2g3-hh2r-cwgc
  • GO-2026-4942

Timeline

  • 2026-04-06: advisory: Initial advisory published by GitHub/Distribution maintainers
  • 2026-04-06: disclosed
  • 2026-06-11: patched: Red Hat released patches for OpenShift 4.15
  • 2026-06-17: patched: Red Hat released patches for OpenShift 4.16

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.