Foto von Justin Morgan auf Unsplash
Gestern, am 17. Juli 2026, sind zwei kritische Sicherheitslücken im WordPress-Kern öffentlich geworden. Nicht in irgendeinem Plugin, sondern in WordPress selbst. Jede für sich ist aus der Ferne ausnutzbar, richtig brenzlig wird es aber im Zusammenspiel: Verkettet erlauben die beiden das Einschleusen von Schadcode ganz ohne Login. Die Sicherheitsforscher von Searchlight Cyber, die eine der Lücken gefunden haben, tauften ihren Exploit passenderweise „WP2Shell”. Laut Patchstack werden die Schwachstellen bereits aktiv angegriffen. Wenn du eine WordPress-Webseite betreibst, ist das kein Thema für nächste Woche.
Ich erkläre kurz, was dahintersteckt, was die Lücken praktisch bedeuten und wie du jetzt am besten vorgehst. Vorweg das Wichtigste für alle, die ich betreue: Eure Webseiten sind bereits abgesichert. Mehr dazu weiter unten.
Was gestern bekannt wurde
Es geht um zwei Schwachstellen, die zusammen einen Angriff ergeben. Behoben sind sie mit WordPress 7.0.2, für die älteren Zweige mit 6.9.5 und 6.8.6:
| SQL-Injection | „WP2Shell” (REST-API) | |
|---|---|---|
| CVE | CVE-2026-60137 | CVE-2026-63030 |
| CVSS | 9,1 bis 9,8 (kritisch) | 7,5 bis 9,1 (hoch bis kritisch) |
| Schwachstelle | author__not_in in WP_Query | REST-Endpunkt /wp-json/batch/v1 |
| Zugriff nötig | keiner, unauthentifiziert | keiner, unauthentifiziert |
| Behoben in | 7.0.2 / 6.9.5 / 6.8.6 | 7.0.2 / 6.9.5 / 6.8.6 |
Betroffen sind alle Versionen von 6.8 bis einschließlich 7.0.1. Alles davor ist nicht betroffen. Die genauen CVSS-Werte fallen je nach Quelle etwas unterschiedlich aus, beide Lücken liegen aber im hohen bis kritischen Bereich einer Skala bis 10. Auf die exakte Einzelbewertung kommt es ohnehin weniger an als auf ihr Zusammenspiel.
Die SQL-Injection: Griff in die Datenbank
Die eine Lücke (CVE-2026-60137) ist eine SQL-Injection. Sie steckt im author__not_in-Parameter von WP_Query, der Eingaben nicht sauber prüft. Darüber schleust ein Angreifer eigene Befehle in die Datenbank ein, in der WordPress alles speichert: Inhalte, Benutzerkonten, Passwort-Hashes. Das funktioniert aus der Ferne und ohne Login. Für eine Webseite mit Kundendaten oder einem Shop ist das der Ernstfall.
Die REST-API-Lücke „WP2Shell”
Die zweite Schwachstelle (CVE-2026-63030) sitzt in der REST-API von WordPress, konkret am Endpunkt /wp-json/batch/v1. Eine fehlende Prüfung lässt dort Zugriffe zu, die eigentlich abgesichert sein müssten. Für sich genommen stuften die Finder von Searchlight Cyber sie als hoch ein (CVSS 7,5). Den Namen „WP2Shell” bekam ihr Exploit, weil der Weg über die API am Ende in einer Shell landet, also in der Möglichkeit, Befehle auszuführen.
Verkettet: Codeeinschleusung ohne Login
Gefährlich wird es im Zusammenspiel. Hängt ein Angreifer beide Lücken aneinander, entsteht daraus eine unauthentifizierte Remote Code Execution: Ein Unbekannter führt ohne Anmeldung eigenen Code auf deinem Server aus und übernimmt die Webseite. Ab da ist alles möglich, von untergeschobener Werbung über Weiterleitungen auf Betrugsseiten bis zum kompletten Datenklau. Genau diese Kette ist als „WP2Shell” bekannt geworden, und solche Ketten lassen sich vollautomatisch gegen Millionen Webseiten gleichzeitig ausrollen. Weltweit sind rund 500 Millionen WordPress-Installationen erreichbar. Die technischen Details hat heise online zusammengetragen.
Warum diese beiden Lücken so gefährlich sind
Drei Dinge kommen hier zusammen, die sonst selten gleichzeitig auftreten.
Erstens sitzen die Lücken im Kern, nicht in einer Erweiterung. Normalerweise stammen rund 97 % aller WordPress-Schwachstellen aus Plugins und Themes, wie ich in den fünf Sicherheitsmaßnahmen beschrieben habe. Eine Lücke im Kern trifft dagegen jede einzelne WordPress-Webseite, unabhängig davon, welche Plugins sie nutzt.
Zweitens braucht ein Angreifer keinerlei Zugangsdaten. Unauthentifiziert heißt: Er muss kein Passwort erraten und kein Konto haben. Er ruft die Seite auf, und das reicht.
Drittens ist die Ausnutzung nur eine Frage von Stunden. Patchstack führt die Lücken bereits als aktiv ausgenutzt, und Sicherheitsforscher rechnen damit, dass Angreifer die veröffentlichten Patches mit KI-Hilfe analysieren und noch am Wochenende die ersten Exploit-Versuche starten. Automatisierte Bots scannen das Netz ohnehin rund um die Uhr. Wer erst nächste Woche updatet, kann zu spät dran sein.
Was du jetzt tun solltest
- Version prüfen. Öffne dein WordPress-Dashboard. Unten rechts oder unter „Werkzeuge” steht deine Version. Alles bis 7.0.1 ist verwundbar.
- Aktualisieren. Spiel den passenden Fix ein: 7.0.2 im aktuellen Zweig, für ältere Installationen 6.9.5 oder 6.8.6. Am besten vorher ein Backup ziehen, damit du im Zweifel zurück kannst.
- Kein Update möglich? Notfallflicken einspielen. Die Finder bieten unter wp2shell.com eine schnelle Prüfung samt kleinem Plugin an, das die verwundbare API-Route nachträglich absichert. Alternativ blockiert eine Web Application Firewall (etwa über Patchstack oder Cloudflare) den Angriff. Beides überbrückt das gefährliche Zeitfenster, bis das eigentliche Update läuft.
- Auf Einbruchsspuren achten. Unbekannte Admin-Konten, fremde Dateien im Upload-Ordner, plötzliche Weiterleitungen: Bei solchen Zeichen gehört die Webseite umgehend geprüft.
Meine Wartungskunden sind bereits abgesichert
Wenn ich deine Webseite betreue, musst du an dieser Stelle nichts tun. Ich habe direkt nach Bekanntwerden der Lücken reagiert und alle betreuten WordPress-Webseiten auf den jeweils gepatchten Stand gebracht (7.0.2 bzw. 6.9.5 oder 6.8.6), wo nötig zusätzlich über virtuelles Patching als Sofortschutz, während das Update kontrolliert nachlief.
Genau dafür gibt es die WordPress-Wartung: Sie sorgt dafür, dass jemand aufpasst, wenn so etwas passiert, und zwar sofort und nicht erst, wenn du zufällig davon liest. Kritische Kernlücken wie diese sind der Grund, warum eine gute Absicherung aus mehreren Schichten besteht statt nur aus dem gelegentlichen Update-Klick.
Fazit
Zwei Lücken im WordPress-Kern, einzeln schon kritisch, verkettet zu „WP2Shell” und damit zur Codeeinschleusung ohne Login. Behoben sind sie mit 7.0.2, 6.9.5 und 6.8.6. Für jede WordPress-Webseite gilt jetzt dasselbe: Version prüfen, aktualisieren, und falls das gerade nicht geht, per Notfall-Plugin oder Firewall überbrücken. Wer eine laufende Wartung hat, ist diesen Weg schon gegangen. Wer nicht, sollte die nächste Stunde dafür nutzen, bevor es die Bots tun.
Häufige Fragen
Bin ich betroffen, wenn meine Webseite automatische Updates aktiviert hat?
Vielleicht schon abgesichert, sicher ist es aber nicht. WordPress verteilt Sicherheitsupdates zwar automatisch, das kann sich aber um Stunden verzögern, und genau dieses Zeitfenster wird bei aktiv ausgenutzten Lücken sofort angegriffen. Außerdem sind automatische Updates auf vielen Webseiten deaktiviert oder auf bestimmte Zweige eingeschränkt. Prüfe im Dashboard unter Werkzeuge oder in der Fußzeile, ob wirklich 7.0.2 läuft (oder 6.9.5 bzw. 6.8.6 im jeweils älteren Zweig). Solange dort eine Version von 6.8 bis 7.0.1 steht, bist du angreifbar.
Woran erkenne ich, ob meine Webseite schon gehackt wurde?
Typische Anzeichen sind unbekannte Administratoren, plötzlich langsame Ladezeiten, unerklärliche Weiterleitungen, fremde Dateien im Upload-Ordner oder Warnungen von Google. Ein sauberes Bild bekommst du über einen Malware-Scan und einen Abgleich der Kern-Dateien gegen das Original. Wenn du unsicher bist, prüfe ich das gern für dich, bevor aus einem Verdacht ein echter Schaden wird.
Ich bin kein Kunde. Was soll ich am schnellsten tun?
Zwei Schritte: Erstens die WordPress-Version prüfen und, falls möglich, sofort auf 7.0.2 aktualisieren. Zweitens ein Backup ziehen, bevor du etwas änderst. Kommst du an das Update gerade nicht heran, wende dich an deinen Hoster oder deinen Webentwickler, damit die Lücke über eine Firewall-Regel vorübergehend blockiert wird. Danach lohnt ein Blick auf die grundsätzliche Absicherung, damit du beim nächsten Mal nicht wieder gegen die Uhr arbeitest.
