Listen to this Post
The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response `Vary` header, but the CMS’s own cache key does not incorporate the header values, so the first visitor’s variant is served to all subsequent visitors regardless of their header values.
The `_page_cache_key` function (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. `set_page_cache` collects the plugin-declared vary headers and calls `patch_vary_headers(response, …)` (affecting only the emitted `Vary` header), but stores and retrieves the cached page under the header-agnostic key. `get_page_cache` therefore returns whichever variant was cached first.
When a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users. An unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors. This applies only when `CMS_PAGE_CACHE` is enabled and at least one plugin implements get_vary_cache_on().
The vulnerability was fixed in version 5.0.8: the page cache now folds the request’s values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django’s learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit. Workarounds include disabling `CMS_PAGE_CACHE` or avoiding plugins that rely on `get_vary_cache_on()` until upgraded. The vulnerability was reported by the security team at the University of Sydney.
DailyCVE Form:
Platform: django CMS
Version: < 5.0.8
Vulnerability: Cache Poisoning
Severity: Medium (CVSS 4.8)
Date: 2026-08-24
Prediction: 2026-06-10 (Patch released)
What Undercode Say:
Check django CMS version pip show django-cms Check if CMS_PAGE_CACHE is enabled in settings.py grep -r "CMS_PAGE_CACHE" . Check for plugins implementing get_vary_cache_on grep -r "get_vary_cache_on" .
Exploit: (Educational Purposes!)
An attacker can send a request with a manipulated header (e.g., Country-Code: attacker_value) to a page that uses a plugin varying on that header. The CMS caches the response under a key that does not include the header, so all subsequent visitors receive the attacker’s variant until the cache expires.
Protection:
Upgrade to django CMS version 5.0.8 or later. As a temporary workaround, disable `CMS_PAGE_CACHE` by setting `CMS_PAGE_CACHE = False` in settings.py, or avoid using plugins that implement get_vary_cache_on().
Impact:
- Information disclosure: request-specific content is leaked across users.
- Cache poisoning: an attacker can poison the cache with malicious content served to all visitors.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
