CVE-2026-35193: Django Information Disclosure Vulnerability

CVE-2026-35193 Overview

CVE-2026-35193 is an information disclosure vulnerability in Django's caching middleware. The flaw affects Django 5.2 before 5.2.15 and Django 6.0 before 6.0.6. The django.middleware.cache.UpdateCacheMiddleware does not add Authorization to the Vary response header when requests carry that header without Cache-Control: public. Remote attackers can read private cached responses by issuing unauthenticated requests to the same URL. Earlier unsupported Django series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected. Django credits Shai Berger for reporting the issue. The weakness is classified under [CWE-524] (Use of Cache Containing Sensitive Information).

Critical Impact

Unauthenticated remote attackers can retrieve cached responses intended for authenticated users, exposing private data through shared cache entries.

Affected Products

• Django 5.2 before 5.2.15
• Django 6.0 before 6.0.6
• Earlier unsupported series (5.0.x, 4.1.x, 3.2.x) may also be affected

Discovery Timeline

• 2026-06-03 - CVE-2026-35193 published to NVD
• 2026-06-03 - Last updated in NVD database
• Reporter - Shai Berger reported the issue to the Django project

Technical Details for CVE-2026-35193

Vulnerability Analysis

The vulnerability resides in django.middleware.cache.UpdateCacheMiddleware, the component responsible for storing rendered responses in Django's cache backend. When a request includes an Authorization header but the response does not carry Cache-Control: public, the middleware fails to include Authorization in the Vary response header. The Vary header instructs downstream caches and Django's own cache key logic to differentiate cache entries based on the listed request headers. Without Authorization in Vary, responses generated for an authenticated user can be served from cache to unauthenticated requesters hitting the same URL.

Root Cause

The root cause is incorrect handling of cache variance for authenticated responses. Django's caching layer assumes that responses lacking Cache-Control: public do not require differentiation by Authorization, but UpdateCacheMiddleware still stores those responses. The resulting cache entry is keyed without consideration of authentication state, conflating authenticated and anonymous traffic under one cache slot. This maps to [CWE-524], use of cache containing sensitive information.

Attack Vector

An attacker sends an unauthenticated HTTP request to a URL whose cached response was populated by an authenticated user. Because the cache key omits Authorization, the middleware returns the previously cached authenticated response. No credentials, user interaction, or special privileges are required against the vulnerable middleware. The attack is network-reachable wherever the Django cache is exposed, including standard web deployments behind load balancers.

No public proof-of-concept code is referenced in the advisory. See the Django Weblog Security Updates for project-supplied technical detail.

Detection Methods for CVE-2026-35193

Indicators of Compromise

• Cached HTTP responses served to clients that did not present an Authorization header but contain user-specific content.
• Cache entries whose Vary header omits Authorization despite originating requests carrying that header.
• Anomalous read patterns against cached URLs from unauthenticated source IPs immediately after authenticated traffic.

Detection Strategies

• Audit Django application logs for response cache hits where the requesting session is unauthenticated yet the response body references user identifiers.
• Inspect outgoing Vary headers on responses generated by UpdateCacheMiddleware and flag any that include Authorization-bearing requests without Authorization in Vary.
• Compare cached response payloads against access control expectations using offline review of the cache backend (Redis, Memcached, database cache).

Monitoring Recommendations

• Enable verbose access logging at the reverse proxy and correlate request Authorization presence with downstream cache hits.
• Track Django version inventory across application hosts to identify instances still running 5.2 < 5.2.15 or 6.0 < 6.0.6.
• Alert on requests to authenticated endpoints from clients lacking session cookies or bearer tokens that still return HTTP 200 with personalized content.

How to Mitigate CVE-2026-35193

Immediate Actions Required

• Upgrade Django to 5.2.15 or 6.0.6, depending on the deployed branch.
• Flush existing cache backends to invalidate any responses populated by the vulnerable middleware.
• Review middleware ordering and confirm UpdateCacheMiddleware and FetchFromCacheMiddleware are not caching authenticated endpoints unintentionally.

Patch Information

The Django project released fixed versions 5.2.15 and 6.0.6 on 2026-06-03. Refer to the Django Security Release Notes and the Django Weblog Security Updates for release artifacts and changelog details. Security announcements are also distributed through the Django Announce Group.

Workarounds

• Exclude authenticated views from UpdateCacheMiddleware by applying the @never_cache decorator on views that require an Authorization header.
• Set Cache-Control: private explicitly on responses generated for authenticated users to prevent shared cache storage.
• Add Authorization to the Vary header manually using the vary_on_headers decorator until patched versions are deployed.

# Configuration example
pip install --upgrade "Django>=5.2.15,<6.0"  # for the 5.2 branch
pip install --upgrade "Django>=6.0.6"        # for the 6.0 branch

# Flush cache after upgrade (example for Redis-backed cache)
python manage.py shell -c "from django.core.cache import cache; cache.clear()"