CVE-2026-54768: WPGraphQL erlaubt Benutzeraufzählung ohne Login

Veröffentlicht am 01.08.2026

Sicherheitsmaßnahmen sind nur so gut wie ihre schwächste Stelle – und manchmal öffnet ausgerechnet eine alte, vergessene Funktion eine Tür, die eigentlich fest verschlossen sein sollte. Genau das ist beim beliebten WordPress-Plugin WPGraphQL passiert. Ein veraltetes Datenfeld hebelt einen bewusst eingebauten Schutzmechanismus aus und erlaubt es Angreifern, ohne jede Anmeldung herauszufinden, welche Benutzerkonten auf einer Website existieren – und dazu noch persönliche Profildaten der Autoren abzugreifen. Die Schwachstelle trägt die Kennung CVE-2026-54768 und wurde am 31. Juli 2026 offiziell veröffentlicht.

Was das für Sie als Website-Betreiber bedeutet, ob Sie überhaupt betroffen sind und was Sie jetzt konkret tun sollten, erklären wir in diesem Beitrag Schritt für Schritt.

Was ist passiert?

WPGraphQL ist ein WordPress-Plugin, das eine sogenannte GraphQL-API bereitstellt – eine moderne Schnittstelle, über die andere Programme strukturiert Daten aus einer WordPress-Website abfragen können. Das Plugin ist vor allem im Bereich „Headless WordPress“ beliebt, bei dem WordPress nur als Datenlieferant im Hintergrund dient und die eigentliche Website mit modernen Frameworks wie Next.js, Gatsby oder Astro dargestellt wird.

Am 31. Juli 2026 wurde für WPGraphQL die Sicherheitslücke CVE-2026-54768 veröffentlicht. Sie betrifft alle Versionen von 2.0.0 bis einschließlich 2.15.0. Der CVSS-Wert (eine standardisierte Kennzahl für die Schwere einer Schwachstelle auf einer Skala von 0 bis 10) liegt bei 6.9 – eingestuft als „Medium“, also mittlerer Schweregrad. Behoben wurde das Problem bereits am 9. Juni 2026 mit Version 2.15.1.

Das Kernproblem: WPGraphQL enthält eine Funktion namens sendPasswordResetEmail (Passwort-Zurücksetzen-E-Mail versenden), die bewusst so gebaut wurde, dass sie keine Rückschlüsse darauf zulässt, ob ein Konto existiert. Genau dieses Schutzprinzip wird durch ein altes, überflüssig gewordenes Datenfeld ausgehebelt.

Der technische Hintergrund – verständlich erklärt

Um zu verstehen, warum die Lücke problematisch ist, muss man das Prinzip der Benutzeraufzählung (englisch: User Enumeration) kennen. Darunter versteht man den Versuch eines Angreifers, systematisch herauszufinden, welche Benutzernamen oder E-Mail-Adressen auf einer Website tatsächlich registriert sind. Diese Informationen sind die Grundlage für gezielte Angriffe – etwa Phishing-Mails oder das automatisierte Durchprobieren von Passwörtern (Brute-Force).

Die Entwickler von WPGraphQL haben genau das verhindern wollen. Die Passwort-Reset-Funktion gibt deshalb immer die Rückmeldung „success: true“ zurück – ganz egal, ob die eingegebene E-Mail-Adresse zu einem echten Konto gehört oder nicht. Im Quellcode findet sich dazu sogar ein erklärender Kommentar der Entwickler: „We obsfucate the actual success of this mutation to prevent user enumeration“ – sinngemäß: „Wir verschleiern den tatsächlichen Erfolg dieser Funktion, um Benutzeraufzählung zu verhindern.“

Das Problem: In der Datei src/Deprecated.php ist ein veraltetes (englisch „deprecated“, also für zukünftige Entfernung markiertes) Feld namens user registriert. Und dieses Feld verhält sich verräterisch:

• Gehört die eingegebene E-Mail-Adresse oder der Benutzername zu einem existierenden Autoren-Konto, liefert das Feld ein vollständiges Benutzerobjekt zurück.
• Existiert das Konto nicht, gibt das Feld null (also „nichts“) zurück.

