CVE-2026-81926

Concrete CMS before 9.5.4 authorized OAuth REST API requests based solely on the bearer token and did not re-check the state of the account the token was issued to. Deactivating, deleting, or locking a user did not revoke their outstanding tokens, so such a user retained full access to /ccm/api/1.0/* until the token expired.

Concrete CMS before 9.5.3 exposed a legacy Express entry search endpoint that returned entry result JSON without invoking the canViewExpressEntries() permission check applied by the normal dashboard and CSV Export flow. An unauthenticated visitor who knew or discovered an Express entity identifier could enumerate that entity's entry search results, disclosing attribute values intended to be restricted to privileged users.

In Concrete CMS 9.2.0 through 9.5.3, the REST API user creation endpoint (POST /ccm/api/1.0/users, the add() method of concrete/src/Api/Controller/Users.php) did not perform a permission check before creating an account. As a result, any valid OAuth token carrying the users:add scope, including a client_credentials token with no associated user context, could create active, validated user accounts, bypassing email verification and administrator approval. Under default registration settings the created accounts could then edit page content, providing a path to stored cross-site scripting.

Concrete CMS 9 through 9.5.3 did not confirm that a board InstanceItem submitted to the custom-slot preview endpoint belonged to the board instance the requesting user was authorized to edit, and did not enforce page-view permission before generating page-backed summary content. As a result, an authenticated user holding edit-board-contents permission on a single board instance could submit the identifier of an item belonging to a different board instance and receive summary fields, including the page title and description, of an underlying page the same user was otherwise forbidden to view. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.3.

Concrete CMS before 9.5.4 did not sanitize XML and XSLT documents uploaded through a public Form Block file-upload question. An unauthenticated visitor could store an XML document with an xml-stylesheet processing instruction referencing an attacker-supplied same-origin XSLT stylesheet, leading to stored XSS in the Concrete CMS origin.

Concrete CMS below 9.5.4 did not validate the user timezone value (uTimezone) on write and rendered it without output encoding on the Dashboard user management page. A stored XSS payload saved in this field executed in an administrator's browser when they viewed the affected user.

Concrete CMS below 9.5.3 did not sanitize custom style values in the Block Design dialog before writing them into page CSS via a DOM sink, permitting stored cross-site scripting. An editor-level user could execute script in an administrator's session and escalate privileges.

Concrete CMS before 9.5.3 contained a stored cross-site scripting vulnerability in SVG file handling. In the non-default "Reject files containing potentially harmful elements" mode, uploaded SVGs were checked only against a small built-in blocklist, and the broader sanitization result was discarded, allowing malicious JavaScript to be stored and executed.

Concrete CMS 9.0.0 through 9.5.2 did not enforce a block-level edit-permission check on the Express Form block's control-management actions, relying solely on CSRF token validation. Because the token is bound to the user and action rather than a specific block, page, or form, an authenticated user with edit access to one Express Form could reuse a valid token to modify controls on forms they were not authorized to edit, including injecting a control later rendered as HTML (stored XSS).

Concrete CMS before 9.5.3 improperly neutralized a user-supplied custom date format when rendering conversation messages, resulting in reflected cross-site scripting. An attacker could execute arbitrary JavaScript in the browser of a user who was tricked into submitting a crafted POST request to the conversation view endpoint. Exploitation was aided by the absence of a CSRF token on the endpoint.