Package Instance

Craft CMS vulnerable to potential authenticated Remote Code Execution via Twig SSTI
For this to work, users must have administrator access to the Craft Control Panel, and [allowAdminChanges](https://craftcms.com/docs/5.x/reference/config/general.html#allowadminchanges) must be enabled for this to work, 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, a non-administrator account with allowAdminChanges disabled can be used, provided access to the System Messages utility is available.

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.21 and 4.16.17) to mitigate the issue.

References:

https://github.com/craftcms/cms/commit/d82680f4a05f9576883bb83c3f6243d33ca73ebe

https://github.com/craftcms/cms/blob/5.x/CHANGELOG.md#5821---2025-12-04

Craft CMS vulnerable to potential information disclosure via unchecked asset relocation
Authenticated users on a Craft installation could potentially expose sensitive assets via their user profile photo via maliciously crafted requests.

Users should update to the patched versions (5.8.21 and 4.16.17) to mitigate the issue.

 Resources:

https://github.com/craftcms/cms/commit/4bcb0db554e273b66ce3b75263a13414c2368fc9

https://github.com/craftcms/cms/commit/4bcb0db554e273b66ce3b75263a13414c2368fc9

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.

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

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Craft is a platform for creating digital experiences. When you insert a payload inside a label name or instruction of an entry type, an cross-site scripting (XSS) happens in the quick post widget on the admin dashboard. This issue has been fixed in version 4.3.7.

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.

Local File System Validation Bypass Leading to File Overwrite, Sensitive File Access, and Potential Code Execution
A vulnerability in CraftCMS allows an attacker to bypass local file system validation by utilizing a double `file://` scheme (e.g., `file://file:////`). This enables the attacker to specify sensitive folders as the file system, leading to potential file overwriting through malicious uploads, unauthorized access to sensitive files, and, under certain conditions, remote code execution (RCE) via Server-Side Template Injection (SSTI) payloads.

Note that this will only work if you have an authenticated administrator account with allowAdminChanges enabled

Unauthenticated Craft CMS users can trigger a database backup
Unauthenticated users can trigger database backup operations via specific admin actions, potentially leading to resource exhaustion or information disclosure.Users should update to the patched versions (5.8.21 and 4.16.17) to mitigate the issue.Craft 3 users should update to the latest Craft 4 and 5 releases, which include the fixes.Resources:

https://github.com/craftcms/cms/commit/f83d4e0c6b906743206b4747db4abf8164b8da39

https://github.com/craftcms/cms/blob/5.x/CHANGELOG.md

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Craft is a CMS for creating custom digital experiences on the web. Cross-site scripting (XSS) can be triggered via the Update Asset Index utility. This issue has been patched in version 4.4.6.