CVE-2026-54623

This vulnerability allows a user with plugin-change permission to create a cycle in django CMS's plugin tree — making a plugin its own ancestor. The attack works through the move_plugin endpoint by setting a plugin's parent_id to itself or to one of its descendants. Once the cycle exists, the recursive CTE queries (_get_descendants_cte, _get_ancestors_cte) will either recurse indefinitely or hit PostgreSQL's max_recursion_steps limit. The 5.0.8 patch adds input validation to prevent cycle creation at the API layer, but this is a point solution to a structural problem. The underlying CTEs remain unguarded. Any future code path that modifies plugin relationships — third-party plugins, migration scripts, new features — could recreate the cycle condition. The proper architectural fix would enforce tree invariants at the database layer through CHECK constraints or triggers, preventing cycles from being created by any code path. There's a recovery problem: if a cycle already exists in your plugin tree, upgrading to 5.0.8 won't fix it. The validation prevents new cycles but doesn't heal existing ones. Operations that traverse the tree (rendering, deletion, copy operations) will still fail on corrupted trees. PluginModel.copy_recursive and related methods may silently produce incomplete copies that appear valid — they terminate without hitting the recursion limit, leaving you with corrupted content that looks healthy. You may need manual database repair. The blast radius extends beyond the admin interface. Any downstream system that caches, indexes, or materializes the plugin tree — search indexes, CDN-cached content, permission hierarchies — can persist corrupted data. If a cycle existed during a cache population window, that corruption may persist in CDN edges and application caches even after patching. You'll need to invalidate those caches explicitly. Key actions: Check your plugin tree for cycles in the database (query for parent_id values that create loops in your plugin hierarchy), verify which roles have plugin-change permission (CMS deployments often grant this to content editors and marketing staff, not just admins), plan for manual cleanup if cycles exist, and audit any third-party plugins or custom code that modifies plugin relationships for equivalent vulnerabilities.

Reviewed through automated stages and approved by a human before publication.