CVE-2026-81915
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk19th percentile - higher than 19% of all known CVEs
Summary
Concrete CMS below 9.5.3 does not perform an object-level authorization check when a Page Type is updated. The Types::submit() dashboard controller loaded and saved the Page Type identified by a user-supplied ptID without calling canEditPageType(), allowing a signed-in dashboard user to modify Page Types outside their assigned authorization boundary.
Risk Assessment
A user with permission to edit one Page Type can modify the configuration of other Page Types, potentially leading to unauthorized changes on the site.
Recommendation
Upgrade Concrete CMS to version 9.5.3 or later to fix the missing object-level authorization check.
Other vulnerabilities in Concrete CMS
See all- CVE-2026-85385Critical
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.
- CVE-2026-18119Critical
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.
- CVE-2026-85387High
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.
- CVE-2026-18120Medium
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.
- CVE-2026-87031Low
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.
- CVE-2026-87028Medium
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.
- CVE-2026-85386Medium
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.
- CVE-2026-81927Medium
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.
- CVE-2026-81926Medium
Concrete CMS 9.4.0 through 9.5.2 did not escape colliding page paths before rendering them in the location panel's duplicate-path confirmation dialog. The endpoint returned the submitted path unmodified and client-side JavaScript inserted it as raw HTML, allowing script execution in the editor's authenticated session.
- CVE-2026-18426Medium
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).
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

