CVE-2026-75526

## Summary When plugin rendering fails in edit mode, django CMS renders a `cms-rendering-exception` block so editors can see that a placeholder could not be rendered. Older code built that block's heading by interpolating the exception message, placeholder/source strings, and the failing plugin's short description directly into an HTML string, then returned the placeholder output as safe markup. If an editor could store HTML in data used by a plugin's `get_short_description()` (or in other values interpolated into the exception message), and that plugin later raised during edit-mode rendering, the payload was parsed as HTML in the staff user's browser. This is a stored XSS condition in the CMS editing context. ## Impact The vulnerable path is only reached when placeholder rendering catches a plugin rendering exception: ```python try: placeholder_content = "".join(plugin_content) except Exception as e: context["exc_info"] = sys.exc_info() placeholder_content = self.render_exception("rendering placeholder", context, placeholder, editable) ``` `render_exception()` constructs a `message` from values that can include stored content: - `value` - the exception message. - `placeholder` - the placeholder string representation. - `placeholder.source` - the source object string representation, such as page content. - `instance.get_short_description()` - plugin-provided summary text, often derived from plugin model fields. In the vulnerable implementation, that message was embedded directly into an HTML heading. The final placeholder content was later returned through `mark_safe`, so Django template autoescaping did not protect the heading. `settings.DEBUG` does not mitigate the issue: it only controls whether Django's traceback HTML is appended. The custom heading is rendered in edit mode regardless of `DEBUG`. ## Patch Escape the custom exception heading before returning it as safe placeholder markup. The current fixed code uses `format_html`, which esc