wp2shell: Wie Angreifer WordPress ohne Passwort übernehmen, und was Sie jetzt tun müssen

Kurzfassung: Die Sicherheitslücke wp2shell (CVE-2026-63030) ermöglicht es Angreifern, vollständige Kontrolle über eine WordPress-Website zu übernehmen. Ganz ohne Login, ohne Plugin, ohne Konfigurationsfehler. Betroffen sind alle WordPress-Installationen von 6.9.0 bis 7.0.1. Der Patch ist verfügbar, aber längst nicht überall eingespielt. Dieser Artikel erklärt, was passiert, wie Sie prüfen ob Sie betroffen sind, und was zu tun ist wenn Ihre Website gehackt wurde.

Eine Anfrage. Vollständiger Zugriff. Kein Passwort nötig.

Es klingt wie ein Horrorszenario aus einem Cyberthriller, ist aber seit Juli 2026 bittere Realität: Ein Angreifer schickt eine einzige HTTP-Anfrage an Ihre WordPress-Website und hat danach vollständigen Zugriff auf den Server. Er muss sich nicht einloggen. Er braucht kein anfälliges Plugin. Er muss keine Schwachstelle in Ihrer Konfiguration suchen. Die Lücke steckt in WordPress Core selbst.

Der Sicherheitsforscher Adam Kues von Searchlight Cyber hat diese Schwachstelle entdeckt und unter dem Namen wp2shell veröffentlicht. Die Bezeichnung ist direkt: wp steht für WordPress, shell für die Kommandozeilenübernahme, die ein Angreifer am Ende erhält. Der CVSS-Score liegt bei 9.8 von 10. Das ist der höchste Schweregrad, den eine Sicherheitslücke erhalten kann.

Über 500 Millionen Websites weltweit laufen auf WordPress. Ein erheblicher Teil davon war bis zur Veröffentlichung des Patches Ende Juli 2026 potenziell angreifbar. Seitdem sind öffentliche Exploits auf GitHub verfügbar, und Sicherheitsunternehmen wie watchTowr haben bereits aktive Angriffe in freier Wildbahn dokumentiert.

Wenn Sie WordPress betreiben und Ihre Installation noch nicht auf Version 6.9.5 oder 7.0.2 aktualisiert ist, sollten Sie diesen Artikel zu Ende lesen, bevor Sie irgendetwas anderes tun.

Wie wp2shell technisch funktioniert

wp2shell ist keine einzelne Schwachstelle, sondern die Kombination aus zwei unabhängigen Fehlern, die erst gemeinsam zur vollständigen Serverübernahme führen. Beide tragen offizielle CVE-Nummern.

Der erste Fehler: SQL Injection in WP_Query (CVE-2026-60137)

WordPress verwaltet intern Datenbankabfragen über eine Klasse namens WP_Query. Diese Klasse hat unter anderem einen Parameter namens author__not_in, der dazu dient, Beiträge bestimmter Autoren aus Suchergebnissen auszuschließen. Der Parameter erwartet ein Array mit Autoren-IDs.

Das Problem: Wenn jemand statt eines Arrays einen einfachen String übergibt, überspringt WordPress den Typ-Check. Der rohe Wert landet direkt in der SQL-Datenbankabfrage, ohne Bereinigung. Das ist lehrbuchmäßige SQL-Injection, bekannt seit den frühen Tagen der Webentwicklung, und trotzdem hat sie sich bis in WordPress 6.8 geschlichen. Betroffen sind alle WordPress-Versionen ab 6.8.0.

Allein wäre das ein ernstes Problem, aber ein beherrschbares. SQL-Injection erfordert in der Regel einen Kontext, über den ein Angreifer die betroffene Funktion überhaupt ansprechen kann. Genau diesen Kontext liefert der zweite Fehler.

Der zweite Fehler: REST API Batch-Route Confusion (CVE-2026-63030)

WordPress bietet seit Version 5.6 aus dem Jahr 2020 einen sogenannten Batch-Endpoint an. Er ist unter /wp-json/batch/v1 erreichbar und ermöglicht es, mehrere REST-API-Anfragen in einem einzigen HTTP-Request zu bündeln. Der Block-Editor nutzt diesen Mechanismus im normalen Betrieb regelmäßig.

