CVE-2026-81912 in Concrete CMS
Summary
by MITRE • 09/11/2026
Concrete CMS before 9.5.3 is vulnerable to Cross-Site Request Forgery in the Move Multiple Groups feature. The dashboard/users/groups/bulkupdate/confirm() endpoint moved the selected group tree nodes without validating an action token, so a state-changing group move could be processed for an authenticated user who did not initiate it. Because relocating a group under a new parent causes that group's members to inherit the parent's permissions, a forged move can change effective authorization. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.7 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn 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 Cross-Site Request Forgery vulnerability within the bulk group management functionality, specifically affecting the dashboard/users/groups/bulkupdate/confirm endpoint. This security flaw arises from an insufficient validation of action tokens during state-changing operations involving user groups. When administrators or users with appropriate privileges attempt to reorganize the group hierarchy by moving selected group nodes under a new parent structure, the system fails to verify that the request originated from a legitimate session initiated by the authenticated user. Consequently, an attacker can craft malicious web pages containing forged HTTP requests that trick victims into executing unintended administrative actions without their knowledge or consent.
The operational impact of this vulnerability is significant due to its direct influence on authorization logic within the CMS architecture. In Concrete CMS, group hierarchies are not merely organizational tools but serve as a mechanism for permission inheritance. When a group is moved under a different parent node in the tree structure, all members of that child group automatically inherit the permissions associated with the new parent group. This design choice means that an unauthorized move operation can effectively escalate privileges or alter access controls across multiple user accounts simultaneously. An attacker exploiting this flaw could relocate sensitive administrative groups into less privileged containers to restrict their capabilities, or conversely, move restricted groups under highly privileged parents to grant them elevated access rights without proper authorization checks.
From a classification perspective, this vulnerability aligns with CWE-352, which defines Cross-Site Request Forgery as an attack that forces an end user to execute unwanted actions on a trusted web application for which they are currently authenticated. The lack of anti-CSRF token validation represents a fundamental failure in ensuring request integrity and origin verification. Furthermore, the exploitation technique maps directly to MITRE ATT&CK tactic T1566.002, known as Spearphishing Link, where attackers lure users into clicking links that trigger state-changing requests. The ability to manipulate group permissions through this vector also touches upon privilege escalation concepts found in CWE-269, indicating a potential for lateral movement or vertical privilege abuse depending on the target groups involved.
The Concrete CMS security team has assessed this issue with a CVSS v4.0 base score of 5.7, reflecting its medium severity profile characterized by network-based attack vectors, low complexity, and high impact on confidentiality due to unauthorized access changes. The vector string CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N highlights that while the vulnerability requires user interaction and prior authentication, it poses a substantial risk because it compromises confidentiality without necessarily affecting integrity or availability in the traditional sense. The primary mitigation strategy is to upgrade Concrete CMS immediately to version 9.5.3 or later, where this token validation mechanism has been corrected. Administrators should also ensure that their deployment environments enforce strict Content Security Policy headers and utilize modern browser security features to mitigate potential exploitation attempts until patches are applied.