django CMS CVE-2026-54623

Exploitation requires an authenticated staff-level Django user account (is_staff=True) with the change_plugin permission explicitly granted under django CMS's CMS_PERMISSION system - this permission is not granted by default to all staff users and must be assigned. The attacker must be able to POST to the move_plugin admin endpoint. The cyclic reparenting DoS is limited to move operations only; copy and cut-to-clipboard operations create new plugin instances and are not affected by this specific cycle vector. Anonymous users and authenticated non-staff users cannot reach this endpoint. The database must support recursive CTEs (PostgreSQL, MySQL 8+, SQLite 3.35+); databases without CTE support or with very low recursion depth limits will surface an error earlier but may still corrupt tree state. Organizations using CMS_PERMISSION with narrowly scoped per-placeholder grants to a small number of trusted editors face significantly lower realistic risk than those granting broad plugin-change permissions site-wide.

The CVSS 7.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H accurately reflects the threat profile: the attack is network-accessible, low-complexity, and requires no user interaction, but is gated behind authenticated staff access with the specific plugin-change permission under CMS_PERMISSION. The high availability impact (A:H) is credible - stalled request workers can cascade to full CMS unavailability. The low integrity impact (I:L) reflects persistent tree corruption in the database. EPSS score was not provided in the input data, so probabilistic exploitation likelihood cannot be assessed numerically. No CISA KEV listing was referenced, and no public proof-of-concept was identified, making this lower operational priority than an unauth or KEV-listed issue of similar CVSS. Real-world risk is meaningfully reduced by the PR:L constraint: anonymous users, regular authenticated CMS users, and even staff without plugin-change grants cannot exploit this. The primary threat model is a malicious or compromised internal staff account. Organizations that tightly scope CMS_PERMISSION grants face lower realistic risk than those granting broad plugin-change permissions across many users.

An authenticated staff user with plugin-change permission logs into the django CMS admin interface and issues a crafted POST to the move_plugin endpoint, setting plugin_parent to the primary key of a child plugin that is already a descendant of the plugin being moved. The database writes the cyclic relationship, and any subsequent CMS operation that calls get_descendants() on the parent plugin - such as page rendering, a subsequent move, or a delete - triggers indefinite recursive CTE execution, stalling the database connection and the web worker thread for the duration, effectively denying service to other users. No public proof-of-concept exploit has been identified, but the attack is straightforward to reproduce from the pull request description and commit diff at https://github.com/django-cms/django-cms/pull/8645.