Der Endpoint führt intern drei parallele Listen: welche Sub-Anfragen verarbeitet werden sollen, welche Validierungsergebnisse dazu vorliegen, und welche Handler für die Ausführung zuständig sind. Diese drei Listen müssen immer synchron bleiben.

Das tun sie aber nicht, wenn eine Sub-Anfrage frühzeitig abbricht. Tritt ein Fehler auf, wird er zwar in die Validierungsliste eingetragen, aber vergessen, ihn auch in die Handler-Liste einzutragen. Von diesem Punkt an sind die Listen um einen Eintrag versetzt. Jede nachfolgende Sub-Anfrage wird deshalb mit dem falschen Handler verarbeitet, einschließlich des falschen Sicherheitskontexts.

Ein Angreifer kann diesen Fehler gezielt herbeiführen: Er schickt eine Batch-Anfrage mit einer absichtlich kaputten Sub-Anfrage am Anfang, gefolgt von einer zweiten, die den SQL-Injection-Pfad anspricht. Durch die Verschiebung läuft die zweite Anfrage unter einem anderen Handler, umgeht die Zugangsprüfung und landet direkt in der verwundbaren WP_Query-Funktion.

Ergebnis: unauthentifizierte Remote Code Execution auf einer Standard-WordPress-Installation ohne jede Voraussetzung.

wp2shell Angriffskette: REST API Batch Error führt über SQL Injection zu vollständigem Serverzugriff
Die wp2shell-Angriffskette: Zwei unabhängige Lücken, kombiniert zu vollständiger Serverübernahme.

Welche Versionen sind betroffen?

WordPress-Version Risiko Sofortmaßnahme
6.7 und älter Nicht betroffen Trotzdem aktuell halten
6.8.0 bis 6.8.5 SQL Injection, kein direktes RCE Update auf 6.8.6
6.9.0 bis 6.9.4 Vollständige Serverübernahme möglich Sofort auf 6.9.5 updaten
7.0.0 bis 7.0.1 Vollständige Serverübernahme möglich Sofort auf 7.0.2 updaten

WordPress hat für die betroffenen Versionen automatische Zwangsupdates aktiviert. Das klingt beruhigend, ist es aber nicht vollständig. Ob das Update bei Ihrer Installation angekommen ist, hängt vom Hosting-Anbieter und Ihrer WordPress-Konfiguration ab. Prüfen Sie die Version im Backend unter Dashboard, oder nutzen Sie den kostenlosen Checker unter wp2shell.com.

Besonders wichtig: WordPress 6.9 erschien erst am 2. Dezember 2025. Die Lücke betrifft also ausschließlich Installationen, die ein Update innerhalb der letzten acht Monate verpasst haben. Wer Updates vernachlässigt, war seit Dezember exponiert.

Warum der Angriff so schwer zu erkennen ist

Was wp2shell besonders gefährlich macht, ist nicht nur die Schwere der Lücke, sondern wie unauffällig der Angriff aussieht. Der Exploit ist ein gewöhnlicher POST-Request an einen legitimen Core-Endpoint mit einem korrekt formatierten JSON-Body. Keine Shell-Zeichen, keine ungewöhnlich langen URLs, keine auffälligen User-Agents.

Der Block-Editor sendet im normalen Betrieb regelmäßig genau solche Anfragen an denselben Endpoint. Das macht es für Firewalls und Monitoring-Systeme extrem schwer, bösartige Anfragen von legitimen zu unterscheiden.

Hinzu kommt: Viele WordPress-Betreiber entfernen den Generator-Meta-Tag aus dem HTML-Quellcode, weil das als Sicherheitshärtung gilt. Das hat einen unbeabsichtigten Nebeneffekt. Dieser Tag wäre das einzige passive Signal gewesen, über das ein Sicherheitsscanner die WordPress-Version von außen erkennen kann. Wer ihn entfernt hat, ist also genau das System, das jetzt am schwersten zu schützen ist.

Ist Ihre Website bereits gehackt? Diese Zeichen sprechen dafür

