CVE-2026-81896 in Concrete CMS
Summary
by MITRE • 09/15/2026
Concrete CMS before 9.5.3 does not apply HTML entity encoding to user-defined Form block question labels when rendering them as column headers in the Dashboard Form Submissions report (concrete/single_pages/dashboard/reports/forms/legacy.php). a rogue editor could store markup or script in a label that then executes in the browser of any administrator who opens the submissions report for the affected form, producing stored cross-site scripting in the Dashboard. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 8.4 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Concrete CMS versions prior to 9.5.3 represents a significant security flaw within the administrative interface, specifically affecting how user-generated content is processed and rendered in backend reports. The core technical issue lies in the handling of Form block question labels when they are displayed as column headers in the Dashboard Form Submissions report located at concrete/single_pages/dashboard/reports/forms/legacy.php. In this context, the application fails to apply HTML entity encoding or proper output escaping to these user-defined values before injecting them into the HTML document structure. This omission allows raw markup and executable script tags to be passed through directly from the database storage layer to the browser rendering engine without sanitization.
This technical deficiency results in a Stored Cross-Site Scripting vulnerability, often referred to as persistent XSS. Unlike reflected XSS where malicious payloads are delivered via URLs or temporary inputs, stored vulnerabilities persist within the application's data store. In this scenario, an attacker with editor privileges can create a form and define a question label containing malicious JavaScript code. This payload is then saved in the database alongside other form metadata. When any administrator subsequently accesses the Form Submissions report for that specific form to review user responses, the browser parses the unescaped script tags embedded within the column headers. The execution context of this script is privileged because it runs within the administrative dashboard interface, granting the attacker access to session cookies, authentication tokens, and other sensitive data associated with the administrator's active session.
The operational impact of this vulnerability is severe due to its stored nature and high-privilege execution environment. An adversary can leverage this flaw to perform actions on behalf of an authenticated administrator without their knowledge or consent. This includes modifying site configurations, creating new administrative accounts, exfiltrating sensitive data submitted through forms, or defacing the website interface. The ability to execute arbitrary JavaScript in the context of the admin dashboard effectively compromises the integrity and confidentiality of the entire CMS installation. The severity is further amplified by the fact that it requires only editor-level privileges for exploitation, which are often granted to multiple users within an organization, thereby increasing the attack surface significantly compared to vulnerabilities requiring full administrative access at the point of injection.
Industry standards classify this flaw under CWE-79, known as Improper Neutralization of Input During Web Page Generation (Cross-site Scripting). The specific variant here is Stored XSS where untrusted data is stored and later rendered in a different context without proper validation or encoding. From an offensive security perspective, such vulnerabilities align with MITRE ATT&CK techniques related to Client-side Injection and potentially Account Manipulation if the attacker uses the compromised session to escalate privileges further. The CVSS v4.0 score of 8.4 reflects high confidentiality and integrity impacts due to the privileged context in which the script executes, despite requiring user interaction (opening the report) for exploitation.
Mitigation strategies primarily involve upgrading Concrete CMS to version 9.5.3 or later, where this specific input validation and output encoding issue has been addressed by the development team. For organizations unable to patch immediately due to compatibility constraints, temporary mitigations should focus on restricting editor-level access to trusted individuals only and implementing strict Content Security Policy headers that restrict script execution sources if feasible within their infrastructure. Additionally, administrators should be trained to recognize unusual behavior in dashboard reports and avoid interacting with forms from untrusted or compromised users until the patch is applied. Regular security audits of form configurations can also help identify any previously injected malicious labels before they are exploited by other administrative users.