Race condition can undo logout with cache/file session backends

[Shai Berger]

Django’s cache and file session backends can resurrect a session that was deleted by logout under a narrow but concrete concurrent-request race.

The vulnerable interleaving occurs when an authenticated same-session request has already reached SessionMiddleware.process_response() and the backend save() path has checked that the old session still exists. If /logout/ deletes that same session before the backend performs its final write, the cache/file backend can write the old session key again. SessionMiddleware then raises no SessionInterrupted and sends Set-Cookie for the old sessionid.

This can restore authenticated session data after logout if the late response is applied as the browser’s final cookie state.

The "signed_cookie", "db" and "cached_db" session backends are not affected.

Root Cause

The DB session backend updates an existing row using force_update=True. If logout deletes the row before a late save, the update fails and Django
raises UpdateError, which SessionMiddleware converts to SessionInterrupted.

The cache and file backends use a check-then-write pattern instead:

• Cache backend checks existence with cache.get() and then writes with cache.set().
• File backend checks that the target file exists, then writes a temporary file and moves it into the target path.

Those final writes are not atomically tied to the existence check. If logout deletes the same session after the check but before the final write,
the old key/path is recreated instead of failing.

Failure Scenario

A user has an authenticated session, and two same-session requests are in flight concurrently. This can occur through multiple tabs, background requests, delayed form submissions, beacons/fetches, or application endpoints that modify session state around the same time as logout.

The problematic interleaving is:

1. Request A modifies the session and reaches SessionMiddleware.process_response().
2. Request A’s backend save() path confirms the old session still exists.
3. Request B calls /logout/ and deletes the same session.
4. Request A performs its final backend write and recreates the old session key.
5. Request A’s late response sends Set-Cookie: sessionid=<old key>.
6. If the browser applies Request A’s response after logout, a later /whoami/ request is authenticated again.

This requires a concurrent same-session request and the narrow save-window interleaving.

Important Non-Claim

The simpler flow below was tested and is not sufficient:

1. /slow-save/ pauses inside the view.
2. /logout/ deletes the session.
3. /slow-save/ later finalizes.

In that ordering, cache/file/db/cached_db correctly raise SessionInterrupted
or otherwise do not restore authentication.

Credit

This, including the attached test script, was reported to the Security Team by Jaeyoung Jang (@BORAMAE). In the ticket, some edits were made to the original report.

[Shai Berger]

The attached reproduction script builds a minimal Django app with real auth/session middleware and three endpoints:

• /slow-save/: requires authentication, reads and modifies request.session.
• /logout/: calls django.contrib.auth.logout(request).
• /whoami/: returns authentication state and current session key.

For the positive cache/file tests, the script deterministically pauses the backend between the existence check and final write, calls /logout/, then releases the late save.

Run command:

cd /path/to/file
python session_resurrection_race_repro.py

Expected result:

logout_deleted_cookie: true
exists_after_logout: false
exists_after_slow: true
slow_set_cookie_same_old_key: true
/whoami/ returns authenticated: true