Aktive Angriffe laufen bereits. Die Frage ist nicht mehr ob, sondern wie viele Websites betroffen sind. Prüfen Sie Ihre Website auf diese Warnsignale:

  • Besucher werden auf fremde Domains weitergeleitet, oft zu Pharma-Spam, Glücksspiel oder Crypto-Seiten
  • Google zeigt neben Ihrem Domain-Eintrag eine Sicherheitswarnung
  • Ihr Hosting-Anbieter hat die Website wegen verdächtiger Aktivität gesperrt oder Sie kontaktiert
  • Im WordPress-Backend erscheinen Administrator-Konten, die Sie nicht selbst angelegt haben
  • Das Backend lädt ungewöhnlich langsam oder zeigt PHP-Fehlermeldungen
  • Antiviren-Software auf den Geräten Ihrer Kunden schlägt beim Besuch Ihrer Website an
  • Ihre Domain verschickt Spam-Mails, ohne dass Sie etwas gesendet haben
  • In der Google Search Console tauchen Seiten auf, die Sie nie erstellt haben, oft mit Pharma-Keywords in Titel und Beschreibung

Trifft auch nur eines dieser Symptome zu, sollten Sie sofort handeln. Je länger eine kompromittierte Website online bleibt, desto tiefer der Schaden. Nicht nur technisch.

Was nach einem Hack wirklich passiert: Der zeitliche Ablauf

Viele Betroffene stellen sich einen Hack als einmaliges Ereignis vor. In der Praxis ist es ein Prozess, der sich über Stunden und Tage entfaltet und dessen schlimmste Auswirkungen erst Wochen nach dem Einbruch sichtbar werden.

Die ersten Minuten: Ein automatisierter Scanner findet Ihre ungepatchte Installation. Der eigentliche Angriff dauert Sekunden. Der Angreifer hat zu diesem Zeitpunkt bereits Shell-Zugriff auf den Server und liest das Dateisystem aus.

Stunde 1 bis 6: Jetzt geht es darum, den Zugriff zu sichern. Der Angreifer legt eine PHP-Backdoor ab, meist in einem unauffälligen Verzeichnis wie dem Upload-Ordner oder als umbenannte Datei in einem Plugin-Verzeichnis. Diese Backdoor überlebt Passwort-Resets, Plugin-Deinstallationen und oberflächliche Bereinigungen. Sie bleibt aktiv, bis sie explizit gefunden und entfernt wird.

Stunde 6 bis 24: Abhängig vom Ziel des Angreifers beginnt jetzt die Nutzungsphase. Bei SEO-Spam werden tausende versteckte Seiten angelegt, sichtbar für Google, unsichtbar für echte Besucher. Bei Spam-Versand wird Ihr Mailserver genutzt, um Massenanfragen zu verschicken. Bei Datendiebstahl werden Datenbank-Dumps erstellt und übertragen.

Tag 2 bis 7: Google beginnt, Malware-Signale zu registrieren. Die Domain wird als gefährlich markiert. In der Search Console erscheinen manuelle Maßnahmen oder unbekannte Seiten. Der organische Traffic bricht ein, oft über Nacht.

Ab Tag 7: Die eigentlichen Kosten werden sichtbar. E-Mail-Domains landen auf Blacklists. Kunden bekommen Browser-Warnmeldungen. Rankings, die über Monate oder Jahre aufgebaut wurden, kollabieren. Google-Penalties, die nach einem Hack entstehen, brauchen in der Regel Wochen bis Monate, um wieder aufgehoben zu werden.

Und das alles, weil ein Update nicht eingespielt wurde.

Drei Fälle aus unserer Praxis

Die folgenden Szenarien sind repräsentativ für Anfragen, die uns in den letzten Jahren erreicht haben. Namen und Details sind verändert.

Der Onlineshop, der über Nacht verschwand

Montagmorgen, kurz nach acht. Der Besitzer eines WooCommerce-Shops rief an, weil sein Hoster die Website gesperrt hatte. In der Nacht hatte die Installation tausende Spam-Mails verschickt, die IP-Adresse des Servers stand auf mehreren internationalen Blacklists. Der Shop war nicht erreichbar, die Kunden verwirrten die Bounce-Mails. Das Plugin-Update, das die Lücke geschlossen hätte, war seit sechs Wochen verfügbar. Es war nie eingespielt worden.

