CVE-2026-35192

What it actually does

Affected Django versions can emit session cookies on responses when `SESSION_SAVE_EVERY_REQUEST` is enabled without correctly marking the response as varying by `Cookie` when the session was not otherwise modified. If a shared cache, CDN, reverse proxy, or intermediary stores such a response, the cached response may include a user's session cookie and later be served to another requester. The result is session credential exposure and potential session hijacking. Exploitation requires a cacheable public page, use of Django sessions, `SESSION_SAVE_EVERY_REQUEST=True`, a victim visiting the cached page, and an attacker later receiving the cached response.

Why it matters to the business

An attacker who receives another user's cached session cookie may be able to access that user's account without knowing their password, potentially exposing personal data, customer records, administrative functions, or other application data available to the victim. The issue is not currently listed in CISA KEV and has low EPSS, but it has been public for 97 days and affects common Django deployment patterns that use shared caching, so internet-facing applications should prioritize review and patching where Django sessions and CDN/reverse-proxy caching are used.

How an attack unfolds

An attacker identifies a Django application using affected versions and shared caching for public or semi-public pages. The application has `SESSION_SAVE_EVERY_REQUEST` enabled, causing Django to refresh or send session cookies even when the session content is not modified. A victim with an active session visits a cacheable page. Because the vulnerable response does not include the correct cookie-varying behavior, an intermediary cache may store the response together with the victim's `Set-Cookie` session value. The attacker then requests the same page and receives the cached response. If the cached response contains the victim's session cookie, the attacker can replay that cookie in subsequent requests and impersonate the victim until the session expires, is rotated, or is invalidated.

How to fix it

Upgrade Django to a fixed release: Django 6.0.5 or later for the 6.0 series, or Django 5.2.14 or later for the 5.2 series. Earlier unsupported Django series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected; migrate unsupported deployments to a supported fixed branch. As mitigation until patching is complete, disable `SESSION_SAVE_EVERY_REQUEST` where it is not strictly required, ensure responses that set session cookies include `Vary: Cookie`, prevent shared caches from storing responses with `Set-Cookie`, configure CDN/reverse-proxy rules to bypass caching for authenticated or session-bearing requests, and purge potentially affected cache entries. Consider rotating session keys or invalidating active sessions if evidence suggests session cookies were cached and served to other users.

How to confirm the fix worked

Confirm the deployed Django version is 6.0.5 or later, or 5.2.14 or later. Review application settings for `SESSION_SAVE_EVERY_REQUEST=True` and inspect cache/CDN rules for any paths that can cache responses containing `Set-Cookie`. Test a representative public page while authenticated and verify that responses setting a session cookie include `Vary: Cookie` and are not stored by shared caches. From an unauthenticated or separate client, request the same URL and confirm the response is not a shared-cache hit containing another user's `Set-Cookie` header. Validate that CDN or reverse-proxy behavior bypasses cache when request cookies are present and does not cache responses with session cookies.

Typical attack path

1. Identify a Django application that uses affected Django versions prior to 6.0.5 or 5.2.14.
2. Find public or cacheable pages served through a CDN, reverse proxy, shared HTTP cache, or application cache.
3. Confirm or infer that Django sessions are enabled and `SESSION_SAVE_EVERY_REQUEST` is set to `True`.
4. Wait for or entice an authenticated victim to visit a cacheable public page.
5. Request the same cached page after the victim's visit.
6. Inspect the cached response for a `Set-Cookie` header containing a Django session cookie such as `sessionid`.
7. Replay the exposed session cookie to access the application as the victim.

How to detect it

Investigate CDN, reverse-proxy, web server, application, and WAF logs for evidence that responses containing session cookies were cached or served from cache. Focus on the period before upgrade or mitigation and on public pages that authenticated users can visit. Look for `Set-Cookie` headers containing the Django session cookie name, commonly `sessionid`, in responses marked as cache hits such as `X-Cache: HIT`, `CF-Cache-Status: HIT`, `Age` headers greater than zero, or reverse-proxy cache-status fields. Compare session cookie values across requests and identify the same session ID appearing from multiple unrelated source IPs, user agents, geographies, or autonomous systems in a short period. Review application authentication logs for a single account/session suddenly changing IP address or user agent without a normal login event. Inspect CDN and proxy configuration history for rules that cache responses with `Set-Cookie` or ignore `Cookie`/`Vary` headers. Also review source code and settings repositories for `SESSION_SAVE_EVERY_REQUEST=True`, especially in services using shared HTTP caching.

• SESSION_SAVE_EVERY_REQUEST = True
• SESSION_SAVE_EVERY_REQUEST=True
• Set-Cookie: sessionid=
• Vary: Cookie
• X-Cache: HIT
• CF-Cache-Status: HIT
• X-Cache-Status: HIT
• X-Proxy-Cache: HIT
• Age:
• Cookie: sessionid=

What your security team should do

• Inventory Django applications and prioritize those exposed to the internet, using CDN/reverse-proxy caching, or serving cacheable public pages.
• Upgrade affected deployments to Django 6.0.5+ or 5.2.14+; migrate unsupported Django branches to a supported fixed release.
• Search code and configuration for `SESSION_SAVE_EVERY_REQUEST=True` and disable it unless there is a clear business requirement.
• Audit CDN, reverse-proxy, and application cache rules to ensure responses with `Set-Cookie` are never stored in shared caches.
• Purge CDN and reverse-proxy caches for affected applications after patching or changing cache policy.
• Review logs for cached responses containing `Set-Cookie` and for the same session cookie being used by different IP addresses or user agents.
• If exposure is confirmed, invalidate affected sessions, force reauthentication, and assess account activity for unauthorized access.