Auf einem Smartphone-Display ist das blaue WordPress-Logo mit der Bezeichnung WordPress zu sehen.

wp2shell zwingt WordPress Websites zum Update

Eine neu entdeckte Schwachstellenkette namens wp2shell erlaubt Angreifern die vollständige Übernahme ungepatchter WordPress-Installationen, ganz ohne Login oder Plugin. Das WordPress-Kernteam hat binnen Stunden reagiert und liefert bereits ein Sicherheitsupdate nach. Ihr solltet trotzdem selbst nachsehen, ob Eure Seite betroffen ist, bevor sich jemand anderes dafür interessiert.
Bild von Gepostet von
Gepostet von

Matthias Reynders

Audio-Version anhören

Auf einem Smartphone-Display ist das blaue WordPress-Logo mit der Bezeichnung WordPress zu sehen.
Inhaltsverzeichnis

WordPress zählt weltweit zu den mit Abstand meistgenutzten Content-Management-Systemen, entsprechend groß ist die Angriffsfläche, wenn im Kern des Systems eine kritische Lücke auftaucht. Genau das ist mit wp2shell passiert, einer Kombination zweier Schwachstellen, die zusammen eine unautorisierte Codeausführung ermöglichen. Sicherheitsforscher bestätigen bereits aktive Angriffe im Netz, die Zeit zum Handeln ist also denkbar knapp.

Was hinter wp2shell steckt

wp2shell bezeichnet die Kombination zweier Schwachstellen im WordPress-Kern, die zusammen weit gefährlicher sind als jede für sich allein. CVE-2026-63030 sitzt in der REST-API und sorgt für eine Verwechslung zwischen unterschiedlichen Batch-Routen, wodurch sich mehrere Anfragen in einem einzigen Aufruf anders auswerten lassen als vom System eigentlich vorgesehen, TheHackerNews beschreibt den Mechanismus in einer eigenen Analyse ausführlich. CVE-2026-60137 ist eine SQL-Injection im Parameter author__not_in der WP_Query-Klasse, die im Hintergrund mit der MySQL-Datenbank kommuniziert und dort eigentlich nur Autoren herausfiltern soll. Kombiniert erlauben beide Lücken einem anonymen Angreifer Remote Code Execution, also die Ausführung von eigenem Code auf einem fremden Server, unabhängig davon, ob zusätzliche Sicherheits-Plugins installiert sind.

Betroffen sind Installationen von Version 6.8.0 bis 6.8.5 durch die SQL-Injection allein sowie 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1 durch die vollständige, deutlich gefährlichere Kette aus beiden Schwachstellen. Wer eine ältere Version als 6.8 betreibt, bleibt außen vor, was angesichts veralteter Installationen und ihrer eigenen Risiken selten ein wirklicher Trost ist. Entdeckt und gemeldet wurden die beiden Schwachstellen unabhängig voneinander, die REST-API-Lücke von Assetnote und Searchlight Cyber, die SQL-Injection vom Forscherteam TF1T, dtro und haongo, das WordPress-Kernteam reagierte mit einem Notfall-Update für alle drei betroffenen Versionsstränge. Die Details zum offiziellen Patch hat WordPress in einem eigenen Beitrag veröffentlicht, inklusive einer technischen Beschreibung beider Schwachstellen.

Warum die Attacke so gefährlich ist

Die Kombination aus beiden Lücken funktioniert ohne Anmeldung und ohne ein einziges installiertes Plugin, ein Standard-WordPress reicht bereits als Angriffsziel. Genau das unterscheidet wp2shell von den meisten Sicherheitslücken der letzten Jahre, die üblicherweise über anfällige Erweiterungen oder Themes ins System gelangten und sich damit leichter eingrenzen ließen. ExpertInsights bezeichnet die Lücke als erste kritische, unauthentifizierte Remote Code Execution im WordPress-Kern seit knapp einem Jahrzehnt. Wer die Tragweite unterschätzt, riskiert die vollständige Kompromittierung des eigenen Servers, inklusive Datenbank, Kundendaten und im schlimmsten Fall auch verknüpfter Systeme wie Newsletter-Tools oder Zahlungsanbieter.

Schon am 17. Juli 2026 registrierte der Sicherheitsdienstleister Wordfence erste Testanfragen an die REST-API, wenige Minuten später folgte der erste echte Injection-Versuch. Kurz darauf tauchte auf GitHub ein öffentlicher Proof of Concept auf, der die komplette Angriffskette Schritt für Schritt nachvollziehbar machte und damit auch weniger erfahrenen Angreifern den Einstieg erleichterte. Das Bundesamt für Sicherheit in der Informationstechnik stufte die Lage daraufhin auf Warnstufe Orange ein, wie heise in seiner laufenden Berichterstattung beschreibt. Auch SecurityWeek bestätigte aktive Angriffe im Netz und ordnete die Kampagne als einen der ernsteren WordPress-Vorfälle des laufenden Jahres ein.

Was Betreiber jetzt tun müssen