Damit ist der gesamte Schutzmechanismus ausgehebelt. Ein Angreifer muss nur schauen, ob im user-Feld etwas steht oder nicht – und weiß sofort, ob ein Konto existiert. Und es kommt noch schlimmer: Bei existierenden Autoren-Konten werden gleich mehrere öffentliche Profildaten mitgeliefert – konkret die interne Datenbank-ID, der Name, Vor- und Nachname, der Slug (Kurzname für die URL), die Biografie sowie die Profil-URL.

Die Schwachstelle ist als CWE-204 (Observable Response Discrepancy) klassifiziert – zu Deutsch: eine erkennbare Abweichung in der Antwort, aus der sich sensible Informationen ableiten lassen.

„Die sendPasswordResetEmail-Mutation in WPGraphQL ist ausdrücklich darauf ausgelegt, Benutzeraufzählung zu verhindern. Ein veraltetes user-Feld untergräbt dieses Anti-Enumeration-Design jedoch vollständig.“ – GitHub Security Advisory GHSA-jhh7-832h-f8hv

Entdeckt hat die Lücke der unabhängige Sicherheitsforscher Luke Granto – und zwar durch eine einfache Durchsicht des Quellcodes. Seinen eigenen Angaben zufolge dauerte es „etwa 15 Minuten vom Klonen des Codes bis zur Bestätigung des Fehlers“. Das zeigt, wie leicht die Lücke aufzufinden war. Erfreulich: Es gibt keine Hinweise auf eine tatsächliche Ausnutzung gegen Dritte.

Wer ist betroffen?

Die gute Nachricht zuerst: Die meisten klassischen KMU-Websites sind nicht betroffen. WPGraphQL ist ein Spezial-Plugin, das nur installiert ist, wenn Sie eine sogenannte Headless-WordPress-Architektur betreiben. Wer eine „normale“ WordPress-Website mit einem üblichen Theme nutzt, hat dieses Plugin in aller Regel nicht installiert.

Direkt gefährdet sind ausschließlich Websites, die alle drei folgenden Bedingungen erfüllen:

