medium
CVE
CVE-2026-6907
CWE
CWE-524
Affected Surface
Django 6.0 before 6.0.5, Django 5.2 before 5.2.14, Django applications using UpdateCacheMiddleware
Django’s cache middleware is designed to avoid storing responses that are not safe to reuse. CVE-2026-6907 is a subtle failure in that boundary, reported by Corgea researcher Ahmad Sadeddin: django.middleware.cache.UpdateCacheMiddleware previously cached responses even when the response carried Vary: *. For broader framework hardening guidance, see our Django security best practices.
That header value is special. It tells shared caches that the response varies on factors that cannot be expressed as normal request headers, so the response should not be reused for another request. If application code generated a private response with Vary: *, affected Django versions could still store it and later serve it from cache.
Impact
The core risk is private data exposure through a shared cache. Affected applications are most exposed when all of these conditions are true:
- Django’s site-wide cache middleware is enabled.
- A view can return user-specific or otherwise sensitive content.
- That response contains
Vary: *. - The cached response can be reached by another user or request context.
The Django Software Foundation rates the issue as low severity under its security policy, while the CNA CVSS v3.1 score is 4.3 Medium for low-confidentiality impact. The practical severity depends on what the affected view places in the response body and how broadly the cache is shared.
Affected versions
The supported affected releases are Django 6.0 before 6.0.5 and Django 5.2 before 5.2.14. Django’s advisory also notes that older unsupported series, including examples such as 5.0.x, 4.1.x, and 3.2.x, were not evaluated and may also be affected.
Remediation
Upgrade Django to a fixed release:
- Django 6.0 users should upgrade to 6.0.5 or later.
- Django 5.2 users should upgrade to 5.2.14 or later.
- Teams on unsupported Django series should move to a supported fixed release instead of relying on unevaluated legacy behavior.
After upgrading, review any endpoints that combine user-specific responses with cache middleware. Confirm sensitive pages use explicit cache controls such as Cache-Control: private or Cache-Control: no-store where appropriate, and avoid depending on Vary: * as the only guard against shared cache reuse.
Detection and response
Start by searching code and response middleware for Vary: *, patch_vary_headers(..., ["*"]), and any custom cache-control logic around authenticated views. If a sensitive endpoint could have emitted Vary: * while site-wide caching was enabled, rotate any exposed session-adjacent data as appropriate and invalidate the shared cache after deploying the fixed Django release. Teams can pair this review with Corgea AI SAST to catch vulnerable framework patterns during code review.
For production services, pair this review with access-log analysis for repeated cache hits on authenticated or personalized routes. The highest-signal indicator is the same cached response body or cache key being served across distinct users or sessions.