Django CVE-2026-35192

The vulnerability requires SESSION_SAVE_EVERY_REQUEST to be explicitly set to True in Django settings (non-default configuration). Additionally, the target page must be cached by an HTTP cache layer (CDN, reverse proxy, or browser cache) that does not properly validate or respect HTTP Vary headers, or the cache must be deliberately configured to ignore cookie-based cache differentiation. The victim must visit a cached public page (no authentication required to access the page itself), and the attacker must have prior knowledge of or ability to seed the cache with a response containing their session cookie. Standard Django configurations with SESSION_SAVE_EVERY_REQUEST=False (the default) are not vulnerable because Django emits proper Vary headers, preventing inappropriate cache reuse.

Despite the low CVSS score of 2.3, this vulnerability carries meaningful real-world risk in specific deployment scenarios. The CVSS vector indicates network-based attack (AV:N) with low complexity (AC:L) but requires user interaction (UI:P) and attack prerequisites (AT:P), limiting the baseline severity. However, EPSS and exploitation probability are not provided in the input data, preventing direct comparison of theoretical versus practical risk. The vulnerability does NOT require authentication (PR:N) and affects confidentiality (VC:L - partial session disclosure), but impact is low and requires precise conditions: the victim must visit a cached public page while SESSION_SAVE_EVERY_REQUEST is enabled and the cache is configured to serve the poisoned response. Organizations using aggressive caching strategies (CDNs, reverse proxies with cache-everything rules) combined with Django's per-request session handling face elevated risk; those using default Django session behavior or disabling SESSION_SAVE_EVERY_REQUEST are largely unaffected. The attack chain is feasible but not trivial - it requires cache manipulation or a misconfigured caching layer that violates HTTP semantics. This is a real priority for high-traffic public sites with session handling, but not a critical emergency for standard deployments. No KEV status or POC availability is documented in the input, so active exploitation cannot be confirmed.

An attacker identifies a public page cached by a CDN or reverse proxy on a Django application with SESSION_SAVE_EVERY_REQUEST enabled. The attacker visits the page while authenticated, receiving a response containing their session cookie but missing the Vary header that would prevent caching. A second user visits the same page and receives the cached response that still includes the first user's session cookie due to improper cache semantics. If the caching layer serves this poisoned response, the second user's browser or subsequent requests inherit the attacker's session, allowing the attacker to hijack the authenticated session.