Threat database

MaxSite CMS 109.5 and earlier contains an authentication bypass vulnerability in the AJAX dispatcher that allows unauthenticated attackers to access admin-gated endpoints by supplying any X-Requested-With header and requesting a base64-encoded path resolving to any *-ajax.php file in the codebase. Attackers can exploit this dispatcher bypass to reach privileged plugin endpoints without credentials, enabling actions such as manipulating poll states and vote counts, and amplifying the impact of any dangerous operation performed by admin-only ajax files across the plugin tree.

Statamic is a Laravel and Git powered content management system (CMS). Prior to 5.73.24 and 6.20.1, form submission values in src/Forms/Exporters/CsvExporter.php were not neutralized for spreadsheet formula characters when exported to CSV. A submission containing a value beginning with a formula trigger character, such as =, +, -, or @, could be interpreted as a live formula when a Control Panel user opens the export in a spreadsheet application. Form submissions can come from unauthenticated front-end visitors, so the malicious value can be supplied by an anonymous user and is later triggered by an editor opening the export. This issue is fixed in versions 5.73.24 and 6.20.1.

Statamic is a Laravel and Git powered content management system (CMS). Prior to 5.73.24 and 6.20.1, the Glide image proxy's URL validation in src/Imaging/RemoteUrlValidator.php and src/Imaging/GuzzleAdapter.php could be bypassed using DNS rebinding. The remote hostname was validated as publicly routable, but resolved again when the image was actually fetched, so an attacker controlling the hostname's DNS could rebind it to an internal address after validation and cause the server to make HTTP requests to internal addresses, including loopback, private network, and cloud metadata endpoints. This affects sites that pass user-supplied URLs to Glide. This issue is fixed in versions 5.73.24 and 6.20.1.

Statamic is a Laravel and Git powered content management system (CMS). Prior to 5.74.0 and 6.20.3, the Live Preview endpoint for existing entries and terms in src/Http/Controllers/CP/PreviewController.php only checked view authorization, but it accepts and renders caller-supplied field values. A Control Panel user with view but not edit permission could therefore submit content they were not authorized to author and generate a shareable Live Preview URL rendering it. This issue is fixed in versions 5.74.0 and 6.20.3.

Craft CMS is a content management system (CMS). Versions 5.0.0-RC1 and above, prior to 5.9.21 and versions 4.0.0-RC1 and above prior to 4.17.14 contain an authorization issue where a forced folder move can delete a conflicting destination folder without destination delete permission. Function craft\\controllers\\AssetsController::actionMoveFolder() supports moving an asset folder into a destination parent folder. If a folder with the same name already exists at the destination, the action can be called with force=true to overwrite the destination. This issue has been resolved in versions 5.9.21 and 4.17.14.

Craft CMS is a content management system (CMS). Versions 5.7.0 and above, prior to 5.9.21 contain a mass-assignment flaw in the bulk-duplicate element action. An attacker who is only able to duplicate their own entires can submit an arbitrary id through the newAttributes request parameter. The duplication routine overrides its own id = null reset with that value and writes the attacker's attributes into the victim's existing entry row. ElementsController::beforeAction() pulls the request body into $this->_attributes and rejects requests that ship an id or canonicalId key at the top level, actionBulkDuplicate(), reads a separate newAttributes array and passes it straight through to the service layer. Elements::duplicateElement() clones the source element, sets id to null, and then hands the attacker's array to Craft::configure(), which overwrites the reset id with any numeric value inside $newAttributes. PHP Yii's saveElement() then performs an UPDATE against the row with that primary key instead of an INSERT. The attackers's title, slug, authorId, postDate, and UID land on the victim's entry. safeAttributes() on Entry includes id because the base element model exposes it, so the Collection::only() filter does not strip it. This issue has been fixed in version 5.9.21.

Craft CMS is a content management system (CMS). In versions 5.0.0-RC1 and above prior to 5.9.21, the EntriesController::actionMoveToSection() endpoint gates the destination section only by viewEntries:$section->uid rather than requiring saveEntries permission (the source entry is separately checked via Entry::canMove()). As a result, a low-privileged authenticated control-panel user who can move an entry out of its current section can call moveEntryToSection() to rewrite the entry's sectionId and save it into a section where they have read access but no write access. This breaks the section-level authorization model, letting a user with limited permissions inject content into a protected section and interfere with editorial boundaries, approval workflows, and section-specific business logic. This issue has been fixed in version 5.9.21.

Craft CMS is a content management system (CMS). IN versions 5.0.0-RC1 and above prior to 5.9.21, theEntriesController::actionSaveEntry() performs entry-edit permission checks before request-controlled author changes are applied to the model, allowing for authorship spoofing. The subsequent author mutation path accepts attacker-supplied authors / author parameters and allows the change when the current user is one of the old authors. Because the controller does not re-run authorization after mutating the author list, a low-privileged user can reassign an entry’s authorship to another user without holding the dedicated peer-author-change permission. This issue has been fixed in version 5.9.21.

Craft CMS is a content management system (CMS). In versions 5.9.0 and above prior to 5.10.0, control panel users with the ability to edit entries can execute unsandboxed Twig code via the HTTP Referrer header, potentially leading to authenticated RCE. The issue happens when a user is saving entries. Strings for a signed redirect URL are being compiled as a Twig template via renderObjectTemplate(), and while a sandboxed alternative already exists (renderSandboxedObjectTemplate()), it is not used in this case. This signed URL can be specified by users, as it is reflected in the “Referer” HTTP request header, which is under attacker control. This issue has been fixed in version 5.10.0.

Craft CMS is a content management system (CMS). Versions 4.0.0-RC1 and above, prior to 4.18.0 and 5.0.0-RC1, and above, prior to 5.10.0, are vulnerable to Server-Side Request Forgery (SSRF) and Arbitrary JavaScript Injection through the /actions/app/resource-js endpoint. By exploiting the default permissive trustedHosts configuration, an attacker can poison the Host or X-Forwarded-Host header to manipulate the application’s $baseUrl. This bypasses the endpoint’s internal URL validation, forcing the backend Guzzle client to fetch a malicious payload from an attacker-controlled server and reflect it to the client with a Content-Type: application/javascript header. The vulnerability manifests when assetManager.cacheSourcePaths is set to false. This issue has been fixed in versions 4.18.0 and 5.10.0.

Craft CMS is a content management system (CMS). In versions 5.0.0-RC1 through 5.9.22 and 4.0.0-RC1 through 4.17.15, an attacker with only a GitHub account can plant a JavaScript payload in a craftcms/cms issue title. When a Craft admin uses the CraftSupport widget’s "Give feedback" screen and types a search term that returns the poisoned issue, the payload executes in the admin’s control panel session. No control panel account or elevated privileges are required on the attacker’s side. This issue has been fixed in versions 4.17.16 and 5.9.23.

Craft CMS is a content management system (CMS). In versions 5.0.0-RC1 through 5.9.21 and 4.0.0-RC1 through 4.17.14, theAssetsController::actionDeleteFolder() only requires the deleteAssets:<volume-uid> permission for the target folder. It never enforces deletePeerAssets:<volume-uid>, even though Assets::deleteFoldersByIds() cascades deletion to every descendant folder and every asset inside, regardless of the uploader's assigned privileges. A low-privilege user who has been granted folder-management rights on a shared volume can therefore destroy assets uploaded by other users (peer assets), bypassing the per-asset peer-permission check that the sibling actionDeleteAsset endpoint correctly applies. This issue has been fixed in versions 4.17.15 and 5.9.22.

