Is there a patch available for CVE-2026-6907?

Yes, a patch is available for CVE-2026-6907. Update the affected software to the latest version immediately.

Django CVE-2026-6907

Q: What is the CVSS score of CVE-2026-6907?

CVE-2026-6907 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-27382 LOW

Use of Cache Containing Sensitive Information (CWE-524)

2026-05-05 DSF

Python Information Disclosure

2.3

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

2.3 LOW

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Analysis Generated

May 05, 2026 - 16:32 vuln.today

Severity Changed

May 05, 2026 - 16:22 NVD

MEDIUM LOW

CVSS changed

May 05, 2026 - 16:22 NVD

4.3 (MEDIUM) 2.3 (LOW)

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

12 pypi packages depend on django (12 direct, 0 indirect)

Ecosystem-wide dependent count for version 5.2.

DescriptionCVE.org

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. django.middleware.cache.UpdateCacheMiddleware erroneously caches requests where the Vary header contained an asterisk ('*'). This can lead to private data being stored and served. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Ahmad Sadeddin for reporting this issue.

AnalysisAI

Django's UpdateCacheMiddleware incorrectly caches HTTP responses containing a Vary header with an asterisk value in versions 6.0 before 6.0.5 and 5.2 before 5.2.14, causing private user data to be cached and served to other users. The vulnerability has low confidentiality impact and requires user interaction (UI:P) combined with passive attack timing, making real-world exploitation dependent on specific cache timing conditions and application architecture.

Technical ContextAI

The vulnerability resides in Django's UpdateCacheMiddleware component, which implements HTTP caching middleware following RFC 7234 cache control semantics. The Vary header specifies which request headers should be considered when determining cache key equivalence; per RFC 7231, a Vary value of '*' indicates that the response varies based on factors outside standard headers and should never be cached. Django's cache middleware fails to recognize this special case and caches responses marked with Vary: *, treating them as cacheable when they should be skipped. This violates HTTP caching semantics defined in CWE-524 (Incorrect Parsing). The issue affects the middleware layer that sits between the application and the HTTP cache backend, potentially causing sensitive per-user data (session tokens, CSRF tokens, personal information) to be stored in the cache layer and retrieved by subsequent requests from different users.

RemediationAI

Upgrade Django to version 6.0.5 or later for 6.0.x deployments, or version 5.2.14 or later for 5.2.x deployments. The vendor has released patched versions available at https://www.djangoproject.com/weblog/2026/may/05/security-releases/. For deployments unable to upgrade immediately, implement cache exclusion rules at the middleware level: configure the cache middleware to skip caching for responses with a Vary header containing '*' by creating a custom middleware wrapper that inspects the Vary header before UpdateCacheMiddleware processes the response, or disable UpdateCacheMiddleware entirely and use a reverse proxy cache (nginx, Varnish) with proper HTTP semantic handling. Alternative compensating control: restrict access to Django's cache backend at the network level and ensure authentication tokens are marked with Cache-Control: private, though this does not address responses already marked with Vary: *. Unsupported versions (5.0.x, 4.1.x, 3.2.x) should prioritize upgrading to a supported series, as backports are not available.