Django Session Cookie Leak <6.0.5/5.2.14
CVE-2026-35192 Published on May 5, 2026

Session fixation via public cached pages and SESSION_SAVE_EVERY_REQUEST
An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. Response headers do not vary on cookies if a session is not modified, but `SESSION_SAVE_EVERY_REQUEST` is `True`. A remote attacker can steal a user's session after that user visits a cached public page. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Cantina for reporting this issue.

Vendor Advisory Vendor Advisory NVD

Timeline

Initial report received.

Vulnerability confirmed. 21 days later.

Security release issued. 34 days later.

Weakness Type

Use of Persistent Cookies Containing Sensitive Information

The web application uses persistent cookies, but the cookies contain sensitive information. Cookies are small bits of data that are sent by the web application but stored locally in the browser. This lets the application use the cookie to pass information between pages and store variable information. The web application controls what information is stored in a cookie and how it is used. Typical types of information stored in cookies are session identifiers, personalization and customization information, and in rare cases even usernames to enable automated logins. There are two different types of cookies: session cookies and persistent cookies. Session cookies just live in the browser's memory and are not stored anywhere, but persistent cookies are stored on the browser's hard drive. This can cause security and privacy issues depending on the information stored in the cookie and how it is accessed.


Products Associated with CVE-2026-35192

stack.watch emails you whenever new vulnerabilities are published in Django Project Django or Canonical Ubuntu Linux. Just hit a watch button to start following.

 
 

Affected Versions

djangoproject Django: