CVE-2026-81902 in Concrete CMS
Summary
by MITRE • 09/14/2026
Concrete CMS 9 through 9.5.2 did not validate a CSRF token in the orphaned block removal panel action (removeOrphanedBlocks). A remote attacker could craft a request that, when loaded by an authenticated user holding edit permission on the target page, deleted every block on that page's current version; blocks not aliased to another page or scrapbook entry were also removed from the global Blocks table and their block-type data table, permanently destroying the content. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.1 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/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/14/2026
The vulnerability identified in Concrete CMS versions 9 through 9.5.2 represents a critical failure in access control mechanisms, specifically concerning Cross-Site Request Forgery protections within the administrative interface. The core technical flaw resides in the removeOrphanedBlocks action handler, which processes requests to delete orphaned content blocks from the system database. In a properly secured web application, any state-changing operation that modifies data on behalf of an authenticated user must require a valid anti-CSRF token to verify that the request originated from a legitimate session initiated by the user themselves. However, in this instance, the implementation failed to validate such tokens for this specific endpoint. This oversight allows an attacker to construct malicious HTTP requests containing arbitrary parameters designed to trigger block deletion without requiring any form of cryptographic proof of intent from the victim user. The absence of token validation effectively neutralizes one of the primary defenses against CSRF attacks, leaving authenticated sessions vulnerable to unauthorized state changes initiated by third-party sites or crafted links.
The operational impact of this vulnerability is severe due to its potential for complete data destruction within a specific context. An attacker who can lure an administrator or content editor with sufficient permissions into visiting a malicious page or clicking a crafted link can execute the removeOrphanedBlocks action on any page where that user has edit privileges. The consequence is not merely temporary disruption but permanent data loss, as the vulnerability causes the deletion of every block present in the current version of the targeted page. Furthermore, blocks that are not aliased to other pages or scrapbook entries are also removed from the global Blocks table and their corresponding block-type specific data tables. This means the underlying content is purged from the database entirely rather than just being hidden or unpublished, making recovery difficult without recent backups. The severity of this impact is reflected in the CVSS v4.0 score of 7.1, which highlights high integrity loss while noting that confidentiality and availability impacts are technically classified as none because the attacker does not steal data nor cause a denial of service to the entire system, but rather destroys specific content owned by the victim.
From a classification perspective, this vulnerability aligns with CWE-352, Cross-Site Request Forgery (CSRF), due to the lack of token validation for state-changing operations. It also relates closely to CWE-862, Missing Authorization, as the system fails to ensure that only authorized actions are performed by authenticated users in a secure manner. In terms of adversary tactics, this exploit maps to MITRE ATT&CK technique T1534, Internal Spearphishing, where an attacker might use social engineering or malicious web content to trick an insider into triggering the action. The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P indicates that the attack is network-based with low complexity and requires user interaction, specifically UI deception leading to privilege misuse. This profile suggests that while the technical barrier for exploitation is minimal, successful attacks depend heavily on social engineering or compromised websites directing victims to trigger the malicious request.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is the implementation of robust anti-CSRF tokens for all state-changing endpoints within Concrete CMS, particularly those handling administrative functions like block management. Developers should ensure that every POST, PUT, or DELETE request includes a unique, unpredictable token tied to the user's session, which is validated server-side before any database modifications occur. Additionally, implementing SameSite cookie attributes can provide an additional layer of protection by restricting how browsers send cookies in cross-site contexts. For administrators using affected versions, immediate patching to version 9.5.3 or later is essential to resolve this flaw. Organizations should also review their backup and disaster recovery procedures to ensure that content loss from such vulnerabilities can be rapidly restored if an incident occurs before patches are applied. Regular security audits focusing on CSRF protections across all administrative panels will help prevent similar oversights in future development cycles.