Live › vulnerability › CVE-2026-113593
Django's cache middleware and cache_page decorator build the same cache key for a request that omits a Vary header and one that sends that header empty. A remote attacker can therefore be served private data cached for a different request.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 16:21 UTC. All times on this page are UTC.
Sites built on Django that use the site-wide cache middleware or the cache_page decorator with responses that vary on a request header. Earlier unsupported Django series (5.1, 5.0, 4.2) were not evaluated and may also be affected. Projects that do not use Django's page caching can skip it.
No product ranges from the sources yet.
python -m django --version on each Django install, compare against the fixed rangesUpdateCacheMiddleware or cache_page in the project settings and views, and check whether responses vary on a header6.1.3 or later6.0.10 or later5.2.19 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
An issue was discovered in Django 6.1 before 6.1.3, 6.0 before 6.0.10, and 5.2 before 5.2.19.
The django.middleware.cache.UpdateCacheMiddleware and the django.views.decorators.cache.cache_page() decorator generate identical cache keys for requests that omit a header listed in the response’s Vary header and requests that include that header with an empty value, potentially allowing remote attackers to access private data cached for another request.
Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected.
Django would like to thank Andrew Gonzalez for reporting this issue.
This page as .md · .json · in your agent: get_signal("CVE-2026-113593")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.