Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.8",
  "pubDate": "2026-08-20T18:16:28.170Z",
  "pubdate": "2026-08-20T18:16:28.170Z",
  "executiveSummary": "An improper caching implementation flaw exists in django CMS prior to version 5.0.8 and version 5.1.0a1, specifically within the page caching mechanism located in cms/cache/page.py.\nThe vulnerability involves a failure of the page cache to properly incorporate request headers declared by plugins via the get_vary_cache_on() method into the generated cache keys.\nThis allows unauthenticated attackers or standard users to experience cache poisoning and cross-user data contamination.\nWhen CMS_PAGE_CACHE is enabled, plugins that rely on request-specific headers such as Country-Code fail to isolate cache entries correctly.\nConsequently, an unauthenticated attacker can prime the cache with arbitrary attacker-chosen content, or legitimate users can receive other visitors' request-specific, sensitive content.\nExploitation requires the page cache to be active and plugins to utilize header-dependent caching mechanisms without authentication barriers.",
  "technicalDetails": "The vulnerability resides in the page cache handling functions within cms/cache/page.py of django CMS, specifically affecting versions prior to 5.0.8 and version 5.1.0a1.\nThe root cause stems from a discrepancy between how cache keys are generated and how Vary headers are populated.\nThe internal _page_cache_key function constructs the cache key using only the cache prefix, site identifier, language, request path, and timezone.\nIt entirely omits the dynamic request header values declared by plugins through the get_vary_cache_on() function.\nAlthough the set_page_cache function correctly appends these header names to the HTTP response Vary header, the subsequent retrieval mechanism via get_page_cache attempts to fetch cache entries using the strictly header-agnostic key generated by _page_cache_key.\nAs a result, get_page_cache retrieves the very first stored variant of a page regardless of subsequent requests containing different header values.\nThe attack flow proceeds as follows: an attacker or initial user sends a crafted HTTP request with specific headers to a page containing a plugin that varies content based on request headers like Country-Code.\nThe application processes the request, caches the response under the generic cache key, and populates the Vary header.\nSubsequent visitors issuing requests with different header values are served the cached response intended for a different context due to the shared, header-agnostic cache key.\nAn unauthenticated attacker can proactively prime the cache by sending malicious inputs, forcing subsequent users to receive attacker-chosen content.\nThis flaw impacts integrity and confidentiality across network exposures where CMS_PAGE_CACHE is enabled."
}