Vulnerabilidades

GetSimple CMS is a content management system (CMS), and GetSimple CMS CE is the community edition of that CMS. In versions 3.3.22 and prior, an authenticated stored Cross-Site Scripting (XSS) vulnerability exists in the page backup viewer (admin/backup-edit.php). Page fields are correctly HTML-encoded when a page is…

GetSimple CMS is a content management system (CMS), and GetSimple CMS CE is the community edition of that CMS. Prior to version 1.5, the UpdateCE update form contained no anti-CSRF token, and the POST handler performed no token or request-origin verification. A remote attacker can host a page that auto-submits a…

GetSimple CMS is a content management system (CMS), and GetSimple CMS CE is the community edition of that CMS. Prior to version 1.5, the update handler fetches a user-supplied URL with file_get_contents() after only format validation (FILTER_VALIDATE_URL) — there is no validation of the request destination. An…

Concrete CMS Community Store before 2.7.8 derives digital product download tokens from order creation timestamps instead of random values, making tokens predictable. Unauthenticated attackers can enumerate sequential order and file identifiers to calculate valid download tokens and retrieve digital goods purchased by…

A vulnerability was found in DedeCMS up to 5.7.118. The affected element is an unknown function of the file plus/mytag_js.php. The manipulation of the argument aid results in code injection. The attack can be launched remotely. The exploit has been made public and could be used.

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…

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…

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…

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…

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…

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…

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 when the associated entry was…

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…

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…

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…

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…

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…

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…

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…

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…

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…

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…

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 non-sensitive field could change another…

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…

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…