Auf einen Blick: Bin ich betroffen?
| WordPress-Version | Status |
|---|---|
6.8.5 und älter | Von dieser Angriffskette nicht betroffen |
6.9.0 – 6.9.4 | Betroffen – sofort handeln |
6.9.5 und neuer (6.9er-Zweig) | Geschlossen |
7.0.0 – 7.0.1 | Betroffen – sofort handeln |
7.0.2 und neuer (7.0er-Zweig) | Geschlossen |
So prüfen Sie Ihre Version in 30 Sekunden: Melden Sie sich im WordPress-Backend an. Unten rechts im Dashboard steht „Version x.x.x“. Alternativ: Werkzeuge → Website-Zustand → Bericht.
Wichtig: Dass ältere Versionen wie 6.8.x von dieser Lücke nicht betroffen sind, heißt nicht, dass sie sicher sind. Sie enthalten schlicht andere, teils seit Monaten bekannte Schwachstellen. Wer noch auf 6.8 oder älter läuft, hat ein anderes Problem – aber ebenfalls ein Problem.
Was genau ist bei wp2shell passiert?
Entdeckt wurde die Schwachstelle vom Sicherheitsforschungsteam von Searchlight Cyber, konkret durch deren Angriffsflächen-Einheit Assetnote. Der Fund wurde verantwortungsvoll über das HackerOne-Programm von WordPress gemeldet – also erst an die Entwickler, nicht an die Öffentlichkeit.
Das Besondere an wp2shell: Es ist nicht eine Lücke, sondern zwei. Und genau darin liegt die Gefahr.
Schwachstelle 1: Die SQL-Injection (CVE-2026-60137)
Die erste Lücke steckt in WP_Query – das ist die zentrale Komponente, über die WordPress praktisch jede Datenbankabfrage abwickelt. Jeder Beitrag, jede Seite, jede Übersicht läuft darüber.
Ein bestimmter Parameter dieser Abfrage (author__not_in) wird nicht ausreichend gefiltert. Das erlaubt eine sogenannte SQL-Injection: Ein Angreifer schmuggelt eigene Datenbankbefehle in eine ganz normale Anfrage ein und bringt die Datenbank dazu, Daten herauszugeben, die sie nie herausgeben sollte.
Für sich allein wäre das bereits unangenehm – aber der Zugriff auf diesen Parameter war eigentlich abgesichert. Man musste angemeldet sein.
Schwachstelle 2: Die Routen-Verwechslung (CVE-2026-63030)
Genau hier setzt die zweite Lücke an. Sie steckt im sogenannten Batch-Endpunkt der WordPress-REST-Schnittstelle, erreichbar unter /wp-json/batch/v1. Diese Schnittstelle erlaubt es, mehrere Anfragen in einem einzigen Aufruf zu bündeln – praktisch für Apps und Integrationen, standardmäßig aktiv und ohne Anmeldung erreichbar.
Der Fehler: Bei einer bestimmten, verfremdeten Schreibweise des Anfragepfads lesen die Prüfung und die Ausführung diesen Pfad unterschiedlich. Die Sicherheitsprüfung sieht einen harmlosen Pfad und winkt durch. Die Ausführung leitet die Anfrage dann an einen anderen Handler weiter – einen, der die Anmeldepflicht nicht durchsetzt.
Die Verkettung
Und damit fällt die Absicherung der ersten Lücke. Über die Routen-Verwechslung wird die SQL-Injection erreichbar, ohne dass sich jemand anmelden muss.
Das BSI bewertet die einzelnen Lücken bereits hoch (CVE-2026-60137 mit CVSS 9.1). Die Kombination beider erreicht einen CVSS-Wert von 9.8 von 10 – praktisch das Maximum. Remote ausnutzbar, keine Authentifizierung, keine Nutzerinteraktion, keine besondere Konfiguration nötig.
Searchlight Cyber formulierte es so: Der Angriff habe keinerlei Voraussetzungen und funktioniere gegen eine Standardinstallation ohne Plugins.
Chronologie: Warum das Wochenende so kritisch war
| Datum | Ereignis |
|---|---|
Fr, 17.07.2026 | WordPress veröffentlicht Notfall-Updates 6.9.5 und 7.0.2. Searchlight Cyber macht die Lücke öffentlich – ohne technische Details, um Zeit zum Patchen zu geben. WordPress.org aktiviert erzwungene automatische Updates. |
Sa, 18.07.2026 | Das BSI veröffentlicht die Cyber-Sicherheitswarnung 2026-271984-1032, Warnstufe Orange. |
Wochenende 18./19.07. | Sicherheitsforscher rekonstruieren die Lücke aus dem veröffentlichten Patch. Erste Proof-of-Concept-Codes kursieren. |
Di, 21.07.2026 | Die US-Behörde CISA nimmt beide CVEs in ihren Katalog der aktiv ausgenutzten Schwachstellen auf – bevor ein fertiger Exploit öffentlich war. Das heißt: Organisierte Angreifer waren bereits aktiv. |
Mi, 22.07.2026 | Ein vollständig funktionsfähiger, automatisierter Exploit wird öffentlich. Ab hier braucht ein Angreifer kein Fachwissen mehr – nur noch das Werkzeug. |
seit 23.07.2026 | Massenhafte automatisierte Angriffe. Bestätigt unter anderem durch Bitdefender, Patchstack und Wiz. |
Der Zeitpunkt der Veröffentlichung – Freitagabend europäischer Zeit – wird in Fachkreisen kritisch diskutiert. Wer nicht aktiv Sicherheitsmeldungen verfolgt, hat ein ganzes Wochenende ahnungslos verbracht, während der Angriff bereits lief.
Genau das ist der Punkt, an dem die meisten kleinen Websitebetreiber verlieren: nicht am fehlenden Patch, sondern daran, dass niemand hinschaut. Genau dafür gibt es den WordPress-Wartungsvertrag.
Was Angreifer nach dem Einbruch tatsächlich tun
Schritt 1: Massenscan
Schritt 2: Der Einbruch – in etwa zwei Minuten
Läuft der eigentliche Angriff an, läuft er vollautomatisch durch. Vom ersten Aufruf bis zum Administratorzugang vergehen nach Bitdefender-Messungen rund zwei Minuten. Kein Mensch sitzt dabei an der Tastatur.
Über die SQL-Injection wird zunächst die Datenbank ausgelesen – unter anderem der Passwort-Hash des Administrators, der sich später offline knacken lässt. Anschließend missbraucht die Angriffskette zwei völlig legitime WordPress-Mechanismen (den oEmbed-Cache für Link-Vorschauen und ein zwischengespeichertes Customizer-Änderungsset), um einen manipulierten Wert in die Optionen-Tabelle zu schreiben. Das Ergebnis: ein voll funktionsfähiges Administratorkonto, das der Angreifer selbst kontrolliert.
Schritt 3: Die Persistenz
Mit Administratorrechten installiert der Angreifer ein präpariertes Plugin. Das ist kein Hack mehr – das ist die normale WordPress-Funktion, die jeder Administrator hat.
Dieses Plugin legt sogenannte Webshells ab: kleine PHP-Dateien an zufällig benannten Pfaden innerhalb von wp-content, die Befehle über normale HTTP-Aufrufe entgegennehmen. Damit hat der Angreifer eine Fernsteuerung für Ihren Server – dauerhaft, auch nachdem die eigentliche Lücke geschlossen wurde.
Beobachtet wurden dabei mehrere Varianten:
- Webshells mit eigenem Zugangstoken, damit kein Dritter sie mitbenutzen kann
- Eine minimale Variante, die bei Aufruf einen HTTP-404-Fehler zurückgibt – damit taucht sie in normalen Server-Logs schlicht nicht auf
- Eigene, versteckte REST-API-Hintertüren, die Befehle in kodierter Form entgegennehmen
Schritt 4: Was danach kommt
Ab hier wird es unternehmensspezifisch. Beobachtet und vom BSI genannt werden:
- Datendiebstahl – Kundendaten, Kontaktformular-Einträge, Bestelldaten, Zugangsdaten
- Backdoors – dauerhafte Zugänge, oft mehrfach redundant angelegt
- Cryptomining – Ihre Serverleistung wird zum Schürfen von Kryptowährung missbraucht
- SEO-Spam und Weiterleitungen – Ihre Website verkauft plötzlich Potenzmittel oder leitet Besucher auf Betrugsseiten
- Versand von Spam-Mails über Ihren Server, was Ihre Domain auf Blacklists befördert
- Ransomware – bei Angriffsmustern dieser Art in der Vergangenheit ein regelmäßiger nächster Schritt, sobald ein menschlicher Angreifer den Zugang übernimmt
Ist bei Ihnen bereits einer dieser Fälle eingetreten, hilft die WordPress-Notfall-Reparatur – Bereinigung und Absicherung zum Festpreis.
Der wichtigste Befund: Auch gescheiterte Angriffe hinterlassen Spuren
Das ist der Teil, den ich für die praktisch wichtigste Erkenntnis der gesamten Bitdefender-Analyse halte.
In dem untersuchten Fall lief der Angriff dreimal, bevor er vollständig erfolgreich war. Die ersten beiden Versuche legten jeweils ein Administratorkonto an – und blieben dann stecken. Kein Plugin, keine Webshell. Erst der dritte Durchlauf ging komplett durch.
Der Grund dafür ist strukturell: Die Aufräumroutine des Angriffswerkzeugs läuft nur bei vollständigem Erfolg. Bricht der Angriff vorher ab, bleibt das angelegte Administratorkonto einfach liegen.
Für Sie bedeutet das zweierlei:
Erstens: Suchen Sie nicht zuerst nach einer Webshell. Suchen Sie nach einem Administratorkonto, das Sie nicht angelegt haben. Das ist der zuverlässigste erste Indikator.
Zweitens: Ein solches verwaistes Konto ohne weitere Spuren ist kein Fehlalarm. Es ist der Beweis, dass Ihre Website gezielt angegriffen wurde, dass die Kette zumindest teilweise durchlief – und dass der Angreifer wiederkommen kann. Wenn Sie so einen Fund haben und ihn nicht selbst einordnen möchten: Das ist genau der Fall für ein WordPress-Sicherheitsaudit.
Woran erkenne ich, dass meine Website betroffen ist?
Im WordPress-Backend
Auf dem Server / per FTP
In den Server-Logs
Von außen sichtbar
Ein Hinweis zu den Namensmustern: w2s_, wp2shell.invalid und ähnliche Bezeichnungen sind Voreinstellungen des öffentlich verfügbaren Angriffswerkzeugs. Jeder halbwegs versierte Angreifer ändert sie in zwei Minuten. Verlassen Sie sich also nicht darauf, sie zu finden – die verlässlichen Indikatoren sind die verhaltensbasierten: ein Konto, das niemand angelegt hat. Eine Datei, die niemand hochgeladen hat.
Unsicher, ob ein Fund relevant ist? Schicken Sie mir kurz, was Sie gefunden haben – über das Kontaktformular oder telefonisch. Eine Ersteinschätzung kostet Sie nichts.
Was Sie jetzt tun sollten – in dieser Reihenfolge
Fall A: Ihre Website ist bereits auf 6.9.5 oder 7.0.2 – und war es schnell
Wenn die erzwungenen automatischen Updates bei Ihnen gegriffen haben, bevor die Angriffswelle richtig anlief, stehen Ihre Chancen gut. Trotzdem:
- Verlassen Sie sich nicht darauf, dass das Auto-Update lief. Prüfen Sie die Versionsnummer manuell. Bei stark angepassten Installationen sind automatische Updates häufig deaktiviert – oft aus Sorge vor Kompatibilitätsproblemen.
- Gehen Sie die Erkennungs-Checkliste oben trotzdem einmal durch. Das kostet 20 Minuten. Alternativ übernehme ich die Prüfung im WordPress-Sicherheitsaudit.
- Prüfen Sie Ihre Website zusätzlich mit dem kostenlosen Checker unter wp2shell.com, den Searchlight Cyber bereitstellt.
Fall B: Sie laufen noch auf einer betroffenen Version
- Aktualisieren Sie sofort auf 6.9.5 bzw. 7.0.2. Nicht „beim nächsten Wartungsfenster“ – jetzt.
- Falls ein Update kurzfristig nicht möglich ist: Lassen Sie anonyme Zugriffe auf /wp-json/batch/v1 über eine Web Application Firewall blockieren. Das ist auch die Empfehlung des BSI. Cloudflare hat dafür eigene Regeln ausgerollt. Wichtig: Das ist ein Notpflaster, kein Ersatz für das Update.
- Anschließend: Kompromittierungsprüfung. Siehe Fall C.
Fall C: Sie haben Anzeichen eines Angriffs gefunden
Hier gilt eine Regel, die sich nicht verhandeln lässt: Ein Update schließt die Tür.
-> Es wirft niemanden raus, der schon drin ist.
Wenn ein Angreifer eine Webshell hinterlassen hat, funktioniert diese nach dem Update genauso weiter wie vorher. Das Update entfernt nichts.
Machen Sie in dieser Reihenfolge:
- Nichts löschen. So verständlich der Impuls ist – Sie zerstören damit Beweise, die Sie später für die Dokumentationspflicht brauchen.
- Sichern Sie den aktuellen Zustand – Dateien und Datenbank, als forensische Kopie. Getrennt von Ihren regulären Backups.
- Sichern Sie die Server-Logs. Viele Hoster löschen diese nach 7 bis 14 Tagen. Beim wp2shell-Zeitfenster ab dem 17. Juli wird das jetzt knapp.
- Nehmen Sie die Website vom Netz oder in den Wartungsmodus – insbesondere, wenn personenbezogene Daten betroffen sein könnten.
- Setzen Sie alle Zugangsdaten neu: WordPress-Benutzer, Datenbank, FTP/SFTP, Hosting-Panel, und die Sicherheitsschlüssel in der wp-config.php.
- Prüfen Sie die Dokumentationspflicht – dazu gleich mehr.
- Holen Sie professionelle Hilfe, wenn Sie unsicher sind. Eine übersehene Hintertür bedeutet, dass Sie in vier Wochen wieder von vorn anfangen. Die WordPress-Notfall-Reparatur deckt genau diesen Fall ab.
Zum Thema „einfach ein Backup einspielen“: Das ist der häufigste Fehler. Wenn Sie ein Backup vom 20. Juli einspielen, spielen Sie mit hoher Wahrscheinlichkeit die Hintertür gleich mit ein. Ein Backup hilft nur, wenn es nachweislich vor dem ersten Angriff entstanden ist – und wenn Sie danach sofort patchen, bevor die Seite wieder öffentlich erreichbar ist.
Die rechtliche Seite: Welche Fristen jetzt gelten
Das ist der Teil, den fast alle unterschätzen. Ein Website-Hack ist in Deutschland nicht nur ein technisches Problem – er kann eine meldepflichtige Datenschutzverletzung sein.
Die folgenden Ausführungen sind eine allgemeine Orientierung und ersetzen keine Rechtsberatung. Für Ihren konkreten Fall wenden Sie sich bitte an Ihren Datenschutzbeauftragten oder einen Fachanwalt.
Die 72-Stunden-Frist (Art. 33 DSGVO)
Werden bei einem Angriff personenbezogene Daten verletzt – und das ist bei einem Serverzugriff dieser Art regelmäßig anzunehmen –, müssen Sie den Vorfall der zuständigen Aufsichtsbehörde melden. Die Frist beträgt 72 Stunden ab Kenntniserlangung.
Drei Punkte, die dabei regelmäßig zu Problemen führen:
- Die Frist läuft durch. Wochenenden und Feiertage zählen mit. Wer am Freitagnachmittag entdeckt, dass die Seite kompromittiert ist, hat bis Montagnachmittag Zeit.
- „Kenntnis“ bedeutet nicht „vollständige Aufklärung“. Der begründete Verdacht reicht aus, um die Uhr zu starten. Sie müssen nicht warten, bis Sie alles verstanden haben – Sie dürfen und sollen die Meldung gegebenenfalls nachträglich ergänzen.
- Wer die Frist versäumt, muss das begründen. Eine verspätete Meldung ist möglich, aber begründungspflichtig.
Für Verantwortliche in Nordrhein-Westfalen ist die zuständige Behörde die Landesbeauftragte für Datenschutz und Informationsfreiheit NRW (LDI NRW). Diese stellt ein Online-Meldeformular bereit.
Die Benachrichtigung der Betroffenen (Art. 34 DSGVO)
Besteht durch den Vorfall voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der Betroffenen, müssen Sie zusätzlich die betroffenen Personen selbst informieren – unverzüglich, ohne feste Stundenfrist, aber ohne schuldhaftes Zögern.
Bei Gesundheitsdaten, Kontodaten oder Zugangsdaten ist von einem hohen Risiko in aller Regel auszugehen.
Die Dokumentationspflicht (Art. 33 Abs. 5 DSGVO)
Diese gilt immer – auch dann, wenn Sie zu dem Ergebnis kommen, dass keine Meldung erforderlich ist. Sie müssen dokumentieren:
- was passiert ist
- welche Auswirkungen der Vorfall hatte
- welche Abhilfemaßnahmen Sie ergriffen haben
- und, falls Sie nicht gemeldet haben: warum nicht
Diese Dokumentation muss der Aufsichtsbehörde auf Verlangen vorgelegt werden können. Deshalb der Punkt weiter oben: nichts löschen, bevor Sie dokumentiert haben.
Wenn eine Agentur oder ein Hoster im Spiel ist (Art. 33 Abs. 2 DSGVO)
Sind Sie als Dienstleister für die Website eines Kunden verantwortlich, sind Sie in der Regel Auftragsverarbeiter. Dann gilt: Sie müssen Ihren Auftraggeber unverzüglich informieren, sobald Ihnen die Verletzung bekannt wird. Die 72-Stunden-Frist gegenüber der Behörde läuft beim Verantwortlichen – aber sie startet praktisch mit Ihrer Meldung.
Für Arztpraxen, Anwälte und Steuerberater: § 203 StGB
Berufsgeheimnisträger haben eine zusätzliche Schwelle. Der unbefugte Zugriff Dritter auf Patienten- oder Mandantendaten kann strafrechtliche Relevanz nach § 203 StGB entfalten. Zwar setzt der Straftatbestand ein Offenbaren voraus – aber die berufsrechtlichen Sorgfaltspflichten hinsichtlich der technischen Absicherung bestehen unabhängig davon und werden im Schadensfall geprüft.
Für Praxen kommt hinzu: Kontaktformulare mit Terminwünschen und Symptomschilderungen, Rückrufbitten, Online-Terminbuchungen – all das sind Gesundheitsdaten im Sinne von Art. 9 DSGVO. Diese unterliegen dem strengsten Schutzniveau, das die DSGVO kennt.
Bußgeldrahmen
Verstöße gegen die Melde- und Dokumentationspflichten nach Art. 33 fallen unter Art. 83 Abs. 4 DSGVO: bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, was höher ist.
Bei einem Einzelunternehmen oder einer Praxis liegen realistische Bußgelder deutlich darunter. Aber der entscheidende Punkt ist ein anderer: Aufsichtsbehörden bewerten den Umgang mit dem Vorfall mindestens so stark wie den Vorfall selbst. Wer sauber dokumentiert, fristgerecht meldet und nachvollziehbar reagiert, steht am Ende deutlich besser da als jemand, der den Vorfall aussitzt.
Warum wp2shell anders ist als der typische WordPress-Hack
Die allermeisten WordPress-Angriffe laufen über veraltete Plugins. Ein Kontaktformular-Plugin, das seit zwei Jahren kein Update mehr bekommen hat. Ein Slider, dessen Entwickler das Projekt eingestellt hat. Ein Theme aus einem dubiosen Marktplatz.
Die Konsequenz daraus war bisher: Wer seine Plugins schlank hält, aktuell hält und aus vertrauenswürdigen Quellen bezieht, hat einen großen Teil des Risikos im Griff.
wp2shell durchbricht diese Logik. Die Lücke steckt im Kern – in dem Teil von WordPress, den jede einzelne Installation hat, ohne Ausnahme. Es gibt keine Konfiguration, mit der Sie sich hätten schützen können. Kein „ich benutze ja kaum Plugins“. Kein „meine Seite ist zu klein, um interessant zu sein“.
Der letzte Punkt ist ohnehin der hartnäckigste Irrtum. Die Scanner, die derzeit das Netz durchkämmen, wissen nicht, ob Ihre Praxis fünf oder fünfzig Mitarbeiter hat. Sie prüfen nur eines: Ist der Endpunkt erreichbar, ja oder nein. Eine Zahnarztpraxis in Frechen ist für einen automatisierten Scanner exakt so interessant wie ein Konzern.
Was zählt, ist nicht Ihre Größe. Was zählt, ist Ihre Reaktionszeit.
So schützen Sie sich künftig
Aus wp2shell lässt sich eine Lehre ziehen, die über diese eine Lücke hinausgeht: Der Patch war am 17. Juli verfügbar. Angegriffen wurde ab dem 21. Juli. Dazwischen lagen vier Tage.
Wer in diesen vier Tagen aktualisiert hat, war sicher. Wer erst zwei Wochen später hingeschaut hat, hatte möglicherweise schon Besuch.
Die Frage ist also nicht, ob Sicherheitslücken auftreten – das werden sie, regelmäßig. Die Frage ist, wie schnell Sie davon erfahren und wie schnell reagiert wird.
Konkret bedeutet das:
- Automatische Updates für den WordPress-Kern aktivieren. Bei wp2shell hat das viele Seiten gerettet. Sich darauf zu verlassen ist trotzdem keine Strategie – aber es abzuschalten ist fahrlässig.
- Ein aktuelles Backup-Konzept, mit Aufbewahrung über mehrere Wochen und Speicherung außerhalb des Webservers. Ein Backup, das auf demselben Server liegt, den der Angreifer kontrolliert, ist kein Backup.
- Eine Web Application Firewall als vorgelagerte Schutzschicht. Sie filtert bekannte Angriffsmuster, bevor sie WordPress überhaupt erreichen – und kauft Ihnen im Ernstfall genau die Tage, auf die es ankommt.
- Regelmäßige Kontrolle der Benutzerkonten. Einmal im Monat auf die Administratorliste schauen dauert 30 Sekunden.
- Jemand muss die Sicherheitsmeldungen verfolgen. Das ist der Punkt, an dem die meisten kleinen Betriebe systematisch verlieren – nicht aus Nachlässigkeit, sondern weil es schlicht niemandes Aufgabe ist. Im WordPress-Wartungsvertrag übernehme ich genau das: BSI-Warnungen im Blick behalten und kritische Updates innerhalb weniger Stunden einspielen.