CVE-2026-48588

What it actually does

Django's page caching logic can incorrectly store and serve responses that vary based on cookies when a request includes unrelated cookies. In affected versions, `UpdateCacheMiddleware` and the `cache_page()` decorator may place a user-specific response into a shared cache entry that can later be returned to another unauthenticated or different user. The flaw is a network-accessible information disclosure issue requiring an attacker to influence cache state and then retrieve the cached response under the right conditions; it does not directly allow code execution or data modification.

Why it matters to the business

Applications using Django page caching on pages that include user-specific or private content may expose sensitive information such as account details, session-adjacent data, personalized pages, or business records to other users. The operational risk is highest for internet-facing Django applications that cache authenticated or semi-personalized responses through shared caches, reverse proxies, CDNs, or application-level cache backends. Although the published severity is low and there is no known KEV listing or public exploit maturity reported, the issue affects a widely used web framework and should be remediated during the next prioritized maintenance window, sooner for applications caching private pages.

How an attack unfolds

An attacker identifies a Django endpoint protected by `UpdateCacheMiddleware` or `cache_page()` where the response can vary depending on cookies and where the response may contain private or user-specific data. The attacker sends a crafted request carrying cookies that are unrelated to the cached response logic but still influence how Django handles the cache variation. Due to the vulnerable caching behavior, Django may store a response in a shared cache under a key that is not sufficiently separated from other users' requests. The attacker then makes follow-up requests, or waits for another user's response to be cached under a reusable key, and retrieves a cached response that was intended for a different user. Successful exploitation depends on the application caching sensitive responses, the presence of cookie-varying behavior, and cache key reuse conditions.

How to fix it

Upgrade affected Django versions to a fixed release: Django 6.0 users should upgrade to 6.0.7 or later, and Django 5.2 users should upgrade to 5.2.16 or later. If running an unsupported Django series such as 5.0.x, 4.1.x, 3.2.x, or older, move to a supported fixed branch because those versions were not evaluated and may also be affected. As mitigations until patching is complete, avoid using `UpdateCacheMiddleware` or `cache_page()` on views that return user-specific, authenticated, cookie-dependent, or sensitive content; add explicit `Cache-Control: private, no-store` or equivalent headers for private responses; ensure reverse proxies and CDNs respect `Vary: Cookie`; and purge shared caches after deploying the fix to remove any incorrectly cached private responses.

How to confirm the fix worked

Confirm the deployed Django package version is 6.0.7 or later for the 6.0 branch, or 5.2.16 or later for the 5.2 branch. Review application code and configuration for use of `UpdateCacheMiddleware`, `cache_page()`, shared cache backends, reverse proxies, and CDN caching on endpoints that depend on cookies or authentication state. Test representative sensitive endpoints by issuing requests with different Cookie headers and verifying that responses are not shared across users or sessions. After remediation, purge application caches, CDN objects, and reverse proxy caches, then repeat cross-cookie cache isolation tests to ensure user-specific content is no longer served from a shared cache entry.

Typical attack path

1. Discover a Django application endpoint that appears cacheable and returns personalized or sensitive content.
2. Send requests with unrelated or manipulated Cookie headers to influence cache behavior.
3. Cause Django's page cache middleware or `cache_page()` decorator to store a response that varies on cookies in a shared cache entry.
4. Request the same or similar endpoint without the original user's context or with a different cookie set.
5. Receive a cached response containing information intended for another user or request context.

How to detect it

There is no universal exploit string for this vulnerability because exploitation uses normal HTTP requests and depends on application-specific cached endpoints. To assess whether exploitation may already have occurred, review web server, application, CDN, reverse-proxy, and cache logs for sensitive or authenticated URLs that were served as cache hits to different clients, sessions, or users. Focus on requests containing Cookie headers to endpoints that should not be publicly cacheable, especially where responses included `Vary: Cookie`, `Set-Cookie`, personalized content, or authenticated page templates. Look for repeated probing of the same URL with different Cookie header values, unusual cache HIT responses for authenticated pages, cache entries created after requests with unrelated cookies, and subsequent access to the same cached object from unrelated IPs or user agents. If available, compare cache keys, request cookies, response headers, and user/session identifiers in application logs to identify cross-user response reuse. Also inspect CDN and reverse-proxy cache analytics for private paths with unexpectedly high hit ratios or hits from unauthenticated traffic.

What your security team should do

• Inventory Django applications and identify versions below 6.0.7 on the 6.0 branch or below 5.2.16 on the 5.2 branch.
• Prioritize internet-facing applications and any application using `UpdateCacheMiddleware`, `cache_page()`, shared cache backends, CDNs, or reverse proxies.
• Upgrade to Django 6.0.7 or 5.2.16 or later; migrate unsupported Django branches to a supported fixed release.
• Review cached views and remove caching from authenticated, personalized, or sensitive responses unless cache keys are explicitly user-safe.
• Purge application, CDN, and reverse-proxy caches after patching to remove potentially exposed cached responses.
• Add regression tests that verify responses varying by cookie or authentication state are not shared between users.
• Monitor access logs for unusual cache-hit patterns, repeated requests with varied Cookie headers, and access to personalized pages from unauthenticated or unexpected clients.