Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify CMS page with vary-header plugin
-
DeliverySend request with crafted header value
-
ExploitPrime cache with attacker-chosen variant
-
ExecutionVictim requests same page
-
PersistVictim receives attacker's cached content
-
ImpactCross-user content leakage achieved
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V4 - API and Web Service Acceptance of extraneous untrusted data
|
| Exploitation Conditions | Two non-default conditions must both be true: (1) CMS_PAGE_CACHE must be explicitly enabled in Django settings - it is a configurable CMS option, not enabled by default in all deployment guides; (2) at least one CMS plugin installed on the target page must implement get_vary_cache_on() to declare that its rendered output varies on a specific request header. Without plugin-declared vary headers, the cache key mismatch has no exploitable effect because no header values are ever intended to differentiate cached responses. Exploitation is further limited to pages where such a plugin is placed - a CMS instance with the vulnerable configuration but no affected pages remains unexploitable in practice. No authentication, no user interaction, and no special network position are required once both prerequisites are met. |
| Impact | CVSS 4.8 Medium with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N reflects accurate real-world risk. The AC:H designation is well-justified: exploitation requires CMS_PAGE_CACHE to be explicitly enabled AND at least one installed plugin to implement get_vary_cache_on() - neither condition is universal across django CMS deployments. Where those prerequisites are met, however, PR:N and UI:N mean any unauthenticated network attacker can prime the cache and cause cross-user content leakage without any victim interaction. No EPSS data was provided, and no CISA KEV listing exists, consistent with the configuration-dependency limiting mass exploitation. The dual-nature impact (C:L for reading others' content, I:L for cache poisoning) is real and not inflated. Defenders should treat this as a genuine priority specifically on instances running plugins that vary cache on sensitive headers such as country, language override, or user-tier indicators - and deprioritize it where no such plugins are deployed. |
| Exploit ScenarioDerived | An attacker targeting a django CMS site with CMS_PAGE_CACHE enabled and a country-code-varying plugin sends a GET request to a cacheable page with a crafted Country-Code: ATTACKER header, priming the cache with the response rendered for that header value. A legitimate user from France who subsequently requests the same page receives the attacker's cached variant instead of their own localized content, resulting in both information disclosure (the attacker's chosen content leaks to real users) and content injection (the attacker's input appears in the page). No exploit code is publicly available, but the attack requires only standard HTTP tooling. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 20, 2026
Cache isolation failure in django CMS allows unauthenticated network attackers to both read other users' header-personalized page content and poison the page cache with attacker-chosen content. Affected installations must have CMS_PAGE_CACHE enabled and at least one plugin implementing get_vary_cache_on() - when those conditions hold, the page cache key is computed without the plugin-declared header values, so the first cached variant is served to all subsequent visitors regardless of their headers. No public exploit exists and CISA KEV has not listed this vulnerability, but the attack is mechanically straightforward in affected configurations.
RemediationAI
Upgrade to django CMS 5.0.8 (stable branch) or 5.1.0 (current branch); both releases contain the fix per the tagged GitHub releases at https://github.com/django-cms/django-cms/releases/tag/5.0.8 and https://github.com/django-cms/django-cms/releases/tag/5.1.0. The upstream fix is confirmed via commits 8758714b865ffa79c6bcd0e5c503958ea48885aa and d5dc1efa18d157445491c4b12c2dd1efd56f439f. If immediate upgrade is not feasible, setting CMS_PAGE_CACHE = False in Django settings completely eliminates the vulnerable code path at the cost of increased per-request rendering overhead on page views - acceptable as a short-term compensating control. Alternatively, removing or auditing plugins that implement get_vary_cache_on() neutralizes the vulnerability without disabling caching entirely, but requires enumerating all installed plugins. There is no workaround that preserves both plugin-varied caching and protection against cross-user leakage without the upstream fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in pypi, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is in cms/cache/page.py: the _page_cache_key() function constructed cache keys from prefix, site ID, language, URL path, and timezone but omitted values of request headers that plugins declared via get_vary_cache_on(). Plugins correctly signalled their vary intent - set_page_cache() added those names to the HTTP Vary response header - but get_page_cache() resolved cache hits using the same header-agnostic key, so the first stored variant was returned for all subsequent requests sharing that key, regardless of differing header values. CWE-349 (Acceptance of Extraneous Untrusted Data With Trusted Data) captures the mismatch: the cache write path encoded vary-header awareness into the HTTP response but the cache read path ignored it entirely. The fix mirrors Django's own learn_cache_key/get_cache_key two-step approach: on write, the list of plugin-declared vary headers is persisted under a separate .vary-on key; on read, that list is retrieved first, then a SHA-1 hash of the current request's values for those headers is folded into the content cache key, ensuring each header-value combination maps to a distinct cache entry.
Know when Python gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
AC:H because exploitation requires both CMS_PAGE_CACHE enabled and a vary-header plugin deployed; PR:N since no authentication is needed once those conditions hold; C:L/I:L for cross-user content leakage and cache poisoning respectively; A:N as no availability impact is described.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
1DescriptionCVE.org
django CMS is a content management system powered by Django. Prior to 5.0.8 and in 5.1.0a1, the django CMS page cache in cms/cache/page.py ignores request headers declared by plugins through get_vary_cache_on(). The _page_cache_key function includes the cache prefix, site, language, path, and timezone but not the declared header values. Although set_page_cache adds those names to the response Vary header, get_page_cache retrieves the first stored variant under the same header-agnostic key. When CMS_PAGE_CACHE is enabled and a plugin varies content on a header such as Country-Code, one visitor can receive another visitor’s request-specific content, and an unauthenticated attacker can prime the cache with attacker-chosen content. This issue is fixed in versions 5.0.8 and 5.1.0.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
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
EUVD-2026-63564
GHSA-fwjf-m4qw-9f2x
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB