Concrete CMS vulnerabilities

Concrete CMS versions 9.5.0 through 9.5.2 are vulnerable to Open Redirect via the rcURL parameter. An attacker can craft a link on the site's own domain that sends a user to an arbitrary external site after authentication, facilitating phishing and credential theft. The same handling is present in the registration flow.

Concrete CMS before 9.5.3 is vulnerable to Cross-Site Request Forgery in the Move Multiple Groups feature. The dashboard/users/groups/bulkupdate/confirm() endpoint moved selected group tree nodes without validating an action token, so a state-changing group move could be processed for an authenticated user who did not initiate it. Relocating a group under a new parent causes its members to inherit the parent's permissions.

Concrete CMS versions 9.0.0 to 9.5.2 is vulnerable to Stored XSS in Board Custom Slot dialog. The custom_slot save_template endpoint authorizes the request only against the target board instance and then persists the client-supplied selectedTemplateOption[collection] verbatim, allowing a user with permission to edit board contents to store a forged summary object with a JavaScript-bearing HTML payload in the description field. The default summary template renders the description field without output encoding.

Concrete CMS before 9.5.3 did not validate an anti-CSRF token in the Calendar event duplicate dialog controller (concrete/controllers/dialog/event/duplicate.php) submit() action, which duplicated a calendar event after checking only canAccess() and the per-resource canAddCalendarEvent() permission. A crafted cross-site request could cause an authenticated user with add-event permission to create duplicate CalendarEvents and CalendarEventVersions records.

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, with the compiled output written to the publicly served CSS cache.

Concrete CMS 9 through 9.5.2 is vulnerable to Missing Authorization in the block alias route (Process::alias() in concrete/controllers/backend/block/process.php). It does not verify that the referenced block is genuinely orphaned on the target page, nor that the caller holds any permission over the source block. A user granted only an area-scoped add_block_to_area delegation on their own page can pass any block ID on the site, causing the source block's content to be duplicated into an area the rogue editor controls, disclosing that content, and the original block is then force-deleted in the same request.

Concrete CMS 9.2.0 to 9.5.2 contain a missing authorization vulnerability in the REST API Groups list endpoint. The listGroups() method in concrete/src/Api/Controller/Groups.php registers a permissions checker callback that unconditionally returns true, so no per-object (tree node) authorization is enforced when the group collection is returned. An authenticated user whose API token carries the groups:read scope can call GET /ccm/api/1.0/groups and receive every group on the site regardless of view permissions.

The Concrete CMS RSS Displayer block below version 9.5.3 rendered remote feed item titles without HTML escaping, resulting in stored cross-site scripting. An attacker able to control a title in a syndicated feed could execute script in the site origin for any visitor to the affected page, including administrators, without holding an account on that site.

In Concrete CMS 9.2.0 to 9.5.2, the Express REST API list endpoint exposes restricted Express entries via Missing Authorization; the per-entry view permission check was disabled. An OAuth token with read scope for an Express entity could enumerate entries that its user context lacked permission to view, disclosing each entry's public identifier, URL, label, dates, and any attribute or associated-entry data requested via the includes parameter.

Concrete CMS OAuth callback login path prior to version 9.5.3 did not check whether an account was active or email-validated before establishing a session. A deactivated or unvalidated user with an existing OAuth binding could complete authentication and receive a session that was fully authenticated for the callback response, with the login recorded and login events dispatched.

Concrete CMS below 9.5.3 stores user validation hashes for multiple purposes (email/registration validation, password reset, and persistent login) in a single table with a type column, but the redemption path resolves a hash by value alone and does not verify its type. As a result, a hash issued for one purpose can be redeemed for another: a long-lived registration hash (60-day expiry) can be submitted to the password-change endpoint to set a new password on the target account, and a password-reset hash can be submitted to the email-validation endpoint to activate an account. Exploitation requires the attacker to first obtain a valid hash through a separate channel (for example email interception, log exposure, or SSRF against an internal mail relay), so the flaw amplifies the impact of any hash disclosure rather than creating a standalone entry point.

