CVE-2026-85386 in Concrete CMS
Summary
by MITRE • 09/16/2026
Concrete CMS before 9.5.4 did not sanitize XML and XSLT documents uploaded through a public Form Block file-upload question. Plain XML uploads were validated by file extension only and stored as publicly accessible files that were served inline from the application's own origin. An unauthenticated visitor could therefore store an XML document containing an xml-stylesheet processing instruction that referenced an attacker-supplied, same-origin XSLT stylesheet. When a victim opened the stored file directly in a browser, the browser fetched the stylesheet, transformed the document into HTML, and executed attacker-controlled JavaScript in the Concrete CMS origin (stored cross-site scripting). If the victim was an authenticated administrator, the script could act with that administrator's session, and the reporter demonstrated creation of a new user in the Administrators group. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Valentin SARRE (Independent security researcher) for reporting.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.4 represents a critical failure in input validation and content type handling within the application's Form Block file upload functionality. This flaw allows unauthenticated attackers to bypass standard security controls by uploading malicious XML documents that contain XSLT processing instructions. The core technical deficiency lies in the fact that the system validates uploaded files solely based on their file extension rather than inspecting the actual content or MIME type of the document. Consequently, an attacker can upload a plain XML file with a valid extension, which is then stored as publicly accessible within the application's directory structure and served inline from the Concrete CMS origin itself. This architectural decision creates a persistent storage vector for malicious code that leverages the browser's native XML processing capabilities to execute arbitrary scripts under the trusted domain of the target website.
The operational mechanism of this exploit relies on the interaction between the stored XML document, an attacker-controlled XSLT stylesheet, and the victim's web browser. When an unauthenticated visitor uploads a crafted XML file containing an xml-stylesheet processing instruction that references a same-origin or externally hosted XSLT file, they are effectively planting a payload within the application's storage space. The critical impact occurs when another user, particularly one with administrative privileges, opens this stored XML file directly in their web browser. Upon opening the document, the browser parses the XML and fetches the referenced stylesheet. The browser then applies the XSLT transformation to the XML content, which results in the generation of HTML that includes attacker-controlled JavaScript code. Because the resources are served from the Concrete CMS origin, this constitutes a stored cross-site scripting vulnerability where the malicious script executes with full trust context of the application domain.
The security implications of this flaw are severe due to its potential for privilege escalation and persistent compromise. While any user can trigger the execution by opening the file, the impact is significantly amplified if an authenticated administrator views the document. In such scenarios, the injected JavaScript runs within the administrative session, granting the attacker full control over that session. The reporter demonstrated this capability by successfully creating a new user account with Administrator privileges through the malicious script. This action effectively provides persistent backdoor access to the CMS backend, allowing for further exploitation such as data exfiltration, defacement, or complete system takeover. The vulnerability is classified under CWE-20 Improper Input Validation and CWE-79 Cross-site Scripting within the Common Weakness Enumeration framework. From a tactical perspective, this aligns with ATT&CK techniques related to Stored XSS for initial access and persistence, as well as potential privilege escalation vectors depending on the specific actions performed by the injected script.
To mitigate this vulnerability, organizations running Concrete CMS must immediately upgrade to version 9.5.4 or later where these input validation checks have been strengthened. Until an upgrade is feasible, administrators should implement strict file upload restrictions that validate not only extensions but also content types using MIME type sniffing and magic number verification. Additionally, enabling Content Security Policy headers with a restrictive script-src directive can help mitigate the impact of any remaining cross-site scripting vectors by preventing the execution of unauthorized scripts even if they are injected into the DOM. It is also advisable to disable direct browser-based XML rendering for user-uploaded files or serve them as attachments rather than inline content, thereby forcing browsers to download the file instead of parsing and executing it automatically. Regular security audits focusing on file upload mechanisms and strict adherence to least privilege principles for administrative accounts are essential components of a defense-in-depth strategy against such storage-based attacks.