CVE-2026-8140
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
Concrete CMS version 9.5.0 and below does not validate a CSRF token before processing requests to /dashboard/extend/install/download/<remoteId>. The download() method only checks the canInstallPackages() permission before fetching a remote package and writing it to the DIR_PACKAGES directory. An attacker can force an authenticated administrator to download an arbitrary marketplace package.
Risk Assessment
The risk involves the possibility of an attacker installing a malicious package without the administrator's consent, potentially leading to system integrity compromise and possible control takeover.
Recommendation
It is recommended to immediately upgrade to a version above 9.5.0, which includes a fix enforcing CSRF token validation for this endpoint.
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 does not validate a CSRF token before processing requests to /dashboard/extend/install/download/<remoteId>. The download() method in concrete/controllers/single_page/dashboard/extend/install.php checks only the canInstallPackages() permission before fetching a remote marketplace package and writing it to the server's DIR_PACKAGES directory. Because the endpoint is a state-changing GET route with no token enforcement, an attacker who can cause an authenticated administrator to visit a crafted page can force an arbitrary marketplace package to be downloaded. In order to be vulnerable, the victim must be passing canInstallPackages() and the site must be connected to the Concrete marketplace. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

