Executive Summary

CVE-2026-35172 is a high-severity vulnerability in the distribution project (versions ≤ 3.0.x and ≤ 2.8.x) that occurs when both Redis blob descriptor caching and delete functionality are enabled. When a blob is deleted from one repository (repo A), the system clears the shared digest descriptor but fails to remove the blob's membership from the repository-specific set in Redis. This incomplete invalidation allows another repository (repo B) that still references the blob to repopulate the shared descriptor. As a result, repo A can regain read access to the deleted blob, bypassing intended access controls.

Technically, the vulnerability arises because the delete path only clears the shared descriptor but leaves stale repository-scoped membership data behind. This stale data causes a revocation gap where access is initially denied after deletion but later restored without authorization. The issue is exploitable remotely without privileges or user interaction and leads to a confidentiality breach limited to repository-local scope.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact you by allowing unauthorized read access to blobs that were explicitly deleted from a repository. Specifically, after deleting a blob from repository A, an attacker or unprivileged user can exploit stale Redis cache data to regain access to that deleted blob from the same repository.

The impact is a confidentiality breach at the repository level, meaning sensitive or deleted container content could be exposed unintentionally. There is no impact on data integrity or availability, but the unauthorized access violates expected access control policies.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by verifying if deleted blobs in repository A become accessible again after being accessed from repository B, due to stale Redis cache entries.

A practical detection method involves monitoring blob access behavior before and after deletion, specifically checking if a Stat or Get request to a deleted blob in repository A initially returns an error (e.g., ErrBlobUnknown) but later succeeds after repository B accesses the same blob.

Commands to help detect this behavior could include:

• Perform a blob deletion in repository A.
• Attempt to access the deleted blob in repository A and confirm it returns an error.
• Access the same blob from repository B to repopulate the Redis cache.
• Retry accessing the blob in repository A; if access is restored, the vulnerability is present.

Additionally, inspecting Redis keys related to blob descriptors and repository membership sets for stale entries after deletion could help detect the issue, though specific Redis commands are not detailed in the provided information.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade the distribution project to version 3.1.0 or later, where the vulnerability is fixed by atomic invalidation of both the shared digest descriptor and the repository membership set in Redis during blob deletion.

Until the upgrade can be applied, consider disabling either the Redis blob descriptor cache (`storage.cache.blobdescriptor: redis`) or the delete functionality (`storage.delete.enabled: true`) to prevent the vulnerability from being exploitable.

Monitoring and auditing blob access patterns to detect unexpected access to deleted blobs can also help in identifying exploitation attempts.

Useful 0 Not Useful 0

Compliance Impact

CVE-2026-35172 causes a repository-local confidentiality breach by allowing deleted blobs to be read again due to stale repository membership data in Redis. This improper access control (CWE-284) could lead to unauthorized disclosure of sensitive data stored in container blobs.

Such unauthorized data exposure may impact compliance with data protection regulations like GDPR and HIPAA, which require strict controls over access to sensitive or personal data and mandate proper data deletion and confidentiality safeguards.

Because the vulnerability allows read access restoration to deleted blobs without privileges or user interaction, it undermines data confidentiality expectations and could result in non-compliance with these standards if sensitive data is involved.

Useful 0 Not Useful 0