CVE-2026-81897 in Concrete CMS
Summary
by MITRE • 09/15/2026
In Concrete CMS below CMS 9.5.3, the save_control action in the Express entities forms dashboard controller did not validate the anti-CSRF token. By causing an authenticated administrator to submit a forged cross-site request, a remote attacker without credentials could write attacker-controlled headline and body values to an existing Express form Text control. Those values were emitted without output encoding by the Express form Text element, so the injected markup executed as persistent JavaScript for any administrator who later opened the affected entry, resulting in stored cross-site scripting. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.7 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.
Statistical analysis made it clear that VulDB provides the best quality 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 critical failure in the implementation of cross-site request forgery protections within the administrative interface, specifically affecting the save_control action associated with Express entities forms dashboard controllers. This flaw allows an unauthenticated remote attacker to manipulate state-changing operations by exploiting the absence of anti-CSRF token validation. In standard web application security practices, actions that modify server-side data must require a unique, unpredictable token tied to the user's session to prevent unauthorized commands from being submitted on behalf of authenticated users. The omission of this check in the specified controller method creates a direct pathway for attackers to force an administrator’s browser to execute unintended requests while they are logged into the CMS dashboard.
The operational impact of this vulnerability is severe due to its combination with stored cross-site scripting capabilities. Once an attacker successfully crafts and delivers a malicious link or form that triggers the save_control action, it causes the system to update existing Express forms by writing attacker-controlled headline and body values into Text controls. Crucially, these injected values are rendered without proper output encoding when displayed via the Express form Text element. This lack of sanitization means that any HTML or JavaScript code embedded in the submitted data is executed directly within the context of other users' browsers rather than being treated as plain text. Consequently, this transforms a simple CSRF issue into a persistent stored XSS vulnerability, where the malicious payload remains active on the server until manually removed by an administrator.
The persistence of this attack vector significantly amplifies its risk profile compared to reflected or DOM-based cross-site scripting variants. Because the injected script is stored in the database and served dynamically to any administrator who views the affected entry, a single successful exploitation can compromise multiple users over time without further interaction from the attacker. This behavior aligns with CWE-80, which covers Improper Neutralization of Script-Related HTML Tags in a Web Page, and specifically illustrates how insufficient validation leads to persistent code injection. The attack also maps to MITRE ATT&CK technique T1566.002, known as Spearphishing Link, where the initial vector involves tricking an administrator into clicking a malicious link that triggers the backend state change leading to data persistence.
The Concrete CMS security team has assigned this vulnerability a CVSS v4.0 score of 7.7, reflecting its high severity based on factors such as low attack complexity and no required privileges for the initial trigger, coupled with high impact on confidentiality, integrity, and availability due to the persistent nature of the script execution. The vector indicates that while an attacker does not need prior authentication to initiate the request, they do rely on user interaction (UI:P) which is typical for CSRF-based attacks but mitigated by proper token implementation. To mitigate this risk, administrators must upgrade immediately to Concrete CMS version 9.5.3 or later where the anti-CSRF validation has been properly implemented in the save_control action. Additionally, implementing Content Security Policy headers can provide a layer of defense against script execution even if similar vulnerabilities exist elsewhere in the application stack by restricting the sources from which scripts are allowed to load and execute.