CVE-2026-75526 in Django CMS
Summary
by MITRE • 08/20/2026
django CMS is an easy-to-use and developer-friendly enterprise content management system powered by Django. From 5.0.8 until 5.0.9, ContentRenderer.render_placeholder in cms/plugin_rendering.py can pass stored, attacker-controlled values to ContentRenderer.render_exception when plugin rendering fails in edit mode. Values from get_short_description(), the exception message, the placeholder, or placeholder.source are interpolated into a cms-rendering-exception heading and later returned through mark_safe. Because the heading is not escaped, stored HTML executes in an editor’s browser, and settings.DEBUG does not prevent the custom heading from rendering. The fix uses format_html to escape the message before safe placeholder output is returned. This issue is fixed in versions 5.0.9.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in django CMS versions ranging from 5.0.8 through 5.0.9 represents a critical stored cross-site scripting flaw within the content rendering engine, specifically located in the ContentRenderer.render_placeholder method found in cms/plugin_rendering.py. This issue arises during the edit mode of the platform when plugin rendering encounters an exception or failure state. Under normal operational circumstances, django CMS is designed to display error messages to administrators and developers for debugging purposes. However, due to improper handling of user-supplied data within this specific code path, the system fails to sanitize inputs that are derived from various sources including the get_short_description method, the exception message itself, placeholder identifiers, or the source attribute of the placeholder object. These values, which can be controlled by an attacker if they have previously injected malicious content into a CMS entity such as a plugin configuration or page metadata, are directly interpolated into a custom HTML heading element labeled cms-rendering-exception without adequate escaping mechanisms in place.
The technical core of this vulnerability lies in the use of Python's mark_safe function to return the constructed exception message for rendering by the browser. While django CMS typically employs Django’s template engine which includes automatic context autoescaping, the specific implementation here bypasses these protections by explicitly marking the string as safe HTML before it is sent to the client side. Consequently, any special characters within the attacker-controlled values are interpreted as executable code rather than literal text when rendered in an administrator or editor's web browser. This behavior persists regardless of whether the Django settings.DEBUG flag is enabled or disabled, indicating that the flaw is structural to the rendering logic itself and not merely a consequence of debug mode configurations. The result is that stored malicious scripts embedded within CMS content are executed whenever an admin user views a page containing the compromised plugin in edit mode, leading to persistent session hijacking, credential theft, defacement, or other client-side attacks against privileged users who interact with the backend interface.
From a classification perspective, this vulnerability aligns closely with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). Specifically, it falls under stored XSS because the malicious payload is saved within the application's database or content store and subsequently retrieved and executed in multiple user sessions. In terms of offensive security frameworks such as MITRE ATT&CK for Enterprise, this behavior corresponds to techniques involving Client-side Injection, particularly those that leverage browser-based execution contexts like Scripting (T1059) or potentially Drive-by Command and Control if the script facilitates further exploitation chains. The impact is severe because it targets high-privilege accounts such as site administrators who are essential for content management operations, thereby compromising the integrity of both the user session and the broader application environment.
The resolution implemented in django CMS version 5.0.9 addresses this security gap by replacing the unsafe string concatenation or direct marking with format_html from Django’s utility module. This function ensures that all variable inputs are properly escaped according to HTML standards before being marked as safe, thereby neutralizing any script tags or event handlers contained within user-supplied data. To mitigate risks in environments still running affected versions until an upgrade is feasible, administrators should ensure that no untrusted content is stored in fields that feed into plugin descriptions or placeholder sources if edit mode access is required by multiple users. Additionally, implementing strict Content Security Policy headers can help limit the execution of inline scripts even if such vulnerabilities exist, serving as a defensive layer to reduce the blast radius of potential exploitation attempts against administrative interfaces.