EUVD-2026-34089
GHSA-qpc8-7fxc-cm4p
Severity by source
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
Lifecycle Timeline
2Blast Radius
ecosystem impact- 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 Django 5.2 before 5.2.15 and 6.0 before 6.0.6. django.middleware.cache.UpdateCacheMiddleware in Django does not add Authorization to the Vary response header for requests bearing that header without Cache-Control: public, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL. 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 Shai Berger for reporting this issue.
AnalysisAI
Cache information disclosure in Django 5.2.x and 6.0.x allows remote unauthenticated attackers to read private authenticated responses served from shared caching layers. The UpdateCacheMiddleware component omits Authorization from the Vary response header when authenticated requests lack an explicit Cache-Control: public directive, causing caches to serve authenticated users' responses to subsequent unauthenticated requestors at the same URL. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects meaningful - but constrained - real-world impact gated behind specific deployment prerequisites.
Technical ContextAI
The vulnerability resides in django.middleware.cache.UpdateCacheMiddleware, part of Django's built-in caching framework. The HTTP Vary response header instructs shared caches - reverse proxies, CDNs, Varnish, nginx caching - to maintain distinct cache entries for requests that differ in the specified request headers. For resources served conditionally based on authentication, including Authorization in Vary ensures cache keys differentiate between authenticated and unauthenticated requests. CWE-524 (Use of Cache Containing Sensitive Information) precisely characterizes this class of flaw: sensitive data is committed to a shared cache without adequate key differentiation, enabling cross-user data leakage. The defect is specifically triggered when a request carries an Authorization header but does not include Cache-Control: public; in that path, Django's middleware omits Authorization from the outgoing Vary header. Affected CPE-identified products are Django 5.2.0 through 5.2.14 and 6.0.0 through 6.0.5. Earlier series including 5.0.x, 4.1.x, and 3.2.x were not evaluated by the Django project and may also carry this defect.
RemediationAI
Upgrade to Django 5.2.15 or Django 6.0.6, the patched releases identified in the vendor security advisory at https://www.djangoproject.com/weblog/2026/jun/03/security-releases/ and indexed at https://docs.djangoproject.com/en/dev/releases/security/. Where immediate upgrade is not feasible, remove django.middleware.cache.UpdateCacheMiddleware (and its companion FetchFromCacheMiddleware) from the middleware stack entirely; this eliminates the vulnerability at the cost of Django-level response caching, which may increase backend load and must be evaluated for production impact. A more targeted compensating control is to add Cache-Control: no-store or Cache-Control: private to all responses serving authenticated content - this prevents caching of those responses by intermediary layers without disabling caching globally, though it requires careful auditing to ensure all sensitive endpoints are covered. Organizations relying on unsupported Django versions (5.0.x, 4.1.x, 3.2.x) should treat those branches as potentially affected and prioritize migration to a supported release.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today