CVE-2026-54768: WPGraphQL Allows User Enumeration Without Login

Published on 1 August 2026

Security measures are only as good as their weakest point – and sometimes it's an old, forgotten feature that opens a door that should really be firmly shut. That's exactly what happened with the popular WordPress plugin WPGraphQL. An outdated data field circumvents a deliberately built-in protection mechanism and allows attackers to find out, without any login whatsoever, which user accounts exist on a website – and on top of that, to scrape personal profile data of the authors. The vulnerability carries the identifier CVE-2026-54768 and was officially published on July 31, 2026.

In this article, we explain step by step what this means for you as a website operator, whether you're affected at all, and what concrete steps you should take now.

What happened?

WPGraphQL is a WordPress plugin that provides a so-called GraphQL API – a modern interface through which other programs can query data from a WordPress website in a structured way. The plugin is especially popular in the "headless WordPress" space, where WordPress serves only as a data supplier in the background and the actual website is rendered using modern frameworks such as Next.js, Gatsby, or Astro.

On July 31, 2026, the security vulnerability CVE-2026-54768 was published for WPGraphQL. It affects all versions from 2.0.0 up to and including 2.15.0. The CVSS score (a standardized metric for the severity of a vulnerability on a scale of 0 to 10) is 6.9 – rated "Medium", i.e. moderate severity. The problem was already fixed on June 9, 2026, with version 2.15.1.

The core problem: WPGraphQL contains a function called sendPasswordResetEmail (send password reset email), which was deliberately built so that it reveals no clues as to whether an account exists. It is precisely this protection principle that is undermined by an old, now-redundant data field.

The technical background – explained plainly

To understand why the vulnerability is problematic, you need to know the principle of user enumeration. This refers to an attacker's attempt to systematically find out which usernames or email addresses are actually registered on a website. This information is the basis for targeted attacks – such as phishing emails or automated password guessing (brute force).

The developers of WPGraphQL wanted to prevent exactly that. That's why the password reset function always returns "success: true" – regardless of whether the entered email address belongs to a real account or not. The source code even contains an explanatory comment from the developers: "We obsfucate the actual success of this mutation to prevent user enumeration" – meaning: "We obscure the actual success of this function to prevent user enumeration."

The problem: in the file src/Deprecated.php, an outdated (marked "deprecated," i.e. flagged for future removal) field called user is registered. And this field behaves in a telltale way:

• If the entered email address or username belongs to an existing author account, the field returns a complete user object.
• If the account does not exist, the field returns null (i.e. "nothing").

This undermines the entire protection mechanism. An attacker only has to check whether the user field contains something or not – and immediately knows whether an account exists. And it gets worse: for existing author accounts, several public profile data points are delivered at once – specifically the internal database ID, the name, first and last name, the slug (short name for the URL), the biography, and the profile URL.

The vulnerability is classified as CWE-204 (Observable Response Discrepancy) – meaning a detectable discrepancy in the response from which sensitive information can be inferred.

"The sendPasswordResetEmail mutation in WPGraphQL is explicitly designed to prevent user enumeration. However, a deprecated user field completely undermines this anti-enumeration design." – GitHub Security Advisory GHSA-jhh7-832h-f8hv

The vulnerability was discovered by independent security researcher Luke Granto – simply through a review of the source code. By his own account, it took "about 15 minutes from cloning the code to confirming the bug." That shows how easy the vulnerability was to find. The good news: there are no indications of actual exploitation against third parties.

Who is affected?

The good news first: most traditional SME websites are not affected. WPGraphQL is a specialized plugin that is only installed if you run a so-called headless WordPress architecture. Anyone using a "normal" WordPress website with a conventional theme generally does not have this plugin installed.

Directly at risk are exclusively websites that meet all three of the following conditions:

1. The WPGraphQL plugin is installed and active in a version between 2.0.0 and 2.15.0.
2. The GraphQL endpoint (by default https://your-domain.com/graphql) is publicly accessible.
3. There are user accounts with author privileges (author, editor, administrator) that have published at least one post.

Important to know: only accounts of the "author class" with published posts are affected. Accounts without published content also return null and remain invisible.

Particularly insidious: websites that have already blocked other known routes of user enumeration – such as the REST API user endpoint, the user XML sitemap, or the ?author=N redirect – remain vulnerable via this WPGraphQL path. So anyone who already believes they're safe may be mistaken.

To put the reach into perspective: according to WordPress.org, WPGraphQL has more than 30,000 active installations (as of July 2026) and is on its way to becoming an official "Canonical Plugin" – a standard plugin recommended by WordPress itself. Its reach is therefore likely to increase rather than decline going forward.

How to check whether you're affected

Work through the following steps to determine whether you're affected:

1. Check the plugin version in the dashboard: Log into the WordPress admin area and open Plugins → Installed Plugins. Look for "WPGraphQL" and check the version number. If it's between 2.0.0 and 2.15.0, you're affected.
2. Check via WP-CLI: On the server you can run the command wp plugin list --name=wp-graphql --fields=name,version,status. A version lower than 2.15.1 means you're affected.
3. Check by file inspection: Open the file wp-content/plugins/wp-graphql/wp-graphql.php and look for the line Version: in the plugin header.
4. Check the GraphQL endpoint: Verify whether the endpoint (usually https://your-domain.com/graphql) is publicly accessible. Only then does an active risk exist.
5. Test with the PoC query (administrators only): As a test, send the following request to the endpoint:
   curl -X POST https://your-domain.com/graphql -H 'Content-Type: application/json' -d '{"query":"mutation { sendPasswordResetEmail(input: { username: \"known-author@your-domain.com\" }) { success user { name } } }"}'
   If the user field returns an object (not null), your installation is vulnerable.
6. Check logs for exploitation: Search your server access logs for POST requests to /graphql containing the keyword sendPasswordResetEmail. Suspiciously frequent requests from unknown IP addresses may indicate exploitation attempts.

What you need to do now

The solution is refreshingly simple – the patch has existed since June 2026.

1. Update immediately: Update WPGraphQL to version 2.15.1 or newer. The current stable version is 2.18.0 (as of July 2026). To do so, go to Plugins → Installed Plugins → WPGraphQL → Update or use the command wp plugin update wp-graphql. This is the only complete solution.
2. Stopgap if an immediate update isn't possible: Restrict access to the /graphql endpoint to authenticated users or known IP addresses – for example via .htaccess, nginx configuration, or a web application firewall (WAF, a protective layer placed in front of web applications). Alternatively, you can temporarily deactivate the plugin.
3. Check for compromise: Search your logs for suspicious requests to /graphql. Also check whether credentials of known author accounts have appeared in data breaches – for example via the HaveIBeenPwned service.
4. Harden the endpoint: Restrict the GraphQL endpoint to authenticated requests if you don't need a public API. Additionally, enable "Query Depth Limiting" and "Query Complexity Limits" in the WPGraphQL settings to make abuse more difficult.
5. Establish patch management: Set up automatic update notifications and subscribe to security feeds such as the Wordfence Weekly Report or the Patchstack newsletter.
6. Involve your service provider: If your website is maintained by an agency or a freelancer, inform them immediately and have them confirm the patch status in writing.

What the patch specifically changes

Maintainer Jason Bahl explains the fix in version 2.15.1 as follows:

"The field is now tied to the list_users capability, so it always returns null for callers who are not allowed to list users – regardless of whether the account exists."

In simpler terms: the telltale field now only returns data if the caller has the corresponding permission to view user lists. Unauthenticated attackers always receive null – making enumeration impossible.

Context and GDPR relevance

Even though the vulnerability "only" exposes information and enables neither file uploads nor code execution, it should not be underestimated. The direct harm – the disclosure of email addresses and profile data – is the basis for targeted follow-up attacks such as phishing, credential stuffing, and brute force.

From a data protection perspective, the vulnerability is relevant because personal data (email addresses, names, biographies) is affected:

• Art. 32 GDPR (Security of processing): Operators are obligated to ensure an appropriate level of protection. Running an unpatched version for which a fix has been available since June 9, 2026, can be considered a violation. The update should therefore be classified as a mandatory measure.
• Art. 33 GDPR (Notification obligation): Only if actual exploitation can be demonstrated and personal data has been leaked does the 72-hour notification obligation to the supervisory authority apply. The mere existence of the vulnerability generally does not trigger a notification obligation.
• Art. 34 GDPR (Notification of data subjects): In cases of high risk – such as targeted phishing based on scraped data – affected individuals must be informed directly.

Mario Elsen of the GRC consultancy Elsen GRC sums up an often-overlooked point:

"The clock starts running upon awareness – not upon remediation. […] Under data protection law, the company remains the controller. Whether the service provider patches promptly is a question of third-party risk management that must be clarified before the incident."

In other words: responsibility cannot be shifted onto the managing agency. For most SMEs, however, the immediate notification risk is likely to be low as long as no exploitation can be demonstrated – especially because there is no KEV status (Known Exploited Vulnerability).

Figures for context

The vulnerability fits into a growing problem area: in 2025, 11,334 new vulnerabilities were discovered in the WordPress ecosystem – an increase of 42% compared to 2024. A full 91% of them stem from plugins. According to Patchstack, the median time to first active exploitation of heavily attacked vulnerabilities is just five hours. And 46% of plugin vulnerabilities had no patch at all at the time of their public disclosure.

In this case, things were different – and that's the genuinely good news: the patch was available 52 days before the public CVE disclosure. Anyone who applies updates promptly was therefore protected long before the vulnerability became publicly known.

Conclusion

CVE-2026-54768 is not a dramatic remote-takeover vulnerability, but an instructive example of how a single outdated field can completely undermine a deliberately built-in protection. Affected is a manageable but growing circle of website operators who use WPGraphQL for headless WordPress.

If you use the plugin, the recommendation is clear: update immediately to version 2.15.1 or newer – ideally straight to the current 2.18.0. The effort is minimal, the effect complete. At the same time, use the incident as an opportunity to review your patch management and the arrangements with your service provider. Because the next plugin vulnerability is sure to come – the only question is whether you'll already be protected when it does.