CVE-2026-8404: Django Information Disclosure Vulnerability

CVE-2026-8404 Overview

CVE-2026-8404 is an information disclosure vulnerability in Django's django.middleware.cache.UpdateCacheMiddleware. The middleware fails to match Cache-Control response directives case-insensitively. As a result, responses with uppercase or mixed-case Cache-Control directives can be incorrectly cached and served to other users.

Remote attackers can read responses that should not have been cached. The flaw is classified as [CWE-178] Improper Handling of Case Sensitivity. Django 5.2 before 5.2.15 and 6.0 before 6.0.6 are affected. Earlier unsupported series (5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.

Critical Impact

Remote attackers can retrieve responses intended for other users when Cache-Control directives use non-lowercase formatting, leading to unintended information disclosure.

Affected Products

• Django 5.2 before 5.2.15
• Django 6.0 before 6.0.6
• Potentially earlier unsupported series (5.0.x, 4.1.x, 3.2.x)

Discovery Timeline

• 2026-06-03 - CVE-2026-8404 published to NVD
• 2026-06-03 - Last updated in NVD database
• Reported by - Ahmed Badawe (credited by Django)

Technical Details for CVE-2026-8404

Vulnerability Analysis

Django's UpdateCacheMiddleware inspects outgoing HTTP responses and decides whether to store them in the cache backend. The decision relies on parsing Cache-Control directives such as private, no-store, and no-cache. These directives instruct intermediaries and application caches to skip storing the response.

The middleware performs string comparisons against lowercase directive names. RFC 7234 defines Cache-Control directives as case-insensitive tokens. When an application emits Private, NO-STORE, or No-Cache, the middleware does not recognize the directive and proceeds to cache the response. Subsequent requests matching the cache key receive the stored response, even when it contains user-specific or sensitive data.

Root Cause

The root cause is improper handling of case sensitivity [CWE-178] in directive parsing. The middleware compares directive tokens using case-sensitive string operations rather than normalizing input to a single case. This violates the HTTP caching specification and breaks the contract developers expect when setting Cache-Control headers programmatically.

Attack Vector

Exploitation requires that a vulnerable Django application uses UpdateCacheMiddleware and serves a view emitting Cache-Control directives in non-lowercase form. An attacker triggers the cached response by issuing a matching request to the affected URL. The cache returns the previously stored response, which may include another user's data, authenticated content, or otherwise private information.

The attack is unauthenticated and remote. User interaction by the original requester is required to populate the cache. The exposure is limited to confidentiality of cached responses.

No verified public exploit code is available. See the Django Weblog Security Releases for technical details.

Detection Methods for CVE-2026-8404

Indicators of Compromise

• Cached responses served to users who did not generate them, identified through application logs correlating cache hits with differing session identifiers.
• Presence of Cache-Control headers with uppercase or mixed-case directives in application source code or response traces.
• Anomalous cache hit rates on views that should bypass caching due to private or no-store directives.

Detection Strategies

• Audit Django codebases for HttpResponse headers and decorators that set Cache-Control values, flagging any non-lowercase directive tokens.
• Inspect deployed middleware configuration for django.middleware.cache.UpdateCacheMiddleware and confirm the running Django version against the patched releases.
• Add integration tests that issue requests as distinct users and verify response bodies are not shared across sessions through the cache.

Monitoring Recommendations

• Log cache key generation and hits at the middleware layer to identify responses served from cache that contain authenticated content.
• Monitor reverse proxy and CDN logs for unexpected cache reuse on endpoints returning user-specific data.
• Track Django version inventory across deployments to identify hosts still running 5.2.x prior to 5.2.15 or 6.0.x prior to 6.0.6.

How to Mitigate CVE-2026-8404

Immediate Actions Required

• Upgrade Django to version 5.2.15 or 6.0.6, depending on the deployed series.
• Review application code and third-party libraries for Cache-Control headers using uppercase or mixed-case directives and normalize them to lowercase.
• Invalidate existing cache entries after upgrading to remove any improperly cached responses.

Patch Information

The Django security team released fixed versions 5.2.15 and 6.0.6 on June 3, 2026. The patches modify UpdateCacheMiddleware to perform case-insensitive matching on Cache-Control directives. Patch details are published in the Django Security Releases Documentation and announced through the Django Announcements Group.

Workarounds

• Remove django.middleware.cache.UpdateCacheMiddleware and FetchFromCacheMiddleware from MIDDLEWARE until the upgrade is applied.
• Standardize all Cache-Control directives to lowercase using a custom middleware that rewrites response headers before caching.
• Disable per-site caching for endpoints returning sensitive or user-specific data and use explicit @never_cache decorators on those views.

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