Concrete CMS vulnerabilities

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

Concrete CMS 9 before 9.5.3 authorized the dashboard sitemap reorder action using only the global access_sitemap task permission and did not check per-page edit permission before updating each page's display order. An authenticated user with sitemap access could change the display order of pages they had no rights to edit. The reorder action also lacked CSRF token validation.

Concrete CMS 9.0.0 to 9.5.2 is vulnerable to Server-Side Request Forgery in remote file import due to cross-port reuse of a host's validated DNS pin. A low-privileged authenticated user could supply a DNS-rebinding host that resolved to a public address during validation and to a private or loopback address during download, allowing the server to fetch internal-only resources and save them to the file manager.

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 with only view permission on a single Express entity could permanently delete or rename saved search presets owned by entities they had no permission for, and a renamed preset name was displayed back to users, enabling defacement or social engineering.

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. An authenticated user with Edit Page Multilingual Settings permission on a single page could bind an arbitrary page in another locale as that source page's translation and delete legitimate translation pairs, altering public-facing language routing.

Concrete CMS before 9.5.3 is vulnerable to Cross-Site Request Forgery (CSRF) in the theme page-template activation feature. The activate_files() action created PageTemplate records from attacker-supplied 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, changing site configuration without consent.

In Concrete CMS before 9.5.3, the SEO Bulk Update Meta Tags editor did not check per-page edit permissions before saving. The saveRecord() action validated the per-page CSRF token but never called canEditPageProperties() for the target page, so a user with access to the bulk SEO tool and view (but not edit) permission could change the page's meta title, meta description, and URL handle, tampering with presentation and live URLs of protected content.

Concrete CMS before 9.5.3 did not enforce a per-page authorization check when reordering pages from the sitemap. In the sitemap Explore dashboard controller, the send_to_top and send_to_bottom reorder tasks ran after only a generic sitemap-access check; the controller loaded the page named by the attacker-controlled cNodeID parameter and changed its display order without verifying that the current user held move or arrange permission on that specific page. An authenticated user with sitemap access but no edit or arrange rights could still move the page and alter the site's global navigation order.

Concrete CMS 8.5.3 through 9.5.2 enabled the OAuth 2.0 refresh-token grant using the unmodified upstream League grant, which issued new access tokens from a valid refresh token without re-checking the associated account's active status. A user who obtained a refresh token while active could continue to mint valid access tokens after being deactivated or suspended (uIsActive=0), so deactivating an account did not revoke its API access.

Concrete CMS below 9.5.3 was vulnerable to Cross-Site Request Forgery in the dashboard SEO Excluded Words page. The reset() controller action cleared the administrator-configured reserved-word list without validating the anti-CSRF token or restricting the request to POST. A remote attacker could lure an authenticated user with SEO access to a crafted page, reverting the reserved-word list to default and silently altering future URL-slug generation.

Concrete CMS below 9.5.3 did not validate an anti-CSRF token on the block-arrangement backend endpoint (the arrange() action of Concrete\Controller\Backend\Page\ArrangeBlocks). The action enforced page-edit authorization but performed no token check, and its route accepted any HTTP method. An attacker could induce a signed-in content editor into loading an attacker-controlled page that auto-submitted a cross-site request and reordered or moved blocks in the draft version of a page.

Concrete CMS before 9.5.3 rendered Express entry labels as raw HTML when displaying associated entries, resulting in stored cross-site scripting. An unauthenticated attacker could submit a payload through a public Express Form; it then executed in an administrator's dashboard session or in the browser of any visitor to a page using an Express Entry List block.

Concrete CMS below 9.5.3 conversation attachment uploaded endpoint imported files into the file manager before evaluating the "Add Message Attachments" permission, which was only checked after the file had been stored. A user denied that permission, or an unauthenticated visitor on a guest-posting configuration, could import approved files of allowed types into the file manager.

Concrete CMS 9.0.0 to 9.5.2 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.

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. An authenticated user with editor-level or higher privileges could submit a crafted search containing many single-character wildcards, forcing the database to perform a full-table scan and degrading responsiveness.

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 controller resolved a board instance directly from an attacker-supplied instance ID and then viewed, refreshed, regenerated, or deleted it without verifying edit_board_settings on the parent board. A user with board-edit rights on one board could reach instances of any other board.

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 resolved an Express entity directly from a user-supplied entity ID and rendered that entity's entries without invoking canViewExpressEntries(), allowing an authenticated dashboard user with view_express_entries on one entity to read entries of any other entity, including secret attribute values.

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 edit permission on the owning board. A user with edit_board_settings on one board could modify or permanently delete data sources of any other board.

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. 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.

In Concrete CMS below version 9.5.3, the Address attribute's country-less text formatter skipped HTML-escaping, enabling stored XSS in Express association views. A user able to submit an Address attribute could execute script in the session of any dashboard user who opened the affected entry.

Concrete CMS 9.2.0 to 9.5.2 did not enforce per-field edit_user_properties permissions on the REST API user write endpoints (PUT /ccm/api/1.0/users/{uID} and POST /ccm/api/1.0/users/{uID}/change_password). A user with an update-scoped OAuth token and permission to edit only one field could change another non-superuser's password, username, email, and attributes, taking over that account.

In Concrete CMS 9.0 to 9.5.2, the Top Navigation Bar block did not HTML-escape dropdown child page names before writing them into the page. A user who could create or rename pages could store a script through a child page name that would run in the browser of any visitor, editor, or administrator viewing the navigation.

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.

Concrete CMS before 9.5.3 does not apply HTML entity encoding to user-defined Form block question labels when rendering them as column headers in the Dashboard Form Submissions report (concrete/single_pages/dashboard/reports/forms/legacy.php). a rogue editor could store markup or script in a label that then executes in the browser of any administrator who opens the submissions report for the affected form, producing stored cross-site scripting in the Dashboard.

In Concrete CMS before 9.5.3, the Document Library block stored the file-set identifiers submitted through fsID[] without validating them as integers, and when the block was configured with setMode set to any it concatenated each stored identifier directly into the file-set filter query instead of casting it or binding it as a parameter. An authenticated user permitted to add or edit a Document Library block could therefore persist SQL syntax in the block configuration (btDocumentLibrary.setIds), and that stored expression was executed every time the published page containing the block was rendered, producing stored, time-based blind SQL injection.

Concrete CMS 9.5.2 and below is vulnerable to stored DOM-based Cross-site Scripting (XSS) via the Gallery block's per-image Caption field because the bundled Magnific Popup lightbox script (concrete/js/features/imagery/frontend.js) re-parses the attribute-decoded caption as HTML through jQuery's .append() in titleSrc instead of inserting it as text. A user with permission to edit a page containing a Gallery block can store a caption that executes in the browser of any visitor who opens that image's lightbox.

Concrete CMS 9 before 9.5.3 and Concrete 8.5.21 contain a stored XSS vulnerability in the Feature, Feature Link, Hero Image, and Image blocks. The external link URL was insufficiently validated and rendered without output escaping, allowing a user with page-editing permissions to inject arbitrary JavaScript.

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). The endpoint only validates a CSRF-style token that is not bound to the caller's identity or permissions, and the token is issued to anonymous visitors.

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.

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.

Concrete CMS 9.0.0 through 9.5.3 is vulnerable to stored XSS via the custom page alias name (customAliasName) because the Edit Alias dialog applied only trim() to the submitted value and performed no input neutralization. An authenticated user holding canWrite (editor) permission on a page could store a malicious alias name that was later rendered unescaped in the administrative Sitemap panel, where it executed automatically in any administrator or editor session that opened the panel, allowing an editor to escalate to administrator through the victim's active session.

Concrete CMS versions 9.0.0 to 9.5.2 stored the Page Container icon value submitted through the dashboard without validating it against the set of known container icons. The unvalidated value was later concatenated into the src attribute of an img tag by a helper that did not encode attribute output, and was rendered raw in the Containers dashboard list and editor views. A user with delegated access to the Page Containers dashboard could store a crafted icon value that broke out of the src attribute and executed script in the authenticated session of another editor or administrator who viewed the list, enabling session token theft and privileged dashboard actions. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.0 with vector CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Andrew Gonzalez for reporting.

Concrete CMS 9 through 9.5.2 did not validate a CSRF token in the orphaned block removal panel action (removeOrphanedBlocks). A remote attacker could craft a request that, when loaded by an authenticated user holding edit permission on the target page, deleted every block on that page's current version; blocks not aliased to another page or scrapbook entry were also removed from the global Blocks table and their block-type data table, permanently destroying the content. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.1 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.

In Concrete CMS 9.2.0 through 9.5.2, the REST API page update endpoint (PUT /ccm/api/1.0/pages/{cID}) did not enforce page-property, page-template, or page-type authorization. A user granted only content-editing rights on a page could therefore alter its properties, template, and type through the API, and could set the header_extra_content attribute, which is rendered unescaped into the head element of every page, to persist JavaScript that executed in the browser of every visitor, including higher-privileged reviewers who approve the page version. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.2 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.

Concrete CMS below 9.5.3 is vulnerable to stored XSS via the Date Format field in the Page Attribute Display block. A user with edit_page_contents permissions could store a payload that executes in the browser of any visitor viewing a page where the block displays a date-type attribute.

Concrete CMS below 9.5.3 does not apply HTML output escaping to the file description and tags fields when rendering the Document Library block. A user with permission to edit file properties could store a script payload that executes in the browser of any visitor to a page displaying the block with the description or tags column enabled, including unauthenticated visitors.

Concrete CMS 9.5.2 and below is vulnerable to CSRF in the Express "Clear Entries" function (POST /index.php/dashboard/system/express/entities/delete_entries) because the controller records but does not enforce a failed CSRF token check. A remote unauthenticated attacker can force an authenticated administrator visiting an attacker-controlled page to permanently delete all entries of an attacker-selected Express entity.

Concrete CMS Area API's block-create endpoint in versions 9.2.0 to 9.5.2 did not invoke the block type controller's validate() method on submitted data, which for file-referencing blocks (e.g., hero_image, gallery) is where the referenced file is authorized against the user's file-manager visibility. This allowed an authenticated user with block-add scope to store and render a reference to a file that would otherwise be rejected, disclosing its URL and preview.

Concrete CMS before 9.5.3 evaluated the authorization check for an Express entry submission against the entity of the posted form rather than the entity identified by the dashboard route. A user permitted to add entries to one Express object could create entries in a different Express object outside their authorization scope.

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.