Die Unternehmenswebsite mit fremden Admin-Konten

Ein mittelständisches Unternehmen aus München meldete sich, weil ein Geschäftspartner ihnen mitgeteilt hatte, ihre Kontaktseite zeige plötzlich Werbung für ein Potenzmittel. Im Backend fanden sich drei Administratoren-Konten, die keiner der Mitarbeiter angelegt hatte. Die Backdoor steckte in einem veralteten Theme, das schon seit Jahren nicht mehr aktiv war, aber nie gelöscht worden war. Die Bereinigung dauerte drei Tage, der Reputationsschaden bei zwei Bestandskunden war nicht reparierbar.

Die Agentur, die es selbst nicht bemerkte

Eine Digitalmarketing-Agentur wandte sich an uns, weil ihr Suchtraffic innerhalb von zwei Wochen auf null gefallen war. Keine technischen Fehler, keine Server-Probleme. Die Google Search Console zeigte hunderte neuer Unterseiten mit Glücksspiel-Keywords, alle unter ihrer Domain. Die Malware war bereits 14 Tage aktiv gewesen, bevor jemand es bemerkte. Sechs Wochen bis zur vollständigen Wiederherstellung der Rankings.

Was alle drei Fälle gemeinsam haben: Der eigentliche Einbruch dauerte Sekunden. Der Schaden entstand in den Tagen danach. Und in keinem Fall wäre das nötig gewesen.

Schnell-Hilfe: Was Sie jetzt tun müssen, wenn Ihre Website gehackt wurde

Notfall-Kontakt CMS ADMINS

+49 89 21550588-8

24/7 erreichbar. Reaktionszeit ab 24 Stunden je nach SLA-Stufe. Erstprüfung kostenlos.

Diese fünf Schritte in der richtigen Reihenfolge können den Schaden erheblich begrenzen:

Schritt 1: Website offline nehmen. Deaktivieren Sie die Website beim Hoster oder leiten Sie auf eine Wartungsseite um. Das schützt Ihre Besucher vor Malware-Auslieferung und stoppt aktiven Spam-Versand. Solange die Website erreichbar ist, läuft der Schaden weiter.

Schritt 2: Alle Passwörter sofort ändern. WordPress-Administrator-Passwörter, FTP- und SFTP-Zugänge, das Hosting-Control-Panel, die Datenbankzugänge, alle E-Mail-Konten unter der betroffenen Domain. Alle, nicht nur einzelne.

Schritt 3: Nichts löschen, bevor ein Backup vorliegt. Der Instinkt, sofort infizierte Dateien zu entfernen, ist verständlich, aber kontraproduktiv. Wer ohne Backup bereinigt, vernichtet möglicherweise forensische Spuren, die für die Ursachen-Analyse wichtig wären. Und wer Backdoors nicht vollständig findet, hat nach der Bereinigung noch immer eine offene Hintertür.

Schritt 4: Den Hoster informieren. Viele Hosting-Anbieter führen eigene Malware-Scans durch und können den Zeitpunkt des Einbruchs anhand von Server-Logs eingrenzen. Diese Information ist für die Bereinigung wertvoll.

Schritt 5: Professionelle Bereinigung beauftragen. Oberflächliche Maßnahmen wie Plugin-Deinstallation oder Passwort-Reset reichen nicht, wenn Backdoors installiert wurden. Diese verstecken sich gezielt in unauffälligen Pfaden und überleben einfache Bereinigungsversuche. Eine saubere Wiederherstellung erfordert vollständigen Code-Audit, Datenbank-Analyse und Schließen des Einfallswegs.

Wie CMS ADMINS Ihre gehackte Website wiederherstellt

Wir sind seit über zehn Jahren auf WordPress-Notfälle spezialisiert. In dieser Zeit haben wir Hunderte von Websites nach Hacks wiederhergestellt, von kleinen Unternehmensseiten bis zu WooCommerce-Shops mit tausenden Bestellungen. wp2shell ist uns bekannt.

Unser Ablauf ist klar strukturiert und hat sich in der Praxis bewährt.

