Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
118 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 -…
Recommended action: Upgrade to 5.9.18 or 4.17.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.9.15 or 4.17.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.15 or 4.17.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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()…
Recommended action: Upgrade to 5.9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 5.9.14 or 4.17.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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,…
Recommended action: Upgrade to 5.9.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.14 or 4.17.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 5.9.14 or 4.17.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: or 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…
Recommended action: Upgrade to 5.9.14 or 4.17.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 5.9.14 or 4.17.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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(): Note the…
Recommended action: Upgrade to 5.9.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.9.12 or 4.17.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.11 or 4.17.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: The $settings array from parsestr 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.
Recommended action: Upgrade to 5.9.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.11 or 4.17.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A stored XSS vulnerability exists in the User Permissions page. The User Group name is rendered without proper HTML escaping in the permissions section, allowing an attacker to execute arbitrary JavaScript when another user views or edits a user's permissions. [!NOTE] This is a separate vulnerability from the previously reported "Stored XSS via User Group Name in User Settings Page" and "Multiple Stored XSS in User Group Edit Page". This affects a different sink: the individual user's permissions page. Proof of Concept Required Permissions - Admin access - allowAdminChanges is enabled in production, which is against our security recommendations. Steps to Reproduce 1. Log in to the control panel as an admin 2. Navigate to Settings → Users → User Groups 3. Create or edit a user group and set the Name field to: 4. Save the user group 5. Navigate to Users and edit any user (/admin/users/{id}) 6. Click on the Permissions tab 7. XSS executes Mitigation Sanitize user group names…
Recommended action: Upgrade to 5.8.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 5.9.9 or 4.17.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ElementSearchController::actionSearch() endpoint is missing the unset() protection that was added to ElementIndexesController in 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.
Recommended action: Upgrade to 5.9.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2025-35939 in craftcms/cms introduced a striptags() call in src/web/User.php to sanitize return URLs before they are stored in the session. However, striptags() 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 striptags() completely unmodified, enabling reflected XSS when the return URL is rendered in an href attribute. Details The patched code in is: striptags() removes HTML tags (e.g., <script, <img) from a string, but it is not a URL sanitizer. When the sanitized return URL is subsequently rendered in an href attribute context (e.g., <a href="{{ returnUrl }}"), the following dangerous payloads survive striptags() completely unmodified: 1. javascript: protocol URLs -- javascript:alert(document.cookie) contains no HTML tags, so striptags() returns it verbatim. When placed in an href, clicking the link executes the JavaScript. 2. data:…
Recommended action: Upgrade to 5.9.7 or 4.17.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. --- Preconditions - Victim is logged in to Craft control panel. - Victim has active preview authorization in session for target content (e.g., opened/edited an entry). - The attacker must know the target’s canonicalId and public URL path of that entry. 1) Attacker prepares a fixed token Use any 32-character value, for example: 2) CSRF victim into minting that token Send the victim a link (or top-level redirect) such as: If the victim is logged in and authorized for previewElement:123, Craft creates that exact…
Recommended action: Upgrade to 5.9.7 or 4.17.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The actionSendActivationEmail() endpoint is accessible to unauthenticated users and does not require a permission check for pending users. An attacker with no prior access can trigger activation emails for any pending user account by knowing or guessing the user ID. If the attacker controls the target user’s email address, they can activate the account and gain access to the system. The vulnerability is not that anonymous access exists - there’s a legitimate use case for it. The vulnerability is that the endpoint accepts arbitrary userId parameters without verifying ownership. Craft CMS allows public user registration. When a user registers but doesn’t receive their activation email (spam filter, typo correction, etc.), they need a way to request a resend. This is why send-activation-email is in the allowAnonymous array - it’s intentional self-service functionality. The Security Gap The endpoint accepts userId as the identifier: This allows any visitor to trigger activation emails…
Recommended action: Upgrade to 5.9.0-beta.2 (pre-release) or 4.17.0-beta.2 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
For this to work, the attacker must have administrator access to the Craft Control Panel, and allowAdminChanges must be enabled, which is against Craft CMS' recommendations for any non-dev environment. https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production Alternatively, they can have a non-administrator account with allowAdminChanges disabled, but they must have access to the System Messages utility. It is possible to craft a malicious payload using the Twig map filter in text fields that accept Twig input under Settings in the Craft control panel or using the System Messages utility, which could lead to a RCE. Users should update to the patched versions (5.8.22 and 4.16.18) to mitigate the issue. References: https://github.com/craftcms/cms/pull/18208
Recommended action: Upgrade to 5.9.0-beta.1 (pre-release) or 4.17.0-beta.1 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The "Duplicate" entry action does not properly verify if the user has permission to perform this action on the specific target elements. Even with only "View Entries" permission (where the "Duplicate" action is restricted in the UI), a user can bypass this restriction by sending a direct request. Furthermore, this vulnerability allows duplicating other users' entries by specifying their Entry IDs. Since Entry IDs are incremental, an attacker can trivially brute-force these IDs to duplicate and access restricted content across the system. Proof of Concept Prerequisites - A user with "View Entries" permission on any section. Steps to Reproduce 1. Log in as a user with minimal permissions ("View Entries"). 1. Identify the target Entry ID (e.g., via brute-force 1 to N). 1. Send the following cURL request: Replace craft.local, <Cookie, <CSRF and 6393 (which is the entry ID): 1. Observe that a new entry is created with the attacker as the owner, granting full access to the…
Recommended action: Upgrade to 5.9.0-beta.1 (pre-release) or 4.17.0-beta.1 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Craft CMS implements a blocklist to prevent potentially dangerous PHP functions from being called via Twig non-Closure arrow functions. In order to be able to successfully execute this attack, you need to either have allowAdminChanges enabled on production, or a compromised admin account, or an account with access to the System Messages utility. Several PHP functions are not included in the blocklist, which could allow malicious actors with the required permissions to execute various types of payloads, including RCEs, arbitrary file reads, SSRFs, and SSTIs. Twig has already deprecated this behavior, and it will eventually be removed from Twig altogether. https://github.com/twigphp/Twig/blob/946ddeafa3c9f4ce279d1f34051af041db0e16f2/src/Extension/CoreExtension.php#L2096 This has been resolved in Craft 4.17.0 and 5.9.0, which removes the blocklist and disables all non-Clousure arrow functions in Twig globally via the enableTwigSandbox config setting. That setting is enabled by default…
Recommended action: Upgrade to 5.9.0-beta.1 (pre-release) or 4.17.0-beta.1 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.