1. Das Plugin WPGraphQL ist in einer Version zwischen 2.0.0 und 2.15.0 installiert und aktiv.
2. Der GraphQL-Endpunkt (standardmäßig https://ihre-domain.de/graphql) ist öffentlich erreichbar.
3. Es existieren Benutzerkonten mit Autorenrechten (Autor, Redakteur, Administrator), die mindestens einen Beitrag veröffentlicht haben.

Wichtig zu wissen: Betroffen sind nur Konten der „Autoren-Klasse“ mit veröffentlichten Beiträgen. Konten ohne veröffentlichte Inhalte geben ebenfalls null zurück und bleiben unsichtbar.

Besonders tückisch: Websites, die andere bekannte Wege der Benutzeraufzählung bereits gesperrt haben – etwa den REST-API-User-Endpunkt, die User-XML-Sitemap oder die ?author=N-Weiterleitung – sind über diesen WPGraphQL-Pfad weiterhin angreifbar. Wer sich also bereits in Sicherheit wähnt, kann sich hier täuschen.

Zur Einordnung der Verbreitung: WPGraphQL hat laut WordPress.org mehr als 30.000 aktive Installationen (Stand Juli 2026) und ist auf dem Weg zum offiziellen „Canonical Plugin“ – also einem von WordPress selbst empfohlenen Standard-Plugin. Die Verbreitung dürfte künftig also eher zunehmen.

So prüfen Sie, ob Sie betroffen sind

Gehen Sie die folgenden Schritte durch, um Ihre Betroffenheit zu klären:

1. Plugin-Version im Dashboard prüfen: Melden Sie sich im WordPress-Adminbereich an und öffnen Sie Plugins → Installierte Plugins. Suchen Sie nach „WPGraphQL“ und prüfen Sie die Versionsnummer. Liegt sie zwischen 2.0.0 und 2.15.0, sind Sie betroffen.
2. Prüfung per WP-CLI: Auf dem Server können Sie den Befehl wp plugin list --name=wp-graphql --fields=name,version,status ausführen. Eine Version kleiner als 2.15.1 bedeutet Betroffenheit.
3. Prüfung per Dateiinspektion: Öffnen Sie die Datei wp-content/plugins/wp-graphql/wp-graphql.php und suchen Sie im Plugin-Header die Zeile Version:.
4. GraphQL-Endpunkt prüfen: Kontrollieren Sie, ob der Endpunkt (meist https://ihre-domain.de/graphql) öffentlich erreichbar ist. Nur dann besteht ein aktives Risiko.
5. Test mit dem PoC-Query (nur für Administratoren): Senden Sie testweise folgenden Request an den Endpunkt:
   curl -X POST https://ihre-domain.de/graphql -H 'Content-Type: application/json' -d '{"query":"mutation { sendPasswordResetEmail(input: { username: \"bekannter-autor@ihre-domain.de\" }) { success user { name } } }"}'
   Liefert das user-Feld ein Objekt zurück (nicht null), ist Ihre Installation anfällig.
6. Logs auf Ausnutzung prüfen: Durchsuchen Sie Ihre Server-Access-Logs nach POST-Anfragen an /graphql mit dem Stichwort sendPasswordResetEmail. Auffällig häufige Anfragen von unbekannten IP-Adressen können auf Ausnutzungsversuche hindeuten.

Das müssen Sie jetzt tun

Die Lösung ist erfreulich einfach – der Patch existiert bereits seit Juni 2026.

1. Sofort aktualisieren: Updaten Sie WPGraphQL auf Version 2.15.1 oder neuer. Die aktuelle stabile Version ist 2.18.0 (Stand Juli 2026). Gehen Sie dazu auf Plugins → Installierte Plugins → WPGraphQL → Aktualisieren oder nutzen Sie das Kommando wp plugin update wp-graphql. Dies ist die einzige vollständige Lösung.
2. Überbrückung, falls kein sofortiges Update möglich ist: Beschränken Sie den Zugriff auf den /graphql-Endpunkt auf authentifizierte Benutzer oder bekannte IP-Adressen – etwa per .htaccess, nginx-Konfiguration oder einer Web Application Firewall (WAF, eine vorgeschaltete Schutzschicht für Webanwendungen). Alternativ können Sie das Plugin vorübergehend deaktivieren.
3. Auf Kompromittierung prüfen: Durchsuchen Sie Ihre Logs auf verdächtige Anfragen an /graphql. Prüfen Sie zudem, ob Zugangsdaten bekannter Autoren-Konten in Datenlecks aufgetaucht sind – etwa über den Dienst HaveIBeenPwned.
4. Endpunkt härten: Beschränken Sie den GraphQL-Endpunkt auf authentifizierte Anfragen, falls Sie keine öffentliche API benötigen. Aktivieren Sie in den WPGraphQL-Einstellungen zusätzlich „Query Depth Limiting“ und „Query Complexity Limits“, um Missbrauch zu erschweren.
5. Patch-Management etablieren: Richten Sie automatische Update-Benachrichtigungen ein und abonnieren Sie Sicherheits-Feeds wie den Wordfence Weekly Report oder den Patchstack-Newsletter.
6. Dienstleister einbinden: Wird Ihre Website von einer Agentur oder einem Freelancer betreut, informieren Sie diese umgehend und lassen Sie sich den Patch-Status schriftlich bestätigen.

Was der Patch konkret ändert

Maintainer Jason Bahl erklärt die Korrektur in Version 2.15.1 so:

„Das Feld ist nun an die list_users-Capability gekoppelt, sodass es für Aufrufer, die keine Benutzer auflisten dürfen, immer null zurückgibt – unabhängig davon, ob das Konto existiert.“

Vereinfacht gesagt: Das verräterische Feld liefert nur noch dann Daten, wenn der Aufrufer die entsprechende Berechtigung besitzt, Benutzerlisten einzusehen. Unangemeldete Angreifer erhalten immer null – die Aufzählung ist damit unmöglich.

Einordnung und DSGVO-Relevanz

Auch wenn die Lücke „nur“ Informationen offenlegt und weder Datei-Uploads noch Codeausführung ermöglicht, sollte man sie nicht unterschätzen. Der direkte Schaden – die Offenlegung von E-Mail-Adressen und Profildaten – ist die Grundlage für gezielte Folgeangriffe wie Phishing, Credential-Stuffing und Brute-Force.

Aus Datenschutzsicht ist die Lücke relevant, weil personenbezogene Daten (E-Mail-Adressen, Namen, Biografien) betroffen sind:

• Art. 32 DSGVO (Sicherheit der Verarbeitung): Betreiber sind verpflichtet, ein angemessenes Schutzniveau sicherzustellen. Das Betreiben einer ungepatchten Version, für die seit dem 9. Juni 2026 ein Fix bereitsteht, kann als Verstoß gewertet werden. Das Update ist daher als Pflichtmaßnahme einzustufen.
• Art. 33 DSGVO (Meldepflicht): Nur wenn eine tatsächliche Ausnutzung nachweisbar ist und personenbezogene Daten abgeflossen sind, greift die 72-Stunden-Meldepflicht gegenüber der Aufsichtsbehörde. Die bloße Existenz der Lücke begründet in der Regel keine Meldepflicht.
• Art. 34 DSGVO (Benachrichtigung Betroffener): Bei hohem Risiko – etwa gezieltem Phishing auf Basis abgegriffener Daten – müssen betroffene Personen direkt informiert werden.

Mario Elsen von der GRC-Beratung Elsen GRC bringt einen oft übersehenen Punkt auf den Punkt:

„Die Uhr läuft ab Kenntnis – nicht ab Behebung. […] Datenschutzrechtlich bleibt das Unternehmen der Verantwortliche. Ob der Dienstleister zeitnah patcht, sind Fragen des Third-Party-Risk-Managements, die vor dem Vorfall geklärt sein müssen.“

Mit anderen Worten: Die Verantwortung lässt sich nicht auf die betreuende Agentur abwälzen. Für die meisten KMU dürfte das unmittelbare Meldepflicht-Risiko jedoch gering sein, solange keine Ausnutzung nachweisbar ist – vor allem, weil kein KEV-Status (Known Exploited Vulnerability, also bekannt ausgenutzte Schwachstelle) vorliegt.

Zahlen zur Einordnung

Die Lücke reiht sich in ein wachsendes Problemfeld ein: 2025 wurden im WordPress-Ökosystem 11.334 neue Schwachstellen entdeckt – ein Plus von 42 % gegenüber 2024. Ganze 91 % davon stammen aus Plugins. Laut Patchstack liegt die mediane Zeit bis zur ersten aktiven Ausnutzung stark angegriffener Lücken bei nur fünf Stunden. Und 46 % der Plugin-Schwachstellen hatten bei ihrer öffentlichen Bekanntmachung noch gar keinen Patch.

Im vorliegenden Fall war das anders – und das ist die eigentlich gute Nachricht: Der Patch stand bereits 52 Tage vor der öffentlichen CVE-Veröffentlichung bereit. Wer Updates zeitnah einspielt, war also längst geschützt, bevor die Lücke öffentlich bekannt wurde.

Fazit

CVE-2026-54768 ist keine dramatische Fernübernahme-Lücke, aber ein lehrreiches Beispiel dafür, wie ein einzelnes veraltetes Feld einen bewusst eingebauten Schutz komplett aushebeln kann. Betroffen ist ein überschaubarer, aber wachsender Kreis von Website-Betreibern, die WPGraphQL für Headless-WordPress einsetzen.

Wenn Sie das Plugin nutzen, ist die Handlungsempfehlung eindeutig: Aktualisieren Sie umgehend auf Version 2.15.1 oder neuer – idealerweise gleich auf die aktuelle 2.18.0. Der Aufwand ist minimal, die Wirkung vollständig. Nutzen Sie den Vorfall zugleich als Anlass, Ihr Patch-Management und die Absprachen mit Ihrem Dienstleister zu überprüfen. Denn die nächste Plugin-Lücke kommt bestimmt – die Frage ist nur, ob Sie dann bereits abgesichert sind.