Der wichtigste Schritt ist simpel, auch wenn er im Tagesgeschäft gerne aufgeschoben wird. Prüft, auf welcher WordPress-Version Eure Seite aktuell läuft, und aktualisiert umgehend auf 6.8.6, 6.9.5 oder 7.0.2, je nachdem welchen Versionsstrang Ihr nutzt. Weil die Schwere der Lücke keine Wartezeit erlaubt, hat das Kernteam automatische Hintergrund-Updates für betroffene Versionen erzwungen, viele Seiten laufen dadurch inzwischen bereits auf einem gepatchten Stand, sofern der Hoster diese Funktion nicht aus eigenen Gründen deaktiviert hat. Kontrolliert die Versionsnummer trotzdem selbst im Backend, denn gerade bei Managed-Hosting-Paketen und speziell eingerichteten Servern greifen mitunter eigene Update-Regeln.

  • WordPress-Version im Dashboard unter “Aktualisierungen” prüfen und bei Bedarf manuell auf 6.8.6, 6.9.5 oder 7.0.2 aktualisieren, auch bei mehreren Installationen
  • Server- und Zugriffslogs der letzten Tage auf ungewöhnliche Anfragen an die REST-API durchsehen, insbesondere rund um den 17. Juli
  • Vor größeren Änderungen ein frisches Datenbank-Backup anlegen, damit Ihr im Ernstfall sauber zurückspringen könnt
  • Automatische Updates im Hosting aktivieren, damit künftige Notfall-Patches ohne Verzögerung greifen
  • Bei Verdacht auf eine Kompromittierung Passwörter, Salts und API-Schlüssel konsequent zurücksetzen und Nutzerkonten prüfen

WordPress Pflege als Daueraufgabe

wp2shell zeigt, wie schnell aus einer soliden Website ein offenes Scheunentor werden kann, wenn Updates liegen bleiben oder Zuständigkeiten zwischen Agentur, Hoster und Kunde unklar sind. Gerade der WordPress-Kern galt bislang als vorbildlich gepflegt, umso mehr Aufmerksamkeit verdient eine Lücke dieser Größenordnung. Wer sein CMS (Content-Management-System) nicht regelmäßig wartet, verlässt sich am Ende auf Glück, und Glück ist bekanntlich kein Sicherheitskonzept. Stichtage dieser Art kennt Ihr vielleicht schon vom Barrierefreiheitsstärkungsgesetz, auch dort zählte am Ende jede Woche, und genau wie damals unterstützt Euch unsere WordPress Agentur Düsseldorf auch bei technischer Sicherheit und laufender Wartung Eurer Website.

  • Regelmäßige Updates von WordPress, Themes und Plugins fest im Redaktionskalender verankern, statt sie dem Zufall zu überlassen
  • Eine Web Application Firewall und Login-Schutz einsetzen, um Angriffsversuche früh abzufangen
  • Monitoring und Uptime-Alerts einrichten, damit Auffälligkeiten sofort auffallen und nicht erst Wochen später
  • Eine Staging-Umgebung nutzen, um Updates vor dem Livegang in Ruhe zu testen, statt live auf der eigenen Website zu experimentieren

FAQs zu wp2shell

Was ist wp2shell?

wp2shell ist der Name für eine Kombination aus zwei WordPress Kernschwachstellen, CVE-2026-63030 und CVE-2026-60137. Zusammen ermöglichen sie einem nicht angemeldeten Angreifer, eigenen Code auf einem fremden Server auszuführen, ganz ohne gültigen Account, Plugin oder Zutun der Nutzer. Der Name wp2shell spielt darauf an, dass am Ende der Angriffskette faktisch eine Kontrollübernahme des Servers steht.

Welche WordPress Versionen sind betroffen?

Die SQL-Injection betrifft die Versionen 6.8.0 bis 6.8.5, 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1. Die vollständige Angriffskette mit Codeausführung wirkt ab Version 6.9.0 aufwärts bis einschließlich 7.0.1, ältere Versionen als 6.8 sind von wp2shell nicht betroffen.

Muss ich sofort updaten?

Ja. Da öffentliche Exploit-Codes bereits kursieren und aktive Angriffe bestätigt sind, solltet Ihr umgehend auf 6.8.6, 6.9.5 oder 7.0.2 aktualisieren und nicht auf das nächste reguläre Wartungsfenster warten.

Reicht das automatische Update aus?

In den meisten Fällen ja, weil das Kernteam wegen der Schwere der Lücke erzwungene Hintergrund-Updates aktiviert hat. Prüft die Versionsnummer trotzdem manuell im Dashboard, falls automatische Updates bei Euch deaktiviert wurden oder Euer Hoster eigene Regeln für Updates verwendet.

Wie erkenne ich einen erfolgten Angriff?

Achtet auf unbekannte Administrator-Accounts, veränderte Dateien im Kernverzeichnis und ungewöhnliche Einträge in den Server Logs rund um den 17. Juli 2026. Im Zweifel hilft ein Blick in die Logs Eures Hosters oder ein kurzes Sicherheitsaudit durch einen erfahrenen Dienstleister, gerade wenn Ihr Euch technisch unsicher fühlt.