CVE-2026-6907: Django Information Disclosure Vulnerability

CVE-2026-6907 Overview

CVE-2026-6907 is an information exposure vulnerability [CWE-524] in the Django web framework. The flaw resides in django.middleware.cache.UpdateCacheMiddleware, which incorrectly caches responses to requests whose Vary header contains an asterisk (*). According to HTTP caching semantics, a Vary: * value signals that the response varies on factors not captured by request headers and must not be served from a shared cache. Django stored these responses anyway, allowing private data intended for a single user to be returned to other clients. The issue affects Django 6.0 before 6.0.5 and Django 5.2 before 5.2.14. Earlier unsupported series including 5.0.x, 4.1.x, and 3.2.x may also be affected.

Critical Impact

Cached responses for requests with Vary: * can leak per-user data to unauthorized requesters sharing the cache.

Affected Products

• Django 6.0 before 6.0.5
• Django 5.2 before 5.2.14
• Earlier unsupported series (5.0.x, 4.1.x, 3.2.x) potentially affected

Discovery Timeline

• 2026-05-05 - Django publishes security release crediting Ahmad Sadeddin for reporting the issue
• 2026-05-05 - CVE-2026-6907 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-6907

Vulnerability Analysis

The vulnerability lies in how UpdateCacheMiddleware evaluates the Vary response header before storing a response. RFC 7234 defines Vary: * as a signal that the response depends on request attributes outside the header set, and shared caches must treat such responses as uncacheable. Django's middleware did not honor this directive. It generated a cache key and persisted the response in the configured cache backend, then served it to subsequent requests matching the constructed key.

When a view sets Vary: * to indicate per-user content, the cached payload may contain authenticated session data, personal information, or authorization-specific output. A second user issuing a request that maps to the same cache key receives the prior user's response. The vulnerability is classified under [CWE-524] (Use of Cache Containing Sensitive Information).

Root Cause

The middleware's caching decision logic checked for the presence of Vary headers but did not exclude entries containing the wildcard token. The fix updates the cache key generation and storage path to skip caching when Vary: * is present, aligning Django with HTTP cache control semantics.

Attack Vector

Exploitation requires the target application to enable UpdateCacheMiddleware and to serve responses that include Vary: *. An attacker submits a request that produces the same cache key as a victim's prior request and receives the cached response containing the victim's data. The attack is network-reachable, requires no privileges, and depends on the application's caching configuration and traffic patterns.

No public proof-of-concept exploit code is available. Refer to the Django Weblog Security Update for vendor technical details.

Detection Methods for CVE-2026-6907

Indicators of Compromise

• User reports of seeing another account's data, profile information, or session-specific content on cached pages
• Cache backend entries (Redis, Memcached, database cache) containing responses generated for views that emit Vary: *
• Unexpected Set-Cookie or authenticated content appearing in responses to anonymous or unrelated users

Detection Strategies

• Audit Django projects for use of django.middleware.cache.UpdateCacheMiddleware or the @cache_page decorator combined with views that set Vary: *
• Inspect response headers in production traffic logs for Vary: * paired with cache hit indicators such as X-Cache: HIT or stored cache keys
• Run pip show django or parse requirements.txt and lockfiles to identify deployments running versions below 6.0.5 or 5.2.14

Monitoring Recommendations

• Enable structured logging on the cache backend and alert on entries whose stored headers contain Vary: *
• Monitor application error trackers and customer support channels for cross-user data exposure reports
• Track package inventories with software composition analysis to flag vulnerable Django versions across services

How to Mitigate CVE-2026-6907

Immediate Actions Required

• Upgrade Django to 6.0.5 or 5.2.14 depending on the deployed series
• Inventory all services running unsupported Django releases (5.0.x, 4.1.x, 3.2.x) and migrate them to a supported, patched version
• Invalidate existing cache backends after patching to purge any sensitive responses stored under the vulnerable behavior

Patch Information

The Django project released fixed versions on 2026-05-05. Apply Django==6.0.5 or Django==5.2.14. Full release notes are available in the Django Security Release Notes and the Django Weblog Security Update.

Workarounds

• Remove django.middleware.cache.UpdateCacheMiddleware and FetchFromCacheMiddleware from MIDDLEWARE until upgrading
• Avoid emitting Vary: * in views handled by the cache middleware, or wrap such views with @never_cache
• Configure upstream reverse proxies or CDNs to strip cache storage when Vary: * is observed in origin responses

# Upgrade Django to a patched version
pip install --upgrade "Django>=6.0.5,<6.1"  # for the 6.0 series
pip install --upgrade "Django>=5.2.14,<5.3" # for the 5.2 series

# Flush the cache after upgrading (example for Django's cache framework)
python manage.py shell -c "from django.core.cache import cache; cache.clear()"