CVE-2026-8404: Django Cache-Control Case-Sensitivity Bypass (Low Severity)

Technical summary

The `UpdateCacheMiddleware` component in Django 5.2 (before 5.2.15) and 6.0 (before 6.0.6) performs case-sensitive matching against `Cache-Control` response directives. RFC 7231 specifies that `Cache-Control` tokens are case-insensitive; Django's implementation violates this by requiring lowercase directive names. An attacker can craft or influence responses containing uppercase variants (e.g., `Cache-Control: PRIVATE`) that bypass the middleware's validation logic, resulting in improper caching of sensitive content. The issue is classified under CWE-178 (Improper Handling of Case Sensitivity) and has a CVSS 3.1 score of 3.1 (Low severity). Unsupported Django series (5.0.x, 4.1.x, 3.2.x) may also be vulnerable but have not been formally evaluated.

Business impact

Organizations relying on Django's cache middleware to prevent sensitive data exposure face elevated risk of information disclosure. Authenticated user data, session information, or other confidential responses could be cached and served to different users or public clients if `Cache-Control` directives are expressed in non-lowercase form. This is particularly concerning in multi-tenant or high-traffic environments where cache reuse is frequent. The actual business impact depends on application design—frameworks or code that consistently use lowercase directives are unaffected, while those with mixed-case headers are vulnerable.

Affected systems

Django 5.2 versions prior to 5.2.15 and Django 6.0 versions prior to 6.0.6 are confirmed vulnerable. Django 5.0.x, 4.1.x, and 3.2.x (no longer in mainstream support) are suspected to be affected but have not been formally assessed by the Django project. Applications using `django.middleware.cache.UpdateCacheMiddleware` are in scope; projects using alternative caching strategies or third-party middleware may not be affected. Verification of exposure requires review of application code and HTTP header usage patterns.

Exploitability

Exploitation requires relatively specific conditions: an attacker must either control response headers returned by the Django application, or interact with an application that generates mixed-case `Cache-Control` headers. The CVSS vector (AV:N/AC:H/PR:N/UI:R) reflects network accessibility but high attack complexity and user interaction requirements, limiting practical exploit scenarios. This is not an actively exploited vulnerability in the wild (KEV status: not listed). Realistic attack paths would involve compromising an upstream service, man-in-the-middle manipulation, or leveraging applications with non-standard header generation.

Remediation

Upgrade Django 5.2 installations to 5.2.15 or later, and Django 6.0 installations to 6.0.6 or later. These versions implement case-insensitive matching for `Cache-Control` directives in compliance with RFC 7231. For unsupported series (5.0.x, 4.1.x, 3.2.x), no official patches are available; migration to a supported release is required. Organizations unable to upgrade immediately should audit application code and response headers to ensure consistent use of lowercase `Cache-Control` directives as a temporary mitigation.

Patch guidance

1. Verify your current Django version: `python -c "import django; print(django.VERSION)"` 2. For Django 5.2: upgrade to 5.2.15 or any subsequent 5.2.x release 3. For Django 6.0: upgrade to 6.0.6 or any subsequent 6.0.x release 4. Test the upgrade in a staging environment before production deployment 5. Consult the official Django security advisory and release notes at djangoproject.com for complete details and any additional changes in these versions 6. If you are on Django 5.0.x, 4.1.x, or 3.2.x (unsupported), plan a migration to Django 5.2 LTS or 6.0 and apply patches immediately upon upgrade

Detection guidance

1. Review application code for use of `django.middleware.cache.UpdateCacheMiddleware`—if not explicitly configured, you are likely using Django's default caching middleware 2. Examine HTTP response headers in your application for `Cache-Control` directives with non-lowercase values (e.g., uppercase or mixed case) 3. Monitor cache hit rates or application logs for anomalous patterns that might indicate sensitive data being served from cache to unintended users 4. Test end-to-end by sending requests with mixed-case `Cache-Control` headers (e.g., `Cache-Control: PRIVATE`) and verify that responses are not cached when they should not be 5. Use web proxy tools (e.g., Burp Suite) to inspect caching behavior and confirm middleware is respecting all `Cache-Control` variants

Why prioritize this

This vulnerability should be patched as routine maintenance, not as an emergency. The CVSS score of 3.1 reflects low severity: exploitation requires attack complexity and user interaction. However, the bug is straightforward to fix, patches are available for all supported Django versions, and the underlying risk—unintended caching of sensitive data—can have serious downstream consequences in certain application designs. Organizations should include this in their next regular Django maintenance window, prioritizing it above optional updates but below critical or high-severity issues.

Risk score, explained

CVSS 3.1 score of 3.1 (Low) is driven by: (1) network attack vector (AV:N)—exploitable over the network; (2) high attack complexity (AC:H)—requires specific conditions or control over response headers; (3) no privileges required (PR:N)—any unauthenticated user can trigger the condition; (4) user interaction required (UI:R)—depends on victim user behavior; (5) low confidentiality impact (C:L)—potential for sensitive data disclosure but not widespread; and (6) no integrity or availability impact (I:N/A:N). The overall score reflects real but constrained risk—the bug is genuine and fixable, not a false positive, but not an immediate threat to most deployments.

Frequently asked questions