CVE-2026-48588: 
Django vulnerability analysis and mitigation

CVE-2026-48588 is an information disclosure vulnerability in Django's caching layer, where UpdateCacheMiddleware and the cache_page() decorator incorrectly cache responses that vary on cookies when the incoming request carries unrelated cookies. This allows remote, unauthenticated attackers to read private data — including session or other sensitive Set-Cookie headers — from the shared cache. The vulnerability affects Django 6.0 before 6.0.7 and Django 5.2 before 5.2.16; earlier unsupported series (5.0.x, 4.1.x, 3.2.x) were not formally evaluated but may also be affected. It was reported by Chris Whyland and disclosed on July 7, 2026. The CVSS v3.1 base score is 5.3 (Medium); the CVSS v4.0 base score is 2.3 (Low) (GitHub Advisory, Django Security Blog, Red Hat Bugzilla).

The root cause is classified as CWE-524 (Use of Cache Containing Sensitive Information), mapped to CAPEC-204 (Lifting Sensitive Data Embedded in Cache). Django's UpdateCacheMiddleware and cache_page() decorator are designed to skip caching responses that set cookies, but they fail to do so when the incoming request already carries an unrelated cookie — causing responses containing sensitive Set-Cookie headers (e.g., session cookies) to be stored in the shared cache. An unauthenticated attacker can then retrieve these cached responses over the network without any privileges, as long as the attack requirements (a legitimate user having previously triggered the cached response with cookies) are met. The fix is tracked in Django's changeset d8d6a32d3783499b0eb5204ae5dd00d02449be37 (Django Changeset, GitHub Advisory).

Successful exploitation results in unauthorized disclosure of private user data stored in Django's shared cache, including session tokens and other sensitive Set-Cookie response headers. An unauthenticated remote attacker could read another user's session data, potentially enabling session hijacking and unauthorized account access. There is no integrity or availability impact; the vulnerability is limited to confidentiality loss (Red Hat Bugzilla, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory). The EPSS score is approximately 0.378%, placing it in the 30th percentile for exploitation likelihood within 30 days. The NVD SSVC assessment classifies exploitation as "none" and the vulnerability as non-automatable. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify Django-based web applications using versions 5.2.x before 5.2.16 or 6.0.x before 6.0.7 that use UpdateCacheMiddleware or the cache_page() decorator with a shared cache backend (e.g., Memcached, Redis).
2. Trigger cached response: Wait for or induce a legitimate authenticated user to make a request to a cached endpoint while carrying cookies (e.g., a session cookie). Due to the bug, Django caches the response including any Set-Cookie headers.
3. Send crafted request: As an unauthenticated attacker, send an HTTP request to the same cached endpoint, including an unrelated cookie in the request headers. This causes Django to serve the previously cached response — which may contain another user's Set-Cookie data — from the shared cache.
4. Extract sensitive data: Parse the response headers to extract session tokens or other sensitive cookie values belonging to the victim user.
5. Session hijacking: Use the extracted session cookie to impersonate the victim user in subsequent authenticated requests to the application (GitHub Advisory, Django Security Blog).

• Network: Unusual HTTP requests to cached endpoints from unauthenticated clients that include arbitrary or unrelated cookie headers; repeated requests to the same cached URL from different source IPs in rapid succession.
• Logs: Django access logs showing requests to cache_page()-decorated views from clients with unexpected cookie headers receiving 200 OK responses with Set-Cookie headers belonging to other sessions; cache backend logs showing high read rates for specific cache keys.
• Application: Evidence of session fixation or account takeover — multiple sessions active for the same user account from geographically disparate IPs; unexpected authenticated actions performed shortly after a cache read event.

Upgrade Django to version 5.2.16 (for the 5.2.x series) or 6.0.7 (for the 6.0.x series), which contain the official fix (Django Security Blog). Users of unsupported versions (5.0.x, 4.1.x, 3.2.x) should evaluate their exposure and upgrade to a supported, patched release. As an interim workaround where upgrading is not immediately possible, consider disabling UpdateCacheMiddleware and cache_page() on endpoints that set cookies, or switching to per-user cache backends (e.g., using cache_control(private=True)) to prevent shared caching of sensitive responses. SUSE and openSUSE have also released updated packages for their distributions (SUSE Advisory).

The Django project publicly acknowledged the issue in its July 7, 2026 security release blog post, crediting Chris Whyland for responsible disclosure (Django Security Blog). The vulnerability was discussed on the oss-security mailing list shortly after disclosure (oss-sec). Red Hat opened a tracking bug and assigned it low severity, with a broad CC list indicating awareness across multiple product teams (Red Hat Bugzilla). Downstream Linux distributions including SUSE, openSUSE, and Fedora issued updated packages within days of the disclosure.