Craft CMS is a content management system (CMS). Versions 5.0.0-RC1 through 5.9.20, and 4.0.0-RC1 through 4.17.13 contain an authorization issue in the AssetsController::actionReplaceFile that can delete a source asset without source delete permission by supplying both assetId and sourceAssetId. AssetsController::actionReplaceFile() supports replacing a target asset file using another existing asset as the source. The action loads: assetId -> $assetToReplace and sourceAssetId -> $sourceAsset, then enforces replace permissions using ($assetToReplace ?: $sourceAsset). When both IDs are provided, this expression resolves to the target asset so no permission check is performed against the source asset volume. When both assets are present, Craft copies the source file into the target and then deletes the source asset. There is no deletion check for for the source asset. An authenticated user who can replace files in one volume can delete assets in another volume where they do not have delete permission, as long as they can obtain a sourceAssetId, leading to broken content references and data loss. This issue has been fixed in versions 4.17.14 and 5.9.21.

Craft CMS is a content management system (CMS). In versions 5.0.0-RC1 through 5.9.22, an author-level control panel user can store a malicious JavaScript payload in an entry title. When an admin, or any control panel user with saveEntries for the same Structure section, drags another entry under the poisoned entry in table view, the payload executes in the victim’s session. The issue is exploitable because the title is escaped into data-title by the server, decoded again by the browser, read with jQuery .data('title'), and then concatenated into a new HTML string without attribute escaping. To exploit, an attacker must have an existing control panel account (Author role minimum), the victim must perform a drag operation (not just visit the page), and the victim’s session needs to be elevated at trigger time. This issue has been fixed in version 5.9.23.

A vulnerability was found in Feehi CMS up to 2.1.1. This vulnerability affects unknown code of the file /api/articles of the component REST API Endpoint. Performing a manipulation results in missing authentication. The attack may be initiated remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

A flaw has been found in Feehi CMS up to 2.1.1. Affected by this issue is some unknown functionality of the file /api/users of the component API. This manipulation causes improper access controls. The attack can be initiated remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

Craft CMS from 4.0.0-RC1 contains an authenticated path traversal vulnerability in the assets/icon endpoint where the extension parameter is not validated before file existence checks. Attackers can bypass extension validation by passing traversal sequences that resolve to existing SVG files, allowing local file read access.

