| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Pakung for reporting. |
| n 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 and further compromise. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. |
| Concrete CMS before 9.5.4 re-authorized OAuth REST API requests from the bearer token alone and did not re-check the state of the account the token had been issued to. The resource server's authorization validator confirmed only that a token existed, had not expired, and had not been explicitly revoked, and deactivating a user did not revoke that user's outstanding tokens. As a result, a deactivated user retained full access to /ccm/api/1.0/* for the remaining lifetime of any token already issued to them. The same gap applied to accounts that had been deleted or locked pending a forced password reset. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Myq Larson for reporting. |
| 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. For Express entities that do not support entry-specific permissions (i.e., supportsEntrySpecificPermissions() returns false), per-entry permission filtering is additionally disabled via EntryList::ignorePermissions(). The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Daniel Powell for reporting. |
| Concrete CMS before 9.5.3 applied only trim() to the YouTube block's stored width and height values and printed them into iframe HTML attributes without escaping or integer casting, resulting in stored cross-site scripting. A user with edit_block permission could inject an event handler that executed script for visitors rendering the page, acting with administrative privileges where the victim was an administrator. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks sh4d0byss for reporting. |
| 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 panel's check endpoint returned the submitted path unmodified in its JSON response, and client-side JavaScript inserted each value into the dialog as raw HTML, so a crafted page path executed script in the editor's authenticated browser session. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| 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, which allowed the payload to be delivered through an auto-submitting cross-origin POST without authentication. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| 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, which relied solely on CSRF token validation. Because the token is bound to the user and action rather than to a specific block, page, or form, an authenticated user with edit access to one Express Form could reuse a validly obtained token to add, modify, or delete controls on Express Forms they were not authorized to edit, including injecting a control whose value is later rendered as HTML to achieve stored XSS. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Yat Wu for reporting. |
| Concrete CMS 9 through 9.5.2 is vulnerable to Server-Side Template Injection (SSTI) in Theme Customizer via Unvalidated Style Values. Values submitted through the customizer (color channels and other style properties handled by ColorStyle and sibling Style classes such as FontFamilyStyle and ImageStyle) are interpolated into server-compiled LESS source without neutralization of LESS syntax, allowing a user with the Theme Customization permission to inject arbitrary LESS directives. By injecting the @import (inline) directive, an attacker can read arbitrary files on the server and reach internal network resources through PHP stream wrappers. The compiled output, including any disclosed file contents, is written to the site's publicly served CSS cache, exposing database credentials, private keys, and other application secrets, and enabling server-side request forgery. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.9 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| Concrete CMS 9.0.0 to 9.5.2 is vulnerable to Server-Side Request Forgery iremote file import via cross-port reuse of a host's validated DNS pin. When multiple remote URLs share the same host, only the first `ValidatedRemoteUrl` is retained and reused for every later URL with that host. A low-privileged authenticated user permitted to import files could therefore supply a DNS-rebinding host that resolved to a public address during validation and to a private or loopback address during the unpinned download, causing the server to fetch internal-only resources such as loopback services, internal admin panels, or cloud metadata endpoints and to save the responses into the file manager. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N. Thanks Ahmad Wicaksono (sonix03) for reporting. |
| Concrete CMS 9 before 9.5.3 authorized the dashboard sitemap reorder action (Concrete\Controller\Backend\Dashboard\SitemapUpdate) using only the global access_sitemap task permission and did not check per-page edit permission before updating each page's display order. As a result, an authenticated user granted sitemap access could change the display order (cDisplayOrder) of any pages they had no rights to edit, altering the order in which those pages render in navigation, breadcrumb, and page-list output. The reorder action additionally validated no CSRF token, so the write could be triggered by a forged request. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. |
| Concrete CMS 9.0.0 through 9.5.2 was missing an authorization check on the Express entries advanced-search dashboard action. The advanced_search() method in DashboardSelectableExpressEntryListTrait resolved an Express entity directly from a user-supplied entity ID and rendered that entity's entries without invoking canViewExpressEntries(), the per-entity permission check that the sibling results() action enforced. An authenticated dashboard user holding view_express_entries on a single Express entity could read the entries of any other entity, including secret attribute values, by requesting the advanced-search action with that entity's ID, disclosing form submissions and CRM-style records across the per-entity permission boundary that Express is designed to enforce. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. |
| Concrete CMS 9.0.0 to dashboard group type controller did not validate a CSRF token on its delete action, resulting in cross-site request forgery. A remote unauthenticated attacker could cause an authenticated user with group type management permission to delete a custom group type. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks riodrwn for reporting. |
| Concrete CMS 9 through 9.5.2 does not perform an authorization check in three actions of the Boards data source dashboard controller (update, update_data_source, and delete_data_source), which resolve a ConfiguredDataSource directly from an attacker-supplied identifier without confirming the requester's edit permission on the owning board. A user granted edit_board_settings on a single board was therefore able to modify or permanently delete the configured data sources of any other board on the site, halting the affected board's content feed and resetting its custom weighting. The CSRF token that guards these actions was validated but bound to the action name rather than to the target object, so a token legitimately obtained for one board could be replayed against another board's ConfiguredDataSource identifier and did not constrain access. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. |
| Concrete CMS before 9.5.3 is vulnerable to Cross-Site Request Forgery (CSRF) in the theme page-template activation feature. The Dashboard theme Inspect controller's activate_files() action created PageTemplate records from attacker-supplied pageTemplates[] values without validating an anti-CSRF token.A remote attacker could host a page that auto-submitted a forged POST request; when a signed-in administrator visited it, the request executed under the administrator's session and created theme page-template records, changing site configuration without the administrator's consent. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting. |
| Concrete CMS 9 before 9.5.3 did not escape SQL LIKE wildcard characters in the keyword search filters used by the file manager, file folders, and page list, allowing an authenticated user with editor-level or higher privileges to submit a crafted search containing many single-character wildcards. Because the keyword input was placed into the LIKE clause without neutralizing its wildcard metacharacters, a short request could force the database to evaluate every row and perform a full-table scan, and repeated or wildcard-dense searches could sustain elevated database CPU and I/O, degrading responsiveness for other users on large installations. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N. Thanks noivan for reporting. |
| Concrete CMS 9 through 9.5.2 did not perform an authorization check on several board-instance actions in the Boards area of the Dashboard. The instance details single-page controller resolved a board instance directly from an attacker-supplied instance ID and then viewed, refreshed, regenerated, or deleted it without verifying that the requester held edit_board_settings on the instance's parent board. As a result, a user granted board-edit rights on a single board could reach the instances of any other board on the site by supplying their instance IDs. The affected actions bypassed the controller's permission-checked accessor (the same accessor used by the read view, which runs canEditBoardSettings on the parent board) and validated only an action-scoped CSRF token, which is bound to the action name rather than to the target object and is therefore reusable across boards. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. |
| Concrete CMS before 9.5.3 did not enforce a destination-side authorization check and did not validate a CSRF token in the multilingual page assignment backend action (Backend\Page\Multilingual::assign). As a result, an authenticated user who held the Edit Page Multilingual Settings permission on a single page could bind an arbitrary page in another locale as that source page's translation, and could delete legitimate translation pairs maintained by other editors, altering public-facing language routing across the site. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Winston Crooker for reporting. |
| Concrete CMS 9.0.0 through 9.5.2 is vulnerable to Insecure direct object reference (IDOR) in the Express saved search preset delete and edit dialogs . An authenticated user holding only view permission on a single Express entity could therefore permanently delete, with no undo, or rename saved search presets owned by Express entities for which they had no permission, and a renamed preset name was displayed back to users of the targeted entity, enabling defacement or social engineering. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Yalguun Tumenkhuu ( fg0x0 ) for reporting. |
| Concrete CMS 9.0.0 to 9.5.2 stored group folder names without sanitization and printed them unescaped on the Members > Groups dashboard page, resulting in stored cross-site scripting. The add and edit group-folder handlers stored the submitted folder name without neutralizing HTML, and the group search grid returned it without output encoding, so the Groups dashboard rendered the name as live markup. An authenticated user holding the Add Group Folder permission could store a script payload as a folder name that executed in the session of any administrator who viewed the Groups dashboard, enabling session and token theft and any action available in the administrator's context. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Lý Chấn Hưng (hunglyvn) for reporting. |
