Wp graphql: WPGraphQL has deprecated `user` field on SendPasswordResetEmailPayload that leaks user existence + profile (defeats explicit anti-enumeration design) (CVE-2026-54768)
## 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`: ```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: ```php 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 ```graphql mutation EnumerateUser { sendPasswordResetEmail(input: { username: "[email protected]" }) { success user { databaseId name firstName lastName slug description uri } } } ``` Behavior: - Non-existing user/email → `data.sendPasswordResetEmail.user` is `null` - - Existing author-class user → `data.sendPasswordResetEmail.user` is a full User object with the listed fields populated - - `success` always returns `true`, preserving the appearance of obfuscation — the deprecated `user` field is the leak ## Impact 1. **Username/email enumeration:** unauthenticated attacker can verify whether any username or email is registered, with no WPGraphQL-side rate limiting 2. 2. **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 3. 3. **Bypasses partial hardening:** sites that disabled the REST API user endpoint, the user XML sitemap, and `?author=N` author redirects may still be vulnerable through this WPGraphQL path 4. 4. **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`: ```diff '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.
AI Analysis
Technical Summary
The WPGraphQL 'sendPasswordResetEmail' mutation is intended to prevent user enumeration by always returning success: true regardless of user existence. However, a deprecated 'user' field on the mutation's payload type leaks user existence and profile information by resolving to a User object when the username/email exists and null otherwise. This field exposes public author-class user fields such as databaseId, name, firstName, lastName, slug, description, and uri. The deprecated field reads an internal 'id' from the mutation payload, which is populated only when the user exists, thus defeating the anti-enumeration design. This issue affects all WPGraphQL versions up to and including 2.6.0 and is acknowledged in the source code with a planned removal in version 3.0.0.
Potential Impact
An unauthenticated attacker can enumerate usernames or emails by querying the deprecated 'user' field, bypassing the intended obfuscation of the sendPasswordResetEmail mutation. This allows confirmation of user existence without rate limiting at the WPGraphQL level. Additionally, for author-class users (including editors and administrators), the attacker can obtain profile details such as databaseId, name, firstName, lastName, slug, description, and uri. This information disclosure can facilitate targeted spearphishing attacks. The vulnerability bypasses other WordPress user enumeration mitigations such as disabling REST API user endpoints, XML sitemaps, and author redirects.
Mitigation Recommendations
No official patch or fix is currently available. The recommended remediation is to remove the deprecated 'user' field entirely or modify its resolver to always return null, preventing user data leakage. Additionally, changing the mutation resolver to not populate the internal 'id' field on success would provide defense in depth. Users should monitor the WPGraphQL project for the planned removal of this field in version 3.0.0 and apply that update once available. Until then, consider restricting access to the GraphQL endpoint or implementing custom rate limiting and monitoring to mitigate enumeration risks.
Wp graphql: WPGraphQL has deprecated `user` field on SendPasswordResetEmailPayload that leaks user existence + profile (defeats explicit anti-enumeration design) (CVE-2026-54768)
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`: ```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: ```php 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 ```graphql mutation EnumerateUser { sendPasswordResetEmail(input: { username: "[email protected]" }) { success user { databaseId name firstName lastName slug description uri } } } ``` Behavior: - Non-existing user/email → `data.sendPasswordResetEmail.user` is `null` - - Existing author-class user → `data.sendPasswordResetEmail.user` is a full User object with the listed fields populated - - `success` always returns `true`, preserving the appearance of obfuscation — the deprecated `user` field is the leak ## Impact 1. **Username/email enumeration:** unauthenticated attacker can verify whether any username or email is registered, with no WPGraphQL-side rate limiting 2. 2. **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 3. 3. **Bypasses partial hardening:** sites that disabled the REST API user endpoint, the user XML sitemap, and `?author=N` author redirects may still be vulnerable through this WPGraphQL path 4. 4. **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`: ```diff '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.
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The WPGraphQL 'sendPasswordResetEmail' mutation is intended to prevent user enumeration by always returning success: true regardless of user existence. However, a deprecated 'user' field on the mutation's payload type leaks user existence and profile information by resolving to a User object when the username/email exists and null otherwise. This field exposes public author-class user fields such as databaseId, name, firstName, lastName, slug, description, and uri. The deprecated field reads an internal 'id' from the mutation payload, which is populated only when the user exists, thus defeating the anti-enumeration design. This issue affects all WPGraphQL versions up to and including 2.6.0 and is acknowledged in the source code with a planned removal in version 3.0.0.
Potential Impact
An unauthenticated attacker can enumerate usernames or emails by querying the deprecated 'user' field, bypassing the intended obfuscation of the sendPasswordResetEmail mutation. This allows confirmation of user existence without rate limiting at the WPGraphQL level. Additionally, for author-class users (including editors and administrators), the attacker can obtain profile details such as databaseId, name, firstName, lastName, slug, description, and uri. This information disclosure can facilitate targeted spearphishing attacks. The vulnerability bypasses other WordPress user enumeration mitigations such as disabling REST API user endpoints, XML sitemaps, and author redirects.
Mitigation Recommendations
No official patch or fix is currently available. The recommended remediation is to remove the deprecated 'user' field entirely or modify its resolver to always return null, preventing user data leakage. Additionally, changing the mutation resolver to not populate the internal 'id' field on success would provide defense in depth. Users should monitor the WPGraphQL project for the planned removal of this field in version 3.0.0 and apply that update once available. Until then, consider restricting access to the GraphQL endpoint or implementing custom rate limiting and monitoring to mitigate enumeration risks.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-jhh7-832h-f8hv
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-54768"]
- Ecosystems
- ["Packagist"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 4.0
Threat ID: 6a6daad3bf32cb7a34667922
Added to database: 08/01/2026, 08:14:11 UTC
Last enriched: 08/01/2026, 08:19:56 UTC
Last updated: 08/01/2026, 22:23:13 UTC
Views: 5
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.