CVE-2026-35172: 
NixOS vulnerability analysis and mitigation

CVE-2026-35172 is a stale blob access resurrection vulnerability in the distribution container registry project (formerly Docker Registry), classified as Improper Access Control (CWE-284). When both storage.cache.blobdescriptor: redis and storage.delete.enabled: true are configured, the delete operation fails to fully revoke repository-scoped Redis cache membership, allowing previously deleted blobs to become readable again after a peer repository repopulates the shared descriptor. Affected versions are <= 2.8.x (Go module github.com/distribution/distribution) and <= 3.0.x (Go module github.com/distribution/distribution/v3); the patched version is 3.1.0. IBM Business Automation Insights is also listed as an affected product. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, GHSA Advisory).

The root cause lies in the incomplete cache invalidation path within repositoryScopedRedisBlobDescriptorService.Clear() in registry/storage/cache/redis/redis.go. When a blob is deleted from repo a, the method verifies digest membership in the repo-scoped Redis set and then calls upstream.Clear(), which deletes the shared digest descriptor hash — but critically does not remove the digest from repo a's repository membership set (SRem). When repo b subsequently performs a Stat or Get on the same digest (which it legitimately owns), the shared descriptor is recreated in Redis. Because repo a's stale membership entry was never purged, repositoryScopedRedisBlobDescriptorService.Stat for repo a finds the membership entry, trusts the now-repopulated shared descriptor, and serves the blob — effectively resurrecting read access that was explicitly revoked. The fix (commit 078b078) replaces the single upstream.Clear() call with an atomic Redis pipeline (TxPipeline) that atomically executes SRem on the repo membership set, Del on the repo-scoped descriptor hash, and HDel on the shared descriptor hash fields (GHSA Advisory, Fix Commit).

The confirmed impact is a repository-local confidentiality failure: an operator who deletes sensitive blob content from repo a may observe immediate revocation, but the same content can become readable again from repo a as soon as any peer repository (repo b) warms the shared Redis descriptor for the same digest. This is an unauthenticated, network-accessible data disclosure — no privileges or user interaction are required to trigger the re-access. Integrity and availability are not affected; the vulnerability is bounded to confidentiality of blob data within the affected registry instance (GHSA Advisory).

A public proof-of-concept (PoC) is available as poc.zip attached to the GitHub Security Advisory, implemented as a deterministic integration harness using miniredis and the distribution source tree, with reproducible steps (make canonical) that produce [PROOF_MARKER]: repo_a_access_restored=true and confidentiality_boundary_broken=true. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.032–0.061% (low probability of near-term exploitation). The vulnerability is not listed in the CISA KEV catalog. Detection plugins are available in Qualys (ID 5010471) and Nessus (IDs 305620, 311486, 313696) (GHSA Advisory, Github Advisory).

1. Identify a vulnerable target: Locate a distribution registry instance (v2.8.x or v3.0.x) configured with both storage.cache.blobdescriptor: redis and storage.delete.enabled: true. This configuration is required for the vulnerability to be exploitable.
2. Confirm shared digest: Identify a blob digest that exists in at least two repositories (repo a and repo b) on the same registry instance. This can be done by pushing the same image layer to both repositories.
3. Wait for or observe deletion: Wait for an operator to delete the blob from repo a (e.g., via DELETE /v2/<repo-a>/blobs/<digest>). Immediately after deletion, repo a correctly returns 404 Blob Unknown.
4. Trigger peer repository cache warm: Issue a HEAD or GET request against the same digest via repo b (e.g., GET /v2/<repo-b>/blobs/<digest>). Since repo b still legitimately owns the blob, this repopulates the shared Redis descriptor for that digest.
5. Access deleted blob from repo a: Issue a subsequent GET /v2/<repo-a>/blobs/<digest> request. Due to the stale Redis membership entry for repo a, the registry now serves the blob content that was supposed to be deleted, confirming the confidentiality boundary is broken (GHSA Advisory).

• Network: Unexpected successful HTTP 200 responses to GET /v2/<repo>/blobs/<digest> requests for digests that were previously deleted from that repository (observable in registry access logs or network monitoring).
• Logs: Registry access logs showing a DELETE operation on a blob digest from repo a followed by a later successful GET or HEAD for the same digest from repo a — particularly after an intervening successful request from repo b for the same digest.
• Redis State: Presence of a digest string in the Redis set key for a repository's blob membership (e.g., registry:v2:blobs:sha256:<digest>:repo:<repo-a>:_manifests) after a confirmed delete operation on that repository; this stale membership entry is the direct indicator of the vulnerable state.
• Behavioral: A pattern of blob access from repo a resuming after a period of 404 responses, correlated with activity from repo b on the same digest (GHSA Advisory).

Upgrade to github.com/distribution/distribution/v3 version 3.1.0 or later, which contains the atomic Redis pipeline fix (commit 078b078). For the legacy v2 module (<= 2.8.x), no patched version is listed in the advisory — users should migrate to the v3 module. As a temporary workaround until patching is possible, disable either Redis blob descriptor caching (storage.cache.blobdescriptor) or blob deletion (storage.delete.enabled) in the registry configuration — the vulnerability requires both to be enabled simultaneously. IBM Business Automation Insights users should apply the May 2026 iFixes (IBM Advisory, GHSA Advisory, Fix Commit).

The vulnerability was reported by security researcher 1seal and published by milosgajdos (a distribution maintainer) on April 6, 2026. Coverage has appeared on pro-linux.de noting the access control deficiency in Docker distribution. No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability database aggregation (GHSA Advisory).