Zuerst die kostenlose Erstprüfung. Sie schildern die Situation, wir schauen uns die Installation an. Dann erhalten Sie ein verbindliches Festpreis-Angebot ohne Stundensatz und ohne versteckte Kosten. Keine bösen Überraschungen nach der Bereinigung.

Bevor irgendetwas bereinigt wird, sichern wir den aktuellen Zustand vollständig. Das schützt Sie im Notfall und ermöglicht uns die forensische Analyse. Dann folgt die eigentliche Bereinigung: Malware aus Dateisystem und Datenbank entfernen, alle Backdoors identifizieren und beseitigen, Theme- und Plugin-Dateien gegen bekannte Signaturen prüfen, den Einfallsweg dauerhaft schließen.

Nach der Bereinigung kommt die Absicherung. Ohne sie ist die nächste Kompromittierung nur eine Frage der Zeit. Wir richten reportedIP Pro ein, inklusive, ohne Aufpreis, für sechs Monate nach der Bereinigung. Das Plugin bietet Brute-Force-Schutz mit automatischer IP-Sperrung nach Fehlversuchen, SMS-basierte Zwei-Faktor-Authentifizierung für alle Administrator-Konten, IP-Reputation aus dem deutschen Bedrohungsnetzwerk und ein vollständiges Login-Protokoll.

SLA-Stufe Reaktionszeit Für wen geeignet
Critical 24 Stunden Online-Shops, umsatzkritische Auftritte, Lead-Generierung
Express 48 Stunden Unternehmenswebsites, Blogs mit aktivem Traffic
Standard 3 Werktage Statische Info-Seiten, niedrige Traffic-Priorität

Kostenlose Erstprüfung anfragen

Warum wp2shell kein Ausreißer ist

Es ist verlockend, wp2shell als seltenes Ereignis abzutun. Eine Lücke dieser Schwere, direkt im Core, ohne Voraussetzungen. Das passiert doch nicht oft.

Stimmt, in dieser Kombination ist es außergewöhnlich. Aber der Grundmechanismus ist sehr gewöhnlich. Patchstack, einer der führenden WordPress-Sicherheitsanbieter, registriert jeden Monat hunderte neue CVEs in WordPress-Plugins, Themes und zunehmend auch im Core. Mehr als 95 Prozent aller WordPress-Hacks nutzen bekannte, längst gepatchte Schwachstellen aus. Nicht Null-Day-Lücken. Nicht raffinierte APT-Angriffe. Einfach nur veraltete Software.

Das bedeutet: Wer Updates konsequent einspielt, überlebt die allermeisten Angriffe ungescathed. Und wer das nicht tut, bietet Angreifern ein öffentlich dokumentiertes Einfallstor.

Dauerschutz: Was ein Wartungsvertrag konkret bedeutet

Unser WordPress-Wartungsvertrag beginnt bei 9,50 Euro pro Monat. Dafür übernehmen wir die regelmäßige Aktualisierung von WordPress Core, allen Plugins und allen Themes. Sicherheits-Updates werden priorisiert und zeitnah eingespielt, ohne dass Sie sich darum kümmern müssen.

Dazu kommen 60 Tage Echtzeit-Backups auf deutschen Servern. Jeder Zustand der letzten 60 Tage ist wiederherstellbar. 24/7-Monitoring, das Ausfälle und Malware-Signale erkennt, bevor Ihre Kunden sie bemerken. Und reportedIP Pro ist in jedem Wartungspaket von CMS ADMINS inklusive: Brute-Force-Schutz, SMS-Zwei-Faktor-Authentifizierung, IP-Reputation aus dem deutschen Bedrohungsnetzwerk, DSGVO-konform mit Serverstandort Deutschland.

Ein Wartungsvertrag ist kein Schutz gegen alle Risiken. Aber er schließt die häufigste Einbruchspforte: veraltete Software mit bekannten Schwachstellen.

Wartungsvertrag ab 9,50 Euro pro Monat

Häufig gestellte Fragen zu wp2shell

