WPGraphQL has deprecated `user` field on SendPasswordResetEmailPayload that leaks user existence + profile (defeats explicit anti-enumeration design)GHSA-jhh7-832h-f8hv
GHSA-jhh7-832h-f8hv is a CWE-204 vulnerability in wp-graphql/wp-graphql. The records list no fixed version yet; check the vendor advisory below and apply the mitigations in the meantime.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jhh7-832h-f8hv.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
wp-graphql/wp-graphqlReal-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 sendPasswordResetEmail mutation in WPGraphQL is explicitly designed to prevent user enumeration. The resolver in src/Mutation/SendPasswordResetEmail.php states in a code comment:
// We obsfucate the actual success of this mutation to prevent user enumeration.
The mutation always returns success: true regardless of whether the supplied username/email belongs to an existing user. The intended public output field is only success: Boolean.
However, a deprecated user field is still registered on the SendPasswordResetEmailPayload output type in src/Deprecated.php (lines 433-450). This deprecated field resolves to a full User object when the supplied username/email corresponds to an existing author-class user, and null otherwise — completely undermining the anti-enumeration design.
The @todo remove in 3.0.0 comment acknowledges the field is scheduled for removal, but it remains active in all 2.x releases, including current 2.14.1.
Discovered via source code review on May 29, 2026.
Details
The mutation resolver in src/Mutation/SendPasswordResetEmail.php:
$payload = ['success' => true, 'id' => null];
$user_data = self::get_user_data($input['username']);
if (!$user_data) {
graphql_debug(...);
return $payload; // id stays null
}
// ...send email, then...
return ['id' => $user_data->ID, 'success' => true];
The intended public output field is only success. The id is internal-only state for downstream resolvers.
src/Deprecated.php registers an additional user field on the same payload type:
register_graphql_field(
'SendPasswordResetEmailPayload',
'user',
[
'type' => 'User',
'deprecationReason' => static function () { return __('This field will be removed...'); },
'resolve' => static function ($payload, $args, AppContext $context) {
return !empty($payload['id'])
? $context->get_loader('user')->load_deferred($payload['id'])
: null;
},
],
);
This field reads the internal $payload['id'] and resolves it through the standard user loader. The User Model's allowed_restricted_fields policy permits unauthenticated reads of public author fields (databaseId, name, firstName, lastName, slug, description, uri, url).
PoC
mutation EnumerateUser {
sendPasswordResetEmail(input: { username: "[email protected]" }) {
success
user {
databaseId
name
firstName
lastName
slug
description
uri
}
}
}
Behavior:
- Non-existing user/email →
data.sendPasswordResetEmail.userisnull -
- Existing author-class user →
data.sendPasswordResetEmail.useris a full User object with the listed fields populated
- Existing author-class user →
-
successalways returnstrue, preserving the appearance of obfuscation — the deprecateduserfield is the leak
Impact
- Username/email enumeration: unauthenticated attacker can verify whether any username or email is registered, with no WPGraphQL-side rate limiting
-
- Profile disclosure for author-class users: for any user with published posts (including editors and administrators), the attacker obtains
databaseId,name,firstName,lastName,slug,description(user bio),uri— substantially more than mere existence
- Profile disclosure for author-class users: for any user with published posts (including editors and administrators), the attacker obtains
-
- Bypasses partial hardening: sites that disabled the REST API user endpoint, the user XML sitemap, and
?author=Nauthor redirects may still be vulnerable through this WPGraphQL path
- Bypasses partial hardening: sites that disabled the REST API user endpoint, the user XML sitemap, and
-
- Spearphishing setup: firstName/lastName/description for authors provides personalized phishing material
Recommended fix
Either remove the deprecated user field entirely (advance the existing @todo remove in 3.0.0) or change the resolver to always return null:
'resolve' => static function ($payload, $args, AppContext $context) {
- return !empty($payload['id']) ? $context->get_loader('user')->load_deferred($payload['id']) : null;
- + // Always null — this deprecated field previously leaked user existence,
- + // undermining the anti-enumeration design of the sendPasswordResetEmail mutation.
- + return null;
- },
- ```
Defense in depth — change the mutation resolver itself to not populate `$payload['id']` on real success:
```diff
return [
- 'id' => $user_data->ID,
- + 'id' => null,
- 'success' => true,
- ];
- ```
Luke Granto — independent security researcher operating in good faith. Discovery via source code review of wp-graphql/wp-graphql v2.14.1, approximately 15 minutes from `git clone` to confirmed bug. No live exploitation against any third-party deployment.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | wp-graphql/wp-graphql | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wp-graphql/wp-graphql, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
The records we use list no patched version of wp-graphql/wp-graphql for GHSA-jhh7-832h-f8hv. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.
Mitigate without a patch
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.
Frequently Asked Questions
Is GHSA-jhh7-832h-f8hv in your dependencies?
Find it across Packagist, including transitive dependencies.