CVE-2026-35192: Django Information Disclosure Vulnerability

CVE-2026-35192 Overview

CVE-2026-35192 is a session disclosure vulnerability in the Django web framework. The flaw affects Django 6.0 before 6.0.5 and Django 5.2 before 5.2.14. When the SESSION_SAVE_EVERY_REQUEST setting is True, response headers do not vary on cookies if a session is unmodified. This caching behavior allows a remote attacker to capture another user's session cookie from a cached public page. Earlier unsupported Django releases such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected. The issue is tracked under [CWE-539: Use of Persistent Cookies Containing Sensitive Information].

Critical Impact

Attackers can hijack authenticated user sessions by retrieving cached responses that contain another user's session cookie.

Affected Products

• Django 6.0 versions prior to 6.0.5
• Django 5.2 versions prior to 5.2.14
• Unsupported Django series including 5.0.x, 4.1.x, and 3.2.x (not evaluated)

Discovery Timeline

• 2026-05-05 - Django releases security advisory crediting Cantina for reporting the issue
• 2026-05-05 - CVE-2026-35192 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-35192

Vulnerability Analysis

The vulnerability stems from incorrect HTTP Vary header handling in Django's session middleware. When SESSION_SAVE_EVERY_REQUEST is enabled, Django re-saves the session on every request to refresh expiry timestamps. However, if the session content itself is not modified during a request, Django fails to mark the response as varying on the Cookie header. Downstream caches such as reverse proxies, content delivery networks, or Django's own cache middleware may then store the response, including any Set-Cookie headers. A subsequent unauthenticated visitor requesting the same public URL receives the cached response, which contains the original user's session cookie. The attacker replays this cookie to impersonate the victim.

Root Cause

The defect lies in the conditional logic that decides whether to add a Vary: Cookie header to outgoing responses. The middleware only triggered the Vary annotation when the session was modified, ignoring the case where SESSION_SAVE_EVERY_REQUEST=True causes a Set-Cookie header to be emitted regardless of modification state. See the Django Security Release Notes for details.

Attack Vector

Exploitation requires a deployment that caches public pages and a victim user who is authenticated and visits one of those pages. After the victim's response is stored in the shared cache, the attacker requests the same URL and receives the cached Set-Cookie header containing the victim's sessionid. The attacker then submits this cookie to authenticated endpoints. The attack vector is network-based and requires user interaction from the victim, but no privileges or authentication on the attacker's side. Refer to the Django Weblog Security Releases for vendor analysis.

Detection Methods for CVE-2026-35192

Indicators of Compromise

• Multiple distinct client IP addresses reusing the same sessionid cookie value within a short window
• Cached HTTP responses for public URLs containing Set-Cookie: sessionid=... headers without an accompanying Vary: Cookie header
• Authenticated activity originating from geographic locations or user agents inconsistent with the legitimate session owner

Detection Strategies

• Audit cache server logs and CDN configurations for cached responses that include Set-Cookie headers
• Inventory Django deployments and identify any with SESSION_SAVE_EVERY_REQUEST = True combined with upstream caching
• Correlate session identifiers against client fingerprints in application logs to surface session reuse anomalies

Monitoring Recommendations

• Alert on session cookies appearing in responses served from cache hit paths
• Track session-to-IP binding deviations and flag rapid IP changes for the same session token
• Continuously verify that Django middleware emits Vary: Cookie on responses that include session cookies

How to Mitigate CVE-2026-35192

Immediate Actions Required

• Upgrade Django to 6.0.5 or 5.2.14 immediately on all affected hosts
• Invalidate existing sessions and force users to re-authenticate after patching
• Purge any shared HTTP caches and CDN edge caches that may contain leaked Set-Cookie headers

Patch Information

The Django project released fixed versions 6.0.5 and 5.2.14 on May 5, 2026. The patches restore the Vary: Cookie header on responses where a session cookie may be set, preventing shared caches from storing personalized responses. Installation details are available in the Django Security Release Notes and the Django Weblog Security Releases.

Workarounds

• Set SESSION_SAVE_EVERY_REQUEST = False if session expiry refresh on every request is not strictly required
• Configure upstream caches and CDNs to strip Set-Cookie headers from cached responses or to bypass cache for responses containing session cookies
• Apply explicit @vary_on_cookie or cache_control(private=True) decorators on views that may set session cookies

# Configuration example: pip upgrade and Django settings hardening
pip install --upgrade "Django>=5.2.14,<6.0" # or "Django>=6.0.5"

# settings.py - reduce exposure if patching is delayed
SESSION_SAVE_EVERY_REQUEST = False
CACHE_MIDDLEWARE_KEY_PREFIX = "public_only"