CVE-2026-81915 in Concrete CMS
Summary
by MITRE • 09/11/2026
Concrete CMS below 9.5.3 does not perform an object-level authorization check when a Page Type was updated. The Types::submit() dashboard controller loaded and saved the Page Type identified by a user-supplied ptID without calling canEditPageType(), so a signed-in dashboard user permitted to edit one Page Type could modify the configuration of Page Types outside their assigned authorization boundary. The update_page_type token was validated but is action- and user-scoped rather than object-scoped, so it did not constrain which Page Type could be targeted. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.1 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/11/2026
Concrete CMS versions prior to 9.5.3 contain a critical authorization bypass vulnerability within the dashboard controller responsible for managing Page Types. The core technical flaw resides in the Types::submit() method, which processes updates to page type configurations without performing an object-level authorization check. Specifically, the function loads and saves the Page Type identified by a user-supplied ptID parameter directly from the request data. This implementation fails to invoke the canEditPageType() validation routine, which is the standard mechanism for verifying that the authenticated user has permission to modify the specific resource being targeted. Consequently, an attacker who possesses valid credentials with access to edit at least one Page Type in the system can manipulate this parameter to target and alter the configuration of any other Page Type within the CMS environment, regardless of their assigned authorization boundaries.
The vulnerability is further exacerbated by the nature of the anti-CSRF token validation implemented in the affected endpoint. While the update_page_type token is indeed validated upon submission, its scope is limited to action-level and user-level checks rather than object-level constraints. This means that while the system verifies that a legitimate session initiated the request, it does not verify that the specific Page Type being modified belongs to or is authorized for modification by that particular user session. This architectural oversight allows an authenticated attacker with minimal privileges to escalate their effective permissions across multiple administrative objects within the application. The lack of object-level scoping in both the authorization logic and the token validation creates a significant gap in access control enforcement, enabling unauthorized configuration changes that can compromise the integrity and security posture of the entire CMS installation.
The operational impact of this vulnerability is substantial for organizations relying on Concrete CMS for their web infrastructure. An attacker with low-privileged dashboard access can modify critical settings associated with various page types, such as form field configurations, template structures, or metadata handling rules. These modifications can lead to data integrity issues, unauthorized collection of user information through manipulated forms, or the introduction of persistent cross-site scripting vectors if malicious scripts are injected into editable fields within the affected Page Types. Furthermore, altering these structural components may disrupt site functionality and degrade the user experience for legitimate visitors. The vulnerability effectively undermines the principle of least privilege by allowing users to perform administrative actions beyond their designated scope, potentially leading to broader system compromise or serving as a stepping stone for more severe attacks such as remote code execution if combined with other vulnerabilities in form processing logic.
Industry standards classify this flaw under CWE-284, which describes Improper Access Control where insufficient access restrictions are applied during the authorization process. The attack vector aligns with MITRE ATT&CK techniques related to Privilege Escalation and Defense Evasion, specifically leveraging valid credentials to bypass intended security boundaries. To mitigate this risk, administrators must immediately upgrade Concrete CMS to version 9.5.3 or later, where the Types::submit() controller has been patched to enforce strict object-level authorization checks before processing any updates. Additionally, it is recommended that developers review other dashboard controllers for similar patterns of missing canEditPageType calls and ensure that anti-CSRF tokens are scoped not only by user and action but also by the specific resource identifier being modified. Regular security audits focusing on access control logic in administrative interfaces are essential to prevent recurrence of such authorization bypasses in complex content management systems.