## Overview of all XSS Reports Multiple stored XSS vulnerabilities were found in Craft CMS. They were split into **4 reports** as follows: | Report | What's Vulnerable | Why Separate | |--------|-------------------|--------------| | **This Report (1)** | Multiple settings names | Twig Template: `_includes/forms/checkbox.twig` | | **Report 2** | Entry Types Name | Twig Template: `_includes/forms/editableTable.twig` | | **Report 3** | Card Attributes in Field Layout | `helpers/Cp.php` | | **Report 4 (Commerce)** | Product Type Name | Source in Commerce, sink in CMS - will report this one via Commerce GHSA | Reports 2, 3, and 4 are clearly distinct locations. For this report (Report 1), it was not clear whether to split or consolidate these 7 bugs. The bug report was consolidated and the final categorization should be left to the judgement of the user. **Note:** This overview is only in this Report. Other reports only reference this one. --- ## Summary Stored XSS in multiple settings. Names/labels are rendered without sanitization via `checkbox.twig` template which uses `{{ label|raw }}`. --- ## Affected Sources | # | Source (injection point) | Sink (where payload reflects) | | --- | ------------------------------------------------------------------------ | --------------------------------------------- | | 1 | Section Name (`/admin/settings/sections`) | Entries field -> Sources checklist | | 2 | Volume Name (`/admin/settings/assets/volumes/{vol_id}`) | Assets field -> Sources checklist | | 3 | User Group Name (`/admin/settings/users/groups`) | Users field -> Sources, User permissions page | | 4 | Global Set Name (`/admin/settings/globals`) | User permissions page | | 5 | Generated Fields Name (Volumes, Users, etc.) | Card Attributes checkboxes | | 6 | Checkboxes & Radio Buttons Field Option Label (`/admin/settings/fields`) | User profile pages | | 7 | Custom Sources Label (`/admin/users` -> Customize Sources) | Users field -> Sources checklist | --- ## Proof of Concept ### Required Permissions (Attacker) - Admin access - `allowAdminChanges` is enabled in production, which is against our [security recommendations](https://craftcms.com/knowledge-base/securing-craft). ### Bugs 1-3: Section, Volume, User Group Names 1. Log in as admin. 2. Inject payload in one of these: - **Settings** -> **Sections** -> Create/edit section -> **Name** - **Settings** -> **Assets** -> **Volumes** -> Create/edit volume -> **Name** - **Settings** -> **Users** -> **User Groups** -> Create/edit group -> **Name** 3. Set **Name** to: ```html <img src=x onerror="alert('XSS')"> ``` 4. Save. 5. Go to **Settings** -> **Fields** -> Create new field. 6. To trigger the XSS payload: Set **Field Type** to "Entries" (for Sections), "Assets" (for Volumes), or "Users" (for User Groups). The alert fires when the Sources checkbox list renders. **Note:** User Group Name also reflects on **User permissions page** under **User Groups** section (`/admin/users/{id}/permissions`). --- ### Bug 4: Global Set Name 1. Go to **Settings** -> **Globals** (`/admin/settings/globals`). 2. Create/edit a Global Set, set **Name** to payload. 3. Save. 4. Go to **Users** -> Edit any user -> **Permissions** tab (`/admin/users/{id}/permissions`). 5. Alert fires because our payload got rendered in the "Global Sets" permissions section without encoding/sanitization. --- ### Bug 5: Generated Fields Name 1. Go to **Settings** -> **Assets** -> **Volumes** -> Create/Edit a volume. 2. Scroll to **Generated Fields** section. 3. Add a field, set **Name** to payload: ```html <img src=x onerror="alert('XSS')"> ``` 4. Save & Notice the alert. The payload renders in the **Card Attributes** checkbox list below it. --- ### Bug 6: Checkboxes/Radio Buttons Option Label 1. Go to **Settings** -> **Fields** (`/admin/settings/fields`). 2. Create new field, set **Field Type** to "Checkboxes" or "Radio Buttons". 3. In **Field Options**, add an option with **Label** set to payload. 4. Save the field. 5. Go to **Settings** -> **Users** -> **User Profile Fields** (`/admin/settings/users/fields`). 6. Add the created field to the layout and save. 7. Alert fires on any user profile page (`/admin/users/{id}`). --- ### Bug 7: Custom Sources Label 1. Go to **Users** (`/admin/users`). 2. Click the three dots icon -> **Customize Sources**. 3. Create a new custom source, set **Label** to payload. 4. Save. 5. Go to **Settings** -> **Fields** -> Create new field. 6. Set **Field Type** to "Users". 7. Alert fires in the Sources checkbox list. ## Resources https://github.com/craftcms/cms/commit/943152d2246b36f12adf161a03b8695b773d9276 https://github.com/cr

### Summary An authenticated low-privileged user can call `assets/preview-file` for an asset they are not authorized to view and still receive preview response data (`previewHtml`) for that private asset. The returned preview HTML included a private preview image route containing the target private `assetId`, even though `canView` was `false` for the attacker account. ### Details 1. `assets/preview-file` accepts a maliciously controlled `assetId` and renders preview output. 2. The action does not enforce per-asset view authorization prior to returning preview content. 3. As a result, an authenticated user without asset-view permission can still obtain private preview output. This affects Craft installations with authenticated users of mixed privilege levels with private assets. ### Resources - d30df3112220db1ffd6726a3ed11857014c7fb27 - b1cddf72c98a

Craft CMS contains a missing authorization vulnerability in the assets/preview-thumb endpoint. A Control Panel user without permission to view a target private asset can call the endpoint with an attacker-controlled assetId and receive preview HTML containing a signed fallback transform preview link for that private asset, because no asset-view permission check is performed before preview generation. This affects versions >= 4.0.0-RC1, <= 4.17.7 and >= 5.0.0-RC1, <= 5.9.13, and is fixed in 4.17.8 and 5.9.14.