Django CVE-2026-48588

Three specific conditions must all be present: (1) the application must use Django's UpdateCacheMiddleware or apply the cache_page() decorator to a view, (2) those cached responses must vary on cookies, meaning they contain or are influenced by cookie-based user state and the Vary: Cookie header is in play, and (3) the cache backend must be a shared store (e.g., Memcached or Redis) accessible across multiple users or sessions rather than a per-user local-memory cache. Exploitation is also limited by the requirement that a legitimate user must have already populated the cache entry (UI:P in CVSS 4.0 terms). Applications that do not use Django's caching middleware or cache_page(), that use only anonymous/public caching, or that use per-user cache isolation are not affected. Authentication requirements are not applicable to the attacker - the CVSS vector PR:N indicates no privileges are needed to send the crafted request.

The CVSS 4.0 score of 2.3 is low primarily because of AT:P (specific attack requirements present) and UI:P (a victim user must have populated the cache first). The attack is only exploitable when all three conditions converge: the application uses UpdateCacheMiddleware or cache_page(), responses bear cookie-based Vary headers, and a shared cache backend (e.g., Memcached, Redis shared across users) is in use. Without these conditions the vulnerability is inert. EPSS data was not provided, so exploitation probability cannot be quantified beyond the structural signals. No KEV listing and no POC code are reported, consistent with the low score. Despite the low score, the real-world consequence when conditions are met is meaningful: an unauthenticated remote attacker can read private, personalized data (session content, user-specific API responses) intended for authenticated users. The risk is therefore highly deployment-dependent: Django applications serving only public, non-personalized content through caching are unaffected, while those caching authenticated or cookie-personalized responses on a shared backend face a genuine confidentiality breach.

An attacker browses a Django application that caches authenticated user dashboard responses on a shared Memcached instance. A legitimate user makes a request that populates the cache with their private account data. The attacker then issues a crafted request carrying an arbitrary, unrelated cookie value - such as a tracking pixel cookie injected from a third-party site - which incorrectly matches the cache key and returns the legitimate user's private cached response. No POC code is publicly identified at time of analysis.