Django CVE-2026-8404

Two specific conditions must both be true for exploitation to be possible. First, the Django application must have django.middleware.cache.UpdateCacheMiddleware active in its MIDDLEWARE setting - this is not enabled by default and must be explicitly configured. Second, at least one response flowing through that middleware must include a Cache-Control header with uppercase or mixed-case directive values (e.g., 'Cache-Control: Private', 'Cache-Control: NO-STORE', 'Cache-Control: No-Cache'). This second condition is the key limiting factor: Django's own HTTP response APIs (HttpResponse, JsonResponse, decorators like @cache_control) emit lowercase values, so the triggering condition most likely originates from third-party packages, manually constructed headers, or reverse-proxy pass-through headers with non-normalized casing. Exploitation is further limited by the need for a prior legitimate user request to populate the cache entry (UI:P) and the confidentiality impact being bounded to whatever that specific cached response contained. Deployments not using UpdateCacheMiddleware are entirely unaffected regardless of Cache-Control header casing.

The CVSS 4.0 vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N yields a score of 2.3, reflecting a network-reachable attack with no required privileges but with two constraining factors: AT:P (specific attack conditions must be present - namely mixed-case Cache-Control headers in responses) and UI:P (passive user interaction, meaning a legitimate user must trigger the incorrectly cached response before an attacker can retrieve it). The confidentiality impact is limited to the vulnerable system (VC:L), with no integrity or availability impact. EPSS data was not provided, so exploitation probability cannot be quantified from that source. KEV status is absent, confirming no known active exploitation. No public POC has been identified. Real-world risk is narrow: it applies only to deployments that actively use UpdateCacheMiddleware and generate responses with non-lowercase Cache-Control directives - not a typical Django pattern. This is a genuine but low-priority finding absent evidence of broader exploitation.

A Django application uses UpdateCacheMiddleware and includes a third-party library or custom view that sets 'Cache-Control: Private' with a capital P. The middleware, failing to match 'Private' against the expected lowercase 'private', stores the response in cache. A second attacker request to the same URL retrieves that cached response, potentially exposing session-specific data - such as a user profile page or partial form data - that was intended to be served only to the original authenticated user.