CVE-2026-7886
MediumCVSS 4.3Exploitation Probability (EPSS)
Low risk21th percentile - higher than 21% of all known CVEs
Summary
Concrete CMS version 9.5.0 and below is vulnerable to IDOR in the AddMessage and UpdateMessage controllers via the attachments[] parameter. They lack per-file permission checks (canViewFile()), allowing a user who can post in any conversation to reference any file in the CMS file manager by its ID, bypassing the permission system.
Risk Assessment
The organization risks unauthorized access to private files stored in the CMS, potentially leading to exposure of confidential data.
Recommendation
Update Concrete CMS to a version above 9.5.0, and for private files configure a private storage location outside the webroot.
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 9.5.0 and below is vulnerable to IDOR in AddMessage/UpdateMessage via attachments[] parameter which can lead to file permission bypass. The `AddMessage` and `UpdateMessage` conversation controllers accept user-supplied file attachment IDs and load files directly via `$em->find(File::class, $attachmentID)` without checking per-file permissions (`canViewFile()`). A user who can post in any conversation can reference any file in the CMS file manager by its sequential ID, effectively bypassing the file permission system. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 2.3 with a vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Tristan Mandani for reporting. if a site truly has private files, the owner should set up a private storage location https://documentation.concretecms.org/user-guide/editors-reference/dashboard/system-and-maintenance/files/file-storage-locations outside of the webroot so that permissions can be checked on view as well. That way, even if a authorized user attaches a file, or otherwise links to it, unauthorized users won't be able to view the file.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

