CVE-2026-54625 in Django CMS
Summary
by MITRE • 08/20/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified within django CMS prior to version 5.0.8 and present in version 5.1.0a1 represents a critical flaw in the application's page caching mechanism, specifically located in the cms/cache/page.py module. This issue stems from an inconsistency between how cache keys are generated for storage versus how they are retrieved during subsequent requests. The core technical failure lies within the _page_cache_key function, which constructs the unique identifier used to store and retrieve cached content. While this function correctly incorporates static contextual elements such as the cache prefix, site ID, language code, URL path, and timezone settings into the key generation process, it completely neglects dynamic request headers that plugins may declare via the get_vary_cache_on() method. This omission creates a scenario where distinct requests with different header values are mapped to identical cache keys, leading to data leakage across user sessions.
The operational impact of this flaw is significant for any deployment utilizing django CMS's built-in page caching feature, which is enabled by default in many production environments through the CMS_PAGE_CACHE setting. When a plugin declares that its output varies based on specific HTTP headers, such as Country-Code or Accept-Language, the system correctly appends these header names to the response Vary header. This signals intermediate caches and browsers that different content variants exist for those inputs. However, because django CMS's internal cache retrieval logic ignores these declared headers when generating the lookup key, it retrieves the first stored variant associated with the generic path rather than the specific variant corresponding to the current request's headers. Consequently, one visitor may inadvertently receive cached content intended for another user who previously accessed the same page under different header conditions.
This behavior facilitates a cache poisoning attack vector where an unauthenticated attacker can prime the cache with malicious or sensitive content tailored to their own environment. By crafting requests that trigger specific caching behaviors and then observing subsequent responses from other users, an attacker can effectively serve personalized data, such as user-specific greetings, localized pricing, or even session-dependent information if exposed by plugins. This constitutes a severe breach of confidentiality and integrity for end-users interacting with the platform. The flaw aligns with CWE-524, which categorizes this type of issue under Cache Injection vulnerabilities where an attacker can manipulate cached content to affect other users. Furthermore, from a threat modeling perspective using MITRE ATT&CK techniques, this vulnerability relates to T1078 Valid Accounts if combined with authentication bypasses or more broadly to data exfiltration through side-channel effects in caching layers, though it primarily manifests as a logic error leading to information disclosure rather than direct exploitation of network protocols.
To mitigate this risk, organizations running django CMS must immediately upgrade to version 5.0.8 or later, where the _page_cache_key function has been corrected to include all headers declared by plugins in the cache key generation process. This ensures that cached content is strictly partitioned based on both static context and dynamic request attributes as intended by the plugin developers. For environments unable to upgrade immediately due to dependency constraints, temporary mitigations involve disabling page caching entirely or implementing a reverse proxy layer such as Nginx or Apache with strict Vary header handling capabilities. These proxies can be configured to generate cache keys that include all relevant headers specified in the Vary response field, thereby isolating user-specific content at the infrastructure level even if the application-layer cache remains flawed. Regular security audits of custom plugins are also recommended to ensure they correctly implement vary declarations and do not expose sensitive data through improperly segmented caches.