Concrete CMS 9.5.2 and below is vulnerable to an authorization bypass (IDOR) because the frontend calendar lightbox endpoint (/ccm/calendar/view_event/{bID}/{occurrence_id}) does not verify that the caller is permitted to view the calendar that owns the requested event occurrence. The controller loads the occurrence directly from an attacker-supplied, sequential identifier without confirming that it belongs to the calendar configured on the referenced block. An unauthenticated visitor who can render any public calendar block with lightbox properties enabled could therefore supply an arbitrary occurrence identifier and disclose event metadata — title, date, description, page link, and configured event attributes — from calendars they are not permitted to view.

Concrete CMS 9 through 9.5.2 did not validate an anti-CSRF token in the Boards custom slot dialog controller (concrete/controllers/dialog/board/custom_slot.php) saveTemplate() action. The action created a board_slot_proxy Block and dispatched an AddCustomSlotToBoardCommand against a board instance while gating only on the per-resource canEditBoardContents() permission, so a crafted cross-site request could cause a user holding board-edit permission with an active session to write attacker-chosen slot and template data to a board under their own authority. The state-changing database write completed before any downstream rendering, so the forged request succeeded even when the HTTP response returned a non-200 status.

Concrete CMS versions 8.3.0 through 9.5.2 contain an authorization bypass in the Calendar event edit dialog. Permissions were checked against the calendar identifier supplied in the request rather than the calendar owning the targeted event, allowing a user with "Add Event" permission on one calendar to read and overwrite events on calendars they were not permitted to access.

Concrete CMS below 9.5.3 registered view assets for every sub-block of a Stack, Container, or layout area without checking whether the requesting user could view that sub-block. An unauthenticated visitor could recover configuration values emitted by a restricted sub-block's asset registration — such as a site's configured Google Maps API key — from any public page embedding an affected Stack, Container, or layout area, despite the block-level permission restriction.

The CVE report was rejected. Reason: Vendor could not replicate the vulnerability, and the reporter is unavailable to comment.

Vulnerability in Concrete CMS below version 9.5.2 allows an unauthenticated attacker to perform PHP object injection via unserialize() calls in Permission, Cache, and Search components. The attack requires a malicious payload to be placed in the database.

Concrete CMS below 9.5.3 is vulnerable to PHP Object Injection via unserialize() calls in the Workflow, Form block, and File/Set components that lack the allowed_classes restriction. The Form block and File/Set sinks were addressed in 9.5.2; the Workflow component sinks were addressed in 9.5.3. An unauthenticated attacker may trigger arbitrary PHP object instantiation if a malicious serialized payload has been placed in the database.

Concrete CMS versions 9.0 to 9.5.0 are vulnerable to Stored XSS via page name in the Atomik theme. A rogue editor can inject arbitrary JavaScript that executes in the context of any authenticated user visiting the affected account pages.

Concrete CMS 9.5.0 and below is vulnerable to IDOR + wrong-authorization-level in the Express association Reorder dialog. This can cause Cross-entity state tampering with view-only permission on one entry. To be affected, a website has to be using express and relying on express entity ordering.

Concrete CMS version 9.5.0 and below is vulnerable to CSRF via Backend\File::approveVersion. A victim with edit_file_contents permission can be tricked into publishing an attacker-chosen previously-uploaded file version (downgrade or activation of an unpublished version).

Concrete CMS 9 before version 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) in the approveVersion() controller. An attacker can exploit this vulnerability to perform unauthorized actions on behalf of an administrator.

Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/backend/file rescanMultiple(). An attacker can trick an administrator into performing unwanted file operations.

Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/backend/file rescan(). An attacker can trick an administrator into rescanning a file.

Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/backend/file star(). An attacker can trick an administrator into starring a file.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the removeFavoriteFolder($id) endpoint. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the addFavoriteFolder($id) endpoint. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the reorder endpoint of the Express Association dialog. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the duplicate endpoint of the Event dialog. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the design endpoint of the Page Bulk dialog. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the cache endpoint of the Page Bulk dialog. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to CSRF in the delete endpoint of the Page Bulk dialog. An attacker can exploit this to perform unauthorized actions on behalf of the victim.

Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/dialog/logs/bulk/delete. CVSS v4.0: 2.3.

