| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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.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 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, where Date::getTimezoneDisplayName() returns any non-IANA value unchanged. A stored cross-site scripting payload saved in this field executed in an administrator's browser when they viewed the affected user in the Dashboard, running script in the admin session (for example to read CSRF tokens, create administrator accounts, or change site settings). In Concrete CMS 9.5.3 the field became reachable by unauthenticated visitors through public registration; in Concrete CMS below 9.5.3, the same field was reachable by any authenticated user through the account profile editor. Exploitation required concrete.misc.user_timezones to be enabled (off by default), and the unauthenticated path additionally required public registration to be enabled. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.7 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Suraj Bhosale for reporting. |
| Concrete CMS before 9.5.4 did not sanitize XML and XSLT documents uploaded through a public Form Block file-upload question. Plain XML uploads were validated by file extension only and stored as publicly accessible files that were served inline from the application's own origin. An unauthenticated visitor could therefore store an XML document containing an xml-stylesheet processing instruction that referenced an attacker-supplied, same-origin XSLT stylesheet. When a victim opened the stored file directly in a browser, the browser fetched the stylesheet, transformed the document into HTML, and executed attacker-controlled JavaScript in the Concrete CMS origin (stored cross-site scripting). If the victim was an authenticated administrator, the script could act with that administrator's session, and the reporter demonstrated creation of a new user in the Administrators group. 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:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Valentin SARRE (Independent security researcher) for reporting. |
| 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.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.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 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 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.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 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 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 8.3.0 to 9.5.2 stored calendar event names without sanitization and rendered them without HTML escaping in the workflow approval and deletion notifications shown in the dashboard "Waiting For Me" block. A registered user permitted to add events to a calendar governed by an approval workflow could submit an event whose name contained a script payload, which then executed in an administrator's browser when the pending request was displayed and could be used to create a new administrator account. 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 v01demort for reporting. |
| Concrete CMS 9 (9.0.0 through 9.5.2) does not perform an authorization check on the user selector autocomplete endpoint (/ccm/system/user/autocomplete), which backs the "Preview as User" panel and other user-selector components. The endpoint validates only a CSRF-style access token that is bound to the selector's display options rather than to the caller's identity or permissions, and that token is issued to anonymous visitors because the selector renders without an authorization check. Because an empty query resolves to a match-all filter, an unauthenticated attacker can submit an empty search and paginate the results to enumerate every backend account, disclosing the internal user ID, username, and email address of all administrative users, including the super-administrator (user ID 1). No password hashes or session material are disclosed The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 8.7 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks thirtythree and YesWeHack 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 before 9.5.3 contained a stored cross-site scripting vulnerability in SVG file handling. When SVG processing was set to the non-default "Reject files containing potentially harmful elements" mode (concrete.file_manager.images.svg_sanitization.action = reject), uploaded SVGs were checked only against a small built-in blocklist covering the script element and on* event-handler attributes; the broader enshrined/svg-sanitize pass still ran, but its result was discarded, so vectors it would have stripped, such as a javascript: URI in an xlink:href, were stored unmodified and executed when the file was opened directly. A user able to upload files could thereby run arbitrary JavaScript in the browser of any user who viewed the file. The default sanitize mode was not affected. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 1.8 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Oriol Ortiz 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. |
| In Concrete CMS below CMS 9.5.3, the save_control action in the Express entities forms dashboard controller did not validate the anti-CSRF token. By causing an authenticated administrator to submit a forged cross-site request, a remote attacker without credentials could write attacker-controlled headline and body values to an existing Express form Text control. Those values were emitted without output encoding by the Express form Text element, so the injected markup executed as persistent JavaScript for any administrator who later opened the affected entry, resulting in stored cross-site scripting. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.7 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
