CVE-2026-81901 in Concrete CMS
Summary
by MITRE • 09/15/2026
In Concrete CMS 9.2.0 through 9.5.2, the REST API page update endpoint (PUT /ccm/api/1.0/pages/{cID}) did not enforce page-property, page-template, or page-type authorization. A user granted only content-editing rights on a page could therefore alter its properties, template, and type through the API, and could set the header_extra_content attribute, which is rendered unescaped into the head element of every page, to persist JavaScript that executed in the browser of every visitor, including higher-privileged reviewers who approve the page version. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.2 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Concrete CMS versions 9.2.0 through 9.5.2 represents a critical failure in access control logic within the platform's REST API implementation, specifically affecting the page update endpoint located at PUT /ccm/api/1.0/pages/{cID}. This flaw stems from an insufficient enforcement of authorization checks for specific page attributes during modification operations. While the CMS correctly restricts users with only content-editing permissions from altering core structural elements like page templates or types via the standard web interface, this security boundary is bypassed when interactions occur through the API endpoint. The system fails to validate whether a user possessing limited privileges has the requisite administrative rights to modify properties such as page-template, page-type, and critical metadata fields. This discrepancy between UI-based permission enforcement and API-level validation creates an authorization bypass that allows lower-privileged users to escalate their effective capabilities within the application context.
The operational impact of this vulnerability is severe due to its direct linkage to persistent cross-site scripting (XSS). The specific attribute exploited in this scenario is header_extra_content, which serves as a mechanism for administrators to inject custom code into the head element of web pages. In vulnerable versions, when an attacker with content-editing rights updates a page via the API, they can insert malicious JavaScript payloads into this field without triggering standard security warnings or permission errors. Because Concrete CMS renders the header_extra_content attribute unescaped within the HTML head section for every page where it is present, any visitor accessing such a page will execute the injected script in their browser context. This transforms what might otherwise be a simple privilege escalation issue into a widespread persistent XSS vulnerability that affects all users interacting with the compromised content.
The threat model associated with this flaw includes significant risks to data integrity and confidentiality for higher-privileged roles, particularly those involved in content approval workflows. Reviewers who possess elevated privileges often access pages to approve versions before they go live or are published publicly. When these reviewers load a page containing the malicious header_extra_content payload, their browser executes the script under their authenticated session context. This allows an attacker with minimal initial permissions to hijack administrative sessions, potentially leading to full site compromise, defacement, data exfiltration, or further lateral movement within the CMS environment. The attack requires no special user interaction beyond visiting a page that has been tampered with via the API, making it highly effective against sites with active editorial workflows where multiple users review content regularly.
From an industry standard perspective, this vulnerability aligns closely with CWE-269 Improper Privilege Management and CWE-749 Exposure of Dangerous Method or Function to Untrusted Control Entity. The failure to enforce role-based access control on the API endpoint constitutes a classic authorization bypass scenario often categorized under ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials with insufficient privileges to perform actions outside their intended scope. Furthermore, the resulting persistent XSS falls under CWE-79 Improper Neutralization of Input During Web Page Generation and is mapped to ATT&CK tactic TA0005 Defense Evasion or TA0001 Initial Access depending on the specific exploitation chain used by an adversary. The CVSS v4.0 score of 7.2 reflects the high impact on confidentiality and integrity due to the potential for session hijacking, despite requiring a privileged user interaction (reviewer visiting the page) rather than direct victim action like clicking a link.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is upgrading Concrete CMS to version 9.5.3 or later, where the security team has patched this authorization gap by enforcing strict permission checks on all modifiable fields within the REST API page update endpoint. Administrators should also audit existing content for any injected scripts in the header_extra_content attribute if they are running an unpatched version and cannot immediately upgrade. To prevent similar issues in custom integrations, developers implementing API consumers must ensure that their applications adhere to the principle of least privilege and validate server-side authorization responses rather than relying solely on client-side restrictions. Additionally, implementing Content Security Policy (CSP) headers can provide a layer of defense-in-depth by restricting script execution sources, although this does not replace the need for fixing the underlying access control flaw in the application logic itself.