Hat WordPress meine Installation automatisch gepatcht?
WordPress hat für betroffene Versionen ein Zwangsupdate aktiviert. Ob es bei Ihrer Installation angekommen ist, hängt jedoch vom Hosting-Anbieter und Ihrer WordPress-Konfiguration ab. Prüfen Sie die Version unter Dashboard in WordPress oder über wp2shell.com. Vertrauen Sie nicht darauf, dass das Update automatisch gelaufen ist.

Ich betreibe WordPress 6.8. Bin ich in Sicherheit?
Für 6.8-Installationen besteht die SQL-Injection-Lücke (CVE-2026-60137), aber keine vollständige Remote Code Execution. Das ist weniger kritisch, aber nicht harmlos. Das Update auf 6.8.6 ist trotzdem dringend empfohlen.

Reicht das Core-Update, oder muss ich mehr tun?
Das Core-Update schließt beide Lücken vollständig. Wenn Ihre Website jedoch in dem Zeitraum erreichbar war, in dem öffentliche Exploits verfügbar waren, sollten Sie auch prüfen, ob Backdoors hinterlassen wurden. Das Update entfernt keine Backdoors, die bereits platziert wurden.

Wie erkenne ich, ob auf meiner Website eine Backdoor aktiv ist?
Von außen kaum. Backdoors werden gezielt in unauffälligen Verzeichnissen und mit harmlosen Dateinamen versteckt. Sie überleben Plugin-Deinstallationen und Passwort-Resets. Ein vollständiger Code-Audit durch einen Spezialisten ist die einzige verlässliche Methode, alle Backdoors zu finden und zu entfernen.

Was kostet die professionelle Bereinigung bei CMS ADMINS?
Die Erstprüfung ist kostenlos. Danach erhalten Sie ein verbindliches Festpreis-Angebot abhängig vom Ausmaß der Kompromittierung. Kein Stundensatz, keine offene Kostenstruktur. Kontakt: +49 89 21550588-8

Wie lange dauert eine professionelle Bereinigung?
Die technische Bereinigung dauert in der Regel zwei bis sechs Stunden. Die Reaktionszeit nach Ihrer Anfrage beträgt 24 Stunden (Critical), 48 Stunden (Express) oder drei Werktage (Standard).

Ist meine Cyber-Versicherung zuständig?
Das hängt von Ihrer Police ab. Viele Versicherungen fordern den Nachweis angemessener Sicherheitsmaßnahmen als Voraussetzung für die Erstattung. Ein Wartungsvertrag mit dokumentierten Update-Intervallen kann hier als Nachweis dienen. Sprechen Sie mit Ihrem Versicherer.

Ich habe Cloudflare. Bin ich geschützt?
Cloudflare hat WAF-Regeln für beide CVEs ausgerollt, auf allen Plänen inklusive Free. Das reduziert das Risiko, ist aber kein vollständiger Schutz und kein Ersatz für das Einspielen des Patches. Cloudflare selbst empfiehlt ausdrücklich, trotzdem zu aktualisieren.

Fazit

wp2shell ist die kritischste WordPress-Schwachstelle seit Jahren. Die gute Nachricht: Patches sind verfügbar, das Update ist kostenlos und dauert Minuten. Die schlechte Nachricht: Nicht jede der über 500 Millionen WordPress-Installationen weltweit hat das Update bereits erhalten. Öffentliche Exploits existieren. Aktive Angriffe laufen.

Wenn Sie sich nicht sicher sind, ob Ihre Installation aktuell ist, prüfen Sie es jetzt. Wenn Sie den Verdacht haben, dass Ihre Website bereits kompromittiert wurde, handeln Sie sofort und holen Sie sich professionelle Hilfe.

Und wenn Sie sichergehen wollen, dass Ihnen ein nächster Vorfall dieser Art nicht passiert: Ein WordPress-Wartungsvertrag ist die einfachste und günstigste Lösung, die es gibt.


Quellen: Searchlight Cyber (wp2shell.com), BleepingComputer, The Hacker News, Hadrian.io, Rapid7, watchTowr. CVE-Details: CVE-2026-63030, CVE-2026-60137. Letzte Aktualisierung: 20. Juli 2026.

Vorheriger Beitrag
Bolt.new, Lovable & Co. auf deutschen Servern: DSGVO-, NIS2- und CLOUD-Act-konform in 48 Stunden