---
id: "CVE-2026-113593"
kind: "vulnerability"
aliases: ["CVE-2026-113593"]
title: "Django: cache keys collide, letting one request read another's cached private data"
severity: "low"
cvss: 3.1
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["django", "package", "python", "self-hosted"]
not_affected_if: ["no-page-caching", "static-export"]
published_at: "2026-11-03T16:17:19+00:00"
first_seen_at: "2026-11-03T16:21:42+00:00"
updated_at: "2026-11-03T16:24:26+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113593", "first_seen_at": "2026-11-03T16:21:42+00:00"}]
---

# Django: cache keys collide, letting one request read another's cached private data

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, check and fix written by a model from the sources; labelled as such._

## How to check

- `python -m django --version` on each Django install, compare against the fixed ranges
- Look for `UpdateCacheMiddleware` or `cache_page` in the project settings and views, and check whether responses vary on a header

## Fix

- Django 6.1: upgrade to `6.1.3` or later
- Django 6.0: upgrade to `6.0.10` or later
- Django 5.2: upgrade to `5.2.19` or later

## Timeline

- 2026-11-03T16:21:42+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-113593

## Documents

- [fix] Patch: github.com https://github.com/django/django/commit/2006a2b068766bf332f1afcc32b7614d8e5759a2
- [fix] Patch: github.com https://github.com/django/django/commit/55e2e009b4f3996e5c55af7b22a8c41eb826e892
- [fix] Patch: github.com https://github.com/django/django/commit/9007fecd3633cfd90b093ebe106af564347c8aee
- [fix] Patch: github.com https://github.com/django/django/commit/c0b7e5e4e4546e8ddc58262f1945938bb9d9ac2d

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_