GHSA-JHH7-832H-F8HV

Vulnerability from github – Published: 2026-07-31 22:24 – Updated: 2026-07-31 22:24
VLAI
Summary
WPGraphQL has deprecated `user` field on SendPasswordResetEmailPayload that leaks user existence + profile (defeats explicit anti-enumeration design)
Details

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: "victim@example.com" }) {
    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
    1. 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
    1. 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
    1. 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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wp-graphql/wp-graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54768"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T22:24:29Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `sendPasswordResetEmail` mutation in WPGraphQL is explicitly designed to prevent user enumeration. The resolver in `src/Mutation/SendPasswordResetEmail.php` states in a code comment:\n\n`// We obsfucate the actual success of this mutation to prevent user enumeration.`\n\nThe 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`.\n\nHowever, 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 \u2014 completely undermining the anti-enumeration design.\n\nThe `@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.\n\nDiscovered via source code review on May 29, 2026.\n\n## Details\n\nThe mutation resolver in `src/Mutation/SendPasswordResetEmail.php`:\n\n```php\n$payload = [\u0027success\u0027 =\u003e true, \u0027id\u0027 =\u003e null];\n$user_data = self::get_user_data($input[\u0027username\u0027]);\nif (!$user_data) {\n    graphql_debug(...);\n    return $payload;  // id stays null\n}\n// ...send email, then...\nreturn [\u0027id\u0027 =\u003e $user_data-\u003eID, \u0027success\u0027 =\u003e true];\n```\n\nThe intended public output field is only `success`. The `id` is internal-only state for downstream resolvers.\n\n`src/Deprecated.php` registers an additional `user` field on the same payload type:\n\n```php\nregister_graphql_field(\n    \u0027SendPasswordResetEmailPayload\u0027,\n    \u0027user\u0027,\n    [\n        \u0027type\u0027 =\u003e \u0027User\u0027,\n        \u0027deprecationReason\u0027 =\u003e static function () { return __(\u0027This field will be removed...\u0027); },\n        \u0027resolve\u0027 =\u003e static function ($payload, $args, AppContext $context) {\n            return !empty($payload[\u0027id\u0027])\n                ? $context-\u003eget_loader(\u0027user\u0027)-\u003eload_deferred($payload[\u0027id\u0027])\n                : null;\n        },\n    ],\n);\n```\n\nThis field reads the internal `$payload[\u0027id\u0027]` and resolves it through the standard user loader. The User Model\u0027s `allowed_restricted_fields` policy permits unauthenticated reads of public author fields (`databaseId`, `name`, `firstName`, `lastName`, `slug`, `description`, `uri`, `url`).\n\n## PoC\n\n```graphql\nmutation EnumerateUser {\n  sendPasswordResetEmail(input: { username: \"victim@example.com\" }) {\n    success\n    user {\n      databaseId\n      name\n      firstName\n      lastName\n      slug\n      description\n      uri\n    }\n  }\n}\n```\n\nBehavior:\n- Non-existing user/email \u2192 `data.sendPasswordResetEmail.user` is `null`\n- - Existing author-class user \u2192 `data.sendPasswordResetEmail.user` is a full User object with the listed fields populated\n- - `success` always returns `true`, preserving the appearance of obfuscation \u2014 the deprecated `user` field is the leak\n## Impact\n\n1. **Username/email enumeration:** unauthenticated attacker can verify whether any username or email is registered, with no WPGraphQL-side rate limiting\n2. 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` \u2014 substantially more than mere existence\n3. 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\n4. 4. **Spearphishing setup:** firstName/lastName/description for authors provides personalized phishing material\n## Recommended fix\n\nEither remove the deprecated `user` field entirely (advance the existing `@todo remove in 3.0.0`) or change the resolver to always return `null`:\n\n```diff\n\u0027resolve\u0027 =\u003e static function ($payload, $args, AppContext $context) {\n-    return !empty($payload[\u0027id\u0027]) ? $context-\u003eget_loader(\u0027user\u0027)-\u003eload_deferred($payload[\u0027id\u0027]) : null;\n- +    // Always null \u2014 this deprecated field previously leaked user existence,\n- +    // undermining the anti-enumeration design of the sendPasswordResetEmail mutation.\n- +    return null;\n- },\n- ```\nDefense in depth \u2014 change the mutation resolver itself to not populate `$payload[\u0027id\u0027]` on real success:\n\n```diff\nreturn [\n-    \u0027id\u0027      =\u003e $user_data-\u003eID,\n- +    \u0027id\u0027      =\u003e null,\n-      \u0027success\u0027 =\u003e true,\n- ];\n- ```\n\nLuke Granto \u2014 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.",
  "id": "GHSA-jhh7-832h-f8hv",
  "modified": "2026-07-31T22:24:29Z",
  "published": "2026-07-31T22:24:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wp-graphql/wp-graphql/security/advisories/GHSA-jhh7-832h-f8hv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wp-graphql/wp-graphql"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wp-graphql/wp-graphql/releases/tag/wp-graphql/v2.15.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "WPGraphQL has deprecated `user` field on SendPasswordResetEmailPayload that leaks user existence + profile (defeats explicit anti-enumeration design)"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…