Concrete CMS 9 before 9.5.0 is vulnerable to Cross-Site Request Forgery (CSRF) at concrete/controllers/dialog/logs/delete. CVSS v4.0: 2.3.

IDOR vulnerability in Concrete CMS 9.5.0 and below allows unauthenticated attackers to vote in restricted surveys via a public endpoint.

Concrete CMS below 9.5.0 and below is vulnerable to password change without reauthorization and session-hardening bypass. The user-profile edit controller passes the entire raw POST array to UserInfo::update() without field whitelisting resulting in password change without requiring the current password and also resulting in registered users able to disable the per-user-IP-pinning in the session validator which is meant to detect hijacking.

Concrete CMS version 9.5.0 and below is vulnerable to Reflected XSS in Legacy Pagination via HTML attribute injection. The pagination function directly interpolates the $URL field into the href attribute, allowing an authenticated admin or report viewer to execute JavaScript by clicking a crafted link.

Concrete CMS 9.5.0 and below is vulnerable to unauthenticated page metadata disclosure across every page with a configured summary template, revealing the existence of private, draft, and restricted pages while leaking title, path, description, and author information.

Concrete CMS 9.5.0 and below is vulnerable to IDOR. The '/ccm/frontend/conversations/get_rating' endpoint confirms existence and returns rating score for any message by ID.

Concrete CMS 9.5.0 and below is vulnerable to IDOR. The '/ccm/frontend/conversations/message_page' endpoint returns the full content of any conversation message. An unauthenticated attacker can enumerate all conversation messages, including messages from restricted pages, member-only areas, and the moderation queue. File attachments with download URLs are also exposed.

Concrete CMS 9.5.0 and below is vulnerable to IDOR. The '/ccm/frontend/conversations/message_detail' endpoint returns the full content of any conversation message. An unauthenticated attacker can enumerate all conversation messages, including messages from restricted pages, member-only areas, and the moderation queue. File attachments with download URLs are also exposed.

Concrete CMS 9.5.0 and below is vulnerable to IDOR combined with a missing authentication gate. The endpoint '/ccm/system/dialogs/file/usage/{fID}' accepts an integer file ID in the URL and returns internal site structure data (page IDs, versions, URL paths) to anyone who sends a GET request.

Concrete CMS 9.5.0 and below is vulnerable to Stored XSS via external-link page cvName because updateCollectionAliasExternal bypasses sanitization. A rogue editor can inject arbitrary JavaScript.

In Concrete CMS 9.5.0 and below, the RSS Displayer block accepts a feed URL from any page editor and fetches it server-side without validation, enabling redirect-to-internal bypasses.

In Concrete CMS 9.5.0 and below, OAuth 2.0 Authorization-Code Handler bypasses account status. A user with uIsActive=0 (suspended, banned, terminated employee) can still authenticate via OAuth and receive valid API tokens.

Concrete CMS version 9.5.0 and below is vulnerable to IDOR in the AddMessage and UpdateMessage controllers via the attachments[] parameter. They lack per-file permission checks (canViewFile()), allowing a user who can post in any conversation to reference any file in the CMS file manager by its ID, bypassing the permission system.

Concrete CMS version 9.5.0 and below is vulnerable to unauthorized file deletion due to an inverted CSRF token check in the DeleteFile controller. The CSRF token is rejected when valid and accepted when invalid, enabling CSRF attacks against users with permission to edit conversation messages.

Concrete CMS 9.5.0 and below is subject to Insecure Direct Object Reference (IDOR) in the Express Entry Detail block via the exEntryID parameter. This IDOR leads to unauthorized access to all Express form submissions.

In Concrete CMS 9.5.0 and below, the submit_password() method in concrete/controllers/single_page/download_file.php allows unauthorized file access since downloading permission-restricted files bypasses the view_file permission check. Files without passwords can be downloaded and any user who knows a file's password can download a password protected file regardless of whether they have permission to access the file.

Concrete CMS 9.5.0 and below emits a CSRF token in the local_available_update.php view, but the do_update() method does not validate it. An attacker can exploit this to perform a CSRF attack that updates the CMS to an attacker-specified version.