Vulnerability in django-cms (CVE-2026-54625)
Summary
Vulnerability in django-cms (CVE-2026-54625). Risk of unauthorized operations or information disclosure. Exploitable via Vary. Mitigation: upgrade to 5.0.8 or later.
Original description
The description as published by the source.
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.
Source: NIST National Vulnerability Database NVD GitHub Advisory
Auto-generated summary
Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.
A vulnerability tracked as CVE-2026-54625 has been found in django-cms.
Attackers can target a specific entry point like Vary over the network to misuse the product.
Risk of unauthorized operations or information disclosure. CVSS score: 4.8/10.
What to do: upgrade django-cms to 5.0.8 or later.
If unsure, ask your IT team or search "django-cms CVE-2026-54625" on the vendor's site.
CVE-2026-54625 (django-cms) — CWE-349 / CVSS v3 4.8
Attack vector: remote (network-reachable) / unauthenticated / no user interaction
Attack surface: Vary / _page_cache_key / set_page_cache / get_page_cache
Patched: 5.0.8 — apply immediately
Workaround: Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.
A vulnerability (CWE-349) exists in django-cms. Attackers reach the vulnerable code path via Vary without authentication.
Check the vendor advisory for the affected versions of django-cms. Attack surface: Vary / _page_cache_key / set_page_cache / get_page_cache.
Severity: Medium (CVSS 4.8/10). Risk of unauthorized operations or information disclosure.
Update to 5.0.8.
Workaround: Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.
Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Run grep -r 'django-cms' . against your dependency files (package-lock.json, requirements.txt, go.sum) to find affected services.
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1Identify exposure identify
grep -r 'django-cms' . | grep -v node_modulesリポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で
django-cmsを grep し、稼働しているサービス・バージョンを把握する。 -
2Apply temporary workaround mitigate
Disable `CMS_PAGE_CACHE`, or avoid plugins that rely on `get_vary_cache_on()`, until upgraded.パッチが適用されるまでの応急処置として、Disable
CMS_PAGE_CACHE, or avoid plugins that rely onget_vary_cache_on(), until upgraded. を実施。回避策の副作用 (機能低下) を確認した上で。 -
3Apply patch patch
Upgrade django-cms to 5.0.8ステージング環境で 5.0.8 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスを含めること。
-
4Post-deployment verification verify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。
Affected packages
References
- advisory github.com
- advisory nvd.nist.gov
- advisory github.com
- patch github.com
- patch github.com
- patch github.com
- patch github.com
- web github.com
- web github.com
- web github.com