django-page-cms EUVD-2026-82616

Exploitation requires (1) a target running django-page-cms at or below 2.0.13 with the five CSRF-exempt admin mutation views in pages/admin/views.py, and (2) a user with editor/admin privileges who is currently authenticated to the CMS and who is tricked into visiting attacker-controlled content (UI:P). The attacker themselves needs no account (PR:N), but cannot succeed without the authenticated victim's browser and their active session. Limiting factors: the social-engineering/user-interaction requirement, the need for the victim to hold content-editing rights, and reliance on the browser sending the session cookie cross-site (standard SameSite cookie policies on the session cookie could blunt the CSRF). Stored XSS payload only fires for visitors after a successful forged mutation.

This is a genuine but conditional risk, not a drop-everything emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) correctly models a CSRF flaw: the attacker is unauthenticated (PR:N) but success depends on a signed-in editor being lured into visiting a malicious page (UI:P), which meaningfully limits automatability and scale. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced - only the VulnCheck advisory, the source lines, and GitHub issue #244 - so exploitation status is 'no public exploit identified at time of analysis.' The vendor's 8.4 (HIGH) is driven largely by VI:H and SI:H (integrity of page content plus stored XSS to visitors); I consider VI:H/SI:H aggressive for a socially-engineered, victim-gated CSRF-to-stored-XSS chain and assess it closer to a 3.1 6.1 (S:C/C:L/I:L). No signals conflict outright, but the headline severity overstates real-world urgency because exploitation requires an authenticated editor to interact with attacker content. No fix version is stated in the input, which is a gap for remediation planning.

An attacker crafts a web page containing a hidden auto-submitting form (or image/fetch) targeting one of the five CSRF-exempt admin mutation endpoints in pages/admin/views.py, then lures a signed-in django-page-cms editor to visit it. The editor's authenticated browser silently submits the forged request, storing unescaped HTML that becomes persistent XSS executed in every visitor's browser. No public proof-of-concept is referenced; exploitation relies on social engineering (UI:P) rather than an automated remote exploit.