CVE-2026-48588: Django Information Disclosure Vulnerability

CVE-2026-48588 Overview

CVE-2026-48588 is an information disclosure vulnerability in Django affecting versions 6.0 before 6.0.7 and 5.2 before 5.2.16. The flaw resides in UpdateCacheMiddleware and the cache_page() decorator, which cache responses that vary on cookies when incoming requests carry unrelated cookies. This behavior allows remote attackers to read private data from the shared cache. Django credits Chris Whyland with reporting the issue. Earlier unsupported Django series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected. The vulnerability is classified under [CWE-524] (Use of Cache Containing Sensitive Information).

Critical Impact
Remote attackers can retrieve cached responses containing private user data by leveraging shared cache entries created when responses vary on cookies.

Affected Products

Django 6.0 before 6.0.7
Django 5.2 before 5.2.16
Earlier unsupported series (5.0.x, 4.1.x, 3.2.x) potentially affected but unevaluated

Discovery Timeline

Vulnerability reported by Chris Whyland to the Django security team
2026-07-07 - Django releases security patches and publishes advisory
2026-07-07 - CVE-2026-48588 published to NVD
2026-07-09 - Last updated in NVD database

Technical Details for CVE-2026-48588

Vulnerability Analysis

The vulnerability affects Django's per-view and site-wide caching layers. When a view declares that its response varies on cookies through the Vary: Cookie header, Django's caching middleware is expected to key cache entries by the specific cookies that influence output. UpdateCacheMiddleware and the cache_page() decorator instead cache responses even when the incoming request carries unrelated cookies that do not affect view output. This leads to cache entries being stored and served under keys that fail to isolate distinct user contexts. As a result, a response generated for one user can be returned to another user whose request produces the same cache key.

Root Cause

The root cause is improper cache key computation for cookie-varying responses. Django's cache logic does not correctly distinguish between cookies that materially affect the response and unrelated cookies present in the request. Sensitive per-user content passes into a shared cache that other requests can retrieve, matching [CWE-524].

Attack Vector

An unauthenticated remote attacker sends HTTP requests to a vulnerable Django application that uses UpdateCacheMiddleware or cache_page() on views returning user-specific content. By manipulating cookies in outgoing requests, the attacker can produce cache lookups that return previously cached responses containing another user's private data. Exploitation requires the target application to cache responses that vary on cookies and requires user interaction to prime the cache with sensitive content.

No verified public proof-of-concept code is available. See the Django Weblog Security Updates for authoritative technical details.

Detection Methods for CVE-2026-48588

Indicators of Compromise

Cache entries in Django backends (Memcached, Redis, database cache) containing user-specific response bodies retrievable without matching session cookies
HTTP responses served from cache that contain personally identifiable information delivered to unauthenticated or unrelated authenticated sessions
Anomalous Vary: Cookie responses returned to requests lacking the expected session or authentication cookies

Detection Strategies

Inventory Django deployments and identify views decorated with cache_page() or protected by UpdateCacheMiddleware that return user-specific data
Audit application logs for cache hits on endpoints returning authenticated content to requests without corresponding session cookies
Review Django version metadata in deployed applications to identify releases prior to 6.0.7 and 5.2.16

Monitoring Recommendations

Instrument cache backends to log key patterns for responses containing sensitive headers such as Set-Cookie or personalization markers
Alert on unexpected Cache-Control behavior where per-user responses appear in shared caches
Track Django release advisories through the Django Security Release Notes and the Django Announcement Group

How to Mitigate CVE-2026-48588

Immediate Actions Required

Upgrade Django to 6.0.7 or 5.2.16 as documented in the Django Weblog Security Updates
Flush shared cache backends after upgrading to purge any tainted cache entries generated by the vulnerable code path
Review all uses of cache_page() and UpdateCacheMiddleware on views that expose user-specific data

Patch Information

The Django project released fixed versions 6.0.7 and 5.2.16 on 2026-07-07. Users of unsupported series (5.0.x, 4.1.x, 3.2.x) should migrate to a supported release, as these branches were not evaluated. Full release details are available in the Django Security Release Notes.

Workarounds

Disable cache_page() and UpdateCacheMiddleware on views that return per-user or authenticated content until the patch is applied
Restrict cached views to responses that do not vary on cookies, removing sensitive data from the cache scope
Configure per-user cache key prefixes based on authenticated identity rather than relying on Vary: Cookie alone

bash

# Configuration example: temporarily bypass caching on sensitive views
# settings.py
MIDDLEWARE = [
    # 'django.middleware.cache.UpdateCacheMiddleware',  # disabled pending patch
    'django.middleware.common.CommonMiddleware',
    # 'django.middleware.cache.FetchFromCacheMiddleware',  # disabled pending patch
]

# views.py - remove cache_page decorator on user-specific endpoints
# @cache_page(60 * 15)
def user_dashboard(request):
    return render(request, 'dashboard.html', {'user': request.user})