CVE-2026-84432: Concrete CMS 9 through 9.5.2 is vulnerable to CSRFin the Boards custom slot dialog controller
Concrete CMS 9 through 9.5.2 did not validate an anti-CSRF token in the Boards custom slot dialog controller (concrete/controllers/dialog/board/customslot.php) saveTemplate() action. The action created a boardslotproxy Block and dispatched an AddCustomSlotToBoardCommand against a board instance while gating only on the per-resource canEditBoardContents() permission, so a crafted cross-site request could cause a user holding board-edit permission with an active session to write attacker-chosen slot and template data to a board under their own authority. The state-changing database write completed before any downstream rendering, so the forged request succeeded even when the HTTP response returned a non-200 status. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.3 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting.
Affected Software
Event History
Frequently Asked Questions
Which users are relevant to exploitation?
A victim must have an active Concrete CMS session and permission to edit the targeted board's contents through canEditBoardContents(). Users without that board-edit permission are not the authorization context used for the write.
Does an attacker need a Concrete CMS account?
No attacker authentication is required. The attacker needs to induce a board editor with an active session to send a crafted cross-site request.
What can a successful forged request change?
It can create a board_slot_proxy Block and add an attacker-chosen slot and template to a board under the victim's authority. The described impact is modification of board content rather than disclosure or availability loss.
Can a non-200 HTTP response be used to determine that the attack failed?
No. The database write occurs before downstream rendering, so the forged state change can succeed even if the response returns a non-200 status.