CVE-2026-35172: Distribution Auth Bypass Vulnerability

CVE-2026-35172 Overview

CVE-2026-35172 is an Improper Access Control vulnerability in Distribution, a widely-used toolkit designed to pack, ship, store, and deliver container content. Prior to version 3.1.0, Distribution can inadvertently restore read access to blobs in a repository after an explicit delete operation when specific configuration options are enabled. This occurs when both storage.cache.blobdescriptor: redis and storage.delete.enabled: true are configured simultaneously.

The vulnerability stems from a cache desynchronization issue where the delete operation clears the shared digest descriptor but leaves stale repository-scoped membership information behind in the Redis cache. When a subsequent Stat or Get operation occurs from a different repository sharing the same blob, the shared descriptor is repopulated, effectively restoring read access to the supposedly deleted blob from the original repository.

Critical Impact

Deleted container image blobs may remain accessible to unauthorized users due to stale Redis cache entries, potentially exposing sensitive container content that was intended to be permanently removed.

Affected Products

• Distribution versions prior to 3.1.0
• Container registries using Distribution with Redis blob descriptor caching enabled
• Deployments configured with both storage.cache.blobdescriptor: redis and storage.delete.enabled: true

Discovery Timeline

• 2026-04-06 - CVE CVE-2026-35172 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-35172

Vulnerability Analysis

This vulnerability is classified under CWE-284 (Improper Access Control), reflecting the core issue where access controls are not properly enforced after blob deletion operations. The vulnerability exploits a network-accessible attack vector with low complexity, requiring no privileges or user interaction to potentially exploit.

The fundamental issue lies in the architectural design of how Distribution handles blob descriptor caching when Redis is used as the cache backend. Container registries often share blobs across multiple repositories to save storage space—a feature known as content-addressable storage. When a blob is deleted from one repository, the system should ensure that access is revoked completely.

However, the delete path in affected versions only clears the shared digest descriptor from the cache without properly invalidating the repository-scoped membership entries. This creates a race condition where stale cache state can be rehydrated by operations from other repositories that legitimately reference the same content-addressed blob.

Root Cause

The root cause is a cache invalidation failure in Distribution's Redis blob descriptor caching layer. When storage.delete.enabled: true is configured, the delete operation is supposed to remove all traces of a blob from both the storage backend and the cache. However, the implementation failed to account for the multi-layered caching structure where repository-scoped membership entries exist separately from the shared digest descriptors.

The delete operation correctly removes the blob from persistent storage and clears the primary digest descriptor from Redis, but the secondary membership records that track which repositories reference a given blob are not cleaned up. This stale state becomes problematic when another repository's Stat or Get operation for the same blob triggers cache repopulation.

Attack Vector

The attack vector leverages the network-accessible Distribution registry API. An attacker with read access to a repository (repo b) that shares blobs with a target repository (repo a) can potentially restore access to deleted content from repo a through the following mechanism:

1. A blob is shared between repo a and repo b due to content-addressable storage
2. An administrator deletes the blob from repo a, intending to revoke access
3. The delete operation clears the shared descriptor but leaves stale membership for repo b
4. Any subsequent access to the blob through repo b repopulates the shared descriptor
5. The blob becomes readable again from repo a, bypassing the intended deletion

This vulnerability mechanism can be exploited without authentication in registries that allow anonymous read access, or by any authenticated user with read permissions to a repository sharing content with the deleted target.

Detection Methods for CVE-2026-35172

Indicators of Compromise

• Unexpected blob access logs for content that was previously deleted from a repository
• Redis cache entries showing descriptor data for blobs that should have been purged
• Discrepancies between blob storage state and registry API accessibility for deleted content

Detection Strategies

• Monitor registry access logs for GET or HEAD requests to blobs that have been deleted
• Implement Redis cache auditing to detect orphaned or stale blob descriptor entries
• Cross-reference blob deletion events with subsequent access patterns to identify potential exploitation
• Deploy integrity checking between persistent storage and cache state for blob references

Monitoring Recommendations

• Enable detailed logging for all blob delete operations including cache invalidation steps
• Set up alerts for blob access attempts returning success after documented deletion events
• Regularly audit Redis cache entries against authoritative storage backend state
• Monitor for unusual cross-repository blob access patterns that may indicate cache manipulation

How to Mitigate CVE-2026-35172

Immediate Actions Required

• Upgrade Distribution to version 3.1.0 or later immediately
• If immediate upgrade is not possible, temporarily disable Redis blob descriptor caching by removing the storage.cache.blobdescriptor: redis configuration
• Audit recent blob deletions to identify any that may have been affected by this vulnerability
• Clear the Redis cache completely after upgrading to ensure no stale entries remain

Patch Information

The vulnerability is addressed in Distribution version 3.1.0. The fix ensures that blob deletion operations properly invalidate all associated cache entries, including repository-scoped membership records, preventing the cache desynchronization issue. For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• Disable Redis blob descriptor caching by setting storage.cache.blobdescriptor: inmemory or removing the Redis configuration entirely
• If blob deletion functionality is not required, set storage.delete.enabled: false to prevent the vulnerable code path from being triggered
• Implement manual Redis cache clearing procedures after each blob deletion operation
• Deploy network-level access controls to limit which clients can access the registry API

# Example configuration to disable Redis caching as a workaround
# Edit your Distribution config.yml file

storage:
  cache:
    # Change from 'redis' to 'inmemory' to avoid the vulnerability
    blobdescriptor: inmemory
  delete:
    enabled: true
  # ... rest of storage configuration