Vulnerabilidades

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…

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…

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…

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 who was granted access to the bulk SEO tool and could view (but not…

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…

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 therefore continue to mint…

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 (concrete.seo.exclude_words) but did not validate the anti-CSRF token that the reset modal emitted, and it did not…

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, so an attacker could induce…

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…

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. The unescaped branch was…

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, so a user who could create or rename pages could store a script through a child page name and have it run in the browser of any visitor, editor, or administrator who viewed the…

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…

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

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…

Concrete CMS 9 before 9.5.3 was vulnerable to stored cross-site scripting (XSS) in the Feature, Feature Link, Hero Image, and Image blocks and before Concrete 8.5.21 in the feature and Image blocks because the external link URL was insufficiently validated by the link filter and was rendered without output escaping. A…

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…

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…

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…

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…

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…

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…

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…

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. The Concrete CMS security team gave this…

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…