wp2shell, und warum das WordPress-Update allein nicht reicht

Eine Lücke, die keine Mithilfe braucht

Seit Juli 2026 wird eine Schwachstellenkette im WordPress-Kern massenhaft ausgenutzt, die unter dem Namen wp2shell läuft. Sie erlaubt die vollständige Übernahme einer Website ohne Benutzername, ohne Passwort und ohne dass ein einziges Plugin installiert sein muss. Angreifbar ist die Standardinstallation.

Das Sicherheitsupdate steht seit dem 17. Juli 2026 bereit. Genau an dieser Stelle entsteht das Missverständnis, das uns in Gesprächen mit betroffenen Betrieben fast täglich begegnet.

Ein Update schließt die Tür. Es wirft niemanden hinaus, der vorher hereingekommen ist.

Wer zwischen dem Beginn der Massenausnutzung und dem Einspielen des Updates angegriffen wurde, betreibt danach weiterhin eine übernommene Website. Der Zugang des Angreifers läuft dann über eine hinterlegte Datei und nicht mehr über die Schwachstelle. Das Update ändert daran nichts.

Was technisch passiert

wp2shell ist kein einzelner Fehler, sondern die Verkettung von zwei Schwachstellen.

Die Ursache der ersten Schwachstelle liegt in einem Logikfehler des Batch-Verarbeiters der REST-API. Validierung und Ausführung laufen dort in zwei getrennten Schleifen. Scheitert die Pfad-Zerlegung einer Teilanfrage, landet der Fehler im Validierungs-Array, aber nicht im Trefferbereich. Beide Listen laufen auseinander, und nachfolgende Anfragen werden unter dem falschen Handler ausgeführt.

Über diese Verschiebung wird die SQL-Injection erreichbar, die für sich genommen blockiert wäre. Von dort führt der Weg über gefälschte Beiträge und den oEmbed-Cache zum Anlegen eines Administrator-Kontos und zum Hochladen eines Plugins, das eine Webshell enthält.

Die Angriffskette wird mit einem CVSS-Wert von 9,8 bewertet und erreicht damit die höchste Kritikalitätsstufe. Das BSI hat eine Cybersicherheitswarnung der Stufe Orange herausgegeben, drei von vier. Allein Wordfence hat über elf Millionen Angriffsversuche blockiert.

Betroffene und sichere Versionen

Die installierte Version steht im WordPress-Backend unter Dashboard und dann Aktualisierungen, alternativ unten rechts auf der Startseite des Backends.

Der Zeitraum, um den es geht

1. 17. Juli 2026. Die Sicherheitsadvisory erscheint. Noch am selben Abend beginnen die ersten Scans, dreizehn Minuten später folgt der erste Injection-Versuch.
2. 18. Juli 2026. Die Massenausnutzung setzt ein. Administrator-Konten werden automatisiert angelegt, Webshells hinterlegt.
3. 21. Juli 2026. Beide Schwachstellen wandern in den CISA-Katalog bekannter ausgenutzter Lücken. Das BSI warnt.
4. 22. Juli 2026. Vollständige technische Details und ein öffentlicher Proof-of-Concept werden veröffentlicht. Ab diesem Punkt braucht ein Angreifer kein Fachwissen mehr.

Wer seine Seite in diesem Zeitraum ungepatcht online hatte, muss nicht fragen, ob sie angegriffen wurde. Die offene Frage ist, ob der Angriff Erfolg hatte.

Warum die Auskunft des Dienstleisters oft unvollständig ist

Die Rückmeldung, es sei alles erledigt, ist meist ehrlich gemeint und trotzdem nur die halbe Antwort. Das liegt an der Natur dieses Angriffs.

Ein Update leistet, dass der Einstiegsweg über die REST-API geschlossen ist, neue Angriffe über wp2shell scheitern und die Versionsanzeige im Backend wieder unauffällig aussieht. Was es nicht leistet, wiegt schwerer. Bereits hinterlegte Webshells bleiben aktiv, angelegte Administrator-Konten bestehen fort, manipulierte Datenbank-Einträge bleiben unberührt, und eingerichtete Cronjobs laufen weiter.

Dazu kommt eine Eigenschaft, die diesen Fall besonders tückisch macht. Der öffentliche Proof-of-Concept räumt hinter sich auf. Er entfernt das angelegte Konto und die Webshell wieder und hinterlässt vor allem Spuren in der Datenbank. Die Angriffsanfragen selbst tauchen in den Zugriffsprotokollen kaum auf, weil der Inhalt einer Batch-Anfrage dort nicht mitgeschrieben wird.

Ein sauber ausgeführter Angriff hinterlässt fast nichts im Logfile. Fehlende Logzeilen sind deshalb kein Beleg für Unversehrtheit, sondern oft nur ein Hinweis darauf, dass am falschen Ort gesucht wurde.

Der Selbsttest im Backend

Diese vier Schritte brauchen keinen Serverzugriff und dauern wenige Minuten.

Unbekannte Administratoren. Unter Benutzer und dann Alle Benutzer, gefiltert auf die Rolle Administrator. Auffällig ist jedes Konto, das nicht selbst angelegt wurde. Typisch für diese Kampagne sind Benutzernamen mit den Präfixen wp2_ oder w2s_ sowie Adressen auf den Domains wp2shell.invalid und wp2shell.shellcode.lol.

Unbekannte Plugins. Unter Plugins und dann Installierte Plugins. Angreifer tarnen Webshells als Plugin. Verzeichnisnamen nach dem Muster wp2shell_ sind ein eindeutiger Treffer. Verdächtig ist außerdem jedes Plugin ohne Autor, ohne Beschreibung oder ohne Versionsnummer.

Fremde Dateien im Cache-Ordner. Der bevorzugte Ablageort der beobachteten Webshells ist wp-content/cache. Die Dateinamen sind zufällig erzeugt, der Zugriff ist passwortgeschützt, und bei falschem Passwort liefert die Datei eine gefälschte 404-Seite aus, um unauffällig zu bleiben. Eine PHP-Datei, die dort nicht hingehört, ist ein ernstes Warnzeichen.

Der forensische Scanner. Im offiziellen Plugin-Verzeichnis liegt der Compromise Scanner for wp2shell. Er arbeitet ausschließlich lesend und durchsucht Datenbank und Plugin-Verzeichnis nach genau den Artefakten dieses Exploits. Er findet auch dann noch Spuren, wenn der Angreifer seine Dateien gelöscht hat, weil die Einträge in der Datenbank bestehen bleiben.

Wenn der Selbsttest anschlägt

Ein fremdes Administrator-Konto, ein unbekanntes Plugin oder eine PHP-Datei im Cache-Ordner bedeutet mit hoher Wahrscheinlichkeit, dass die Seite übernommen wurde. Zwei Dinge sind dann wichtig. Nichts löschen, bevor Dateien und Datenbank gesichert sind, denn der Befund ist zugleich die Beweislage. Und die Zugangsdaten von einem anderen Gerät aus ändern, nicht über die betroffene Seite.

Für eine schnelle Einschätzung sind wir direkt erreichbar.

• Telefon +49 1515 5591467 für akute Fälle
• E-Mail an kontakt@plaximo.de, am besten mit Domain und dem gefundenen Befund
• Alternativ über das Kontaktformular

Ob ein Fund harmlos ist oder tatsächlich auf eine Übernahme hindeutet, klären wir vorab ohne Kosten. Das gilt auch dann, wenn die Seite von jemand anderem betreut wird und die Prüfung dort weiterlaufen soll.

Prüfung mit Serverzugriff

Zuerst die Dateien im Web-Root, die seit Beginn der Kampagne verändert wurden.

find /var/www/html -name "*.php" -newermt "2026-07-16"

Für die Datenbank empfiehlt sich ein Abzug, auf dessen Kopie gearbeitet wird, nicht die laufende Instanz.

mysqldump -u BENUTZER -p DATENBANK > /tmp/analyse.sql

Aussagekräftig sind vor allem diese Artefakte.

• Lücken in den IDs der Tabelle wp_users und verwaiste Einträge in wp_usermeta
• Veränderte Werte für active_plugins, siteurl und home in wp_options
• oEmbed-Cache-Zeilen mit Loopback-Verweisen
• Beiträge vom Typ customize_changeset mit auffällig hohen Parent-IDs
• Untergeschobene Einträge mit dem Präfix _transient_

Ergänzend lohnt ein Blick auf die Crontabs unter /etc/crontab und /etc/cron.*, auf die Shell-History des Webserver-Nutzers und auf /etc/passwd wegen neu angelegter lokaler Konten.

Die richtige Reihenfolge

1. Sichern, bevor etwas verändert wird. Dateien und Datenbank im aktuellen Zustand sichern. Diese Sicherung dient der Beweislage, nicht der Wiederherstellung.
2. Auf eine sichere Version aktualisieren. Mindestens 6.8.6, 6.9.5 oder 7.0.2. Das stoppt neue Angriffe über diesen Weg.
3. Alle Passwörter zurücksetzen. Die SQL-Injection kann Passwort-Hashes aus der Nutzertabelle auslesen. Betroffen sind alle WordPress-Konten sowie Datenbank-, FTP- und Hosting-Zugänge.
4. Auf Kompromittierung prüfen. Erst hier zeigt sich, ob der Angriff Erfolg hatte. Ohne diesen Schritt bleibt die Frage offen.
5. Gefundene Zugänge entfernen. Fremde Konten löschen, untergeschobene Plugins entfernen, Webshells beseitigen, manipulierte Datenbank-Einträge zurücksetzen.
6. Meldepflichten prüfen. Sind personenbezogene Daten betroffen, läuft die Frist ab dem Moment der Kenntnis.

Ein älteres Backup zurückzuspielen, löst das Problem nicht. Eine Sicherung aus der Zeit nach dem 17. Juli kann die Webshell bereits enthalten, eine ältere bringt die ungepatchte Version zurück und öffnet die Lücke erneut.

Die rechtliche Seite

Die Angriffskette kann Nutzerdaten und Passwort-Hashes aus der Datenbank auslesen. Sobald personenbezogene Daten betroffen sind, ist der Vorfall nach Artikel 33 DSGVO innerhalb von 72 Stunden an die zuständige Aufsichtsbehörde zu melden. Die Frist beginnt mit der Kenntnis vom Vorfall, nicht mit dem Angriff.

Besteht ein hohes Risiko für die betroffenen Personen, kommt nach Artikel 34 DSGVO deren direkte Benachrichtigung hinzu. Für Unternehmen im Anwendungsbereich der NIS-2-Richtlinie gelten gegenüber dem BSI zusätzliche und teils kürzere Fristen.

Wer die Prüfung unterlässt, verschiebt damit nicht das Problem, sondern nur den Zeitpunkt, an dem die Fristen unangenehm werden. Dieser Abschnitt ordnet die Rechtslage ein und ersetzt keine Rechtsberatung.

Zur Einordnung unserer Kontaktaufnahme

Wir haben im Rahmen unserer Arbeit öffentlich erreichbare Websites auf die Merkmale dieser Schwachstelle geprüft und dabei eine hohe Zahl betroffener Seiten gefunden. Viele davon gehören Betrieben, die uns nicht kennen. Wer daraufhin einen Anruf oder eine Nachricht von uns erhalten hat, soll wissen, wie wir dabei vorgehen.

• Wir werten ausschließlich aus, was eine Website von außen ohne Anmeldung über ihre Versionskennung und ihre öffentlichen Endpunkte preisgibt. Wir versuchen keine Anmeldung und nutzen die Schwachstelle nicht aus.
• Wir fragen am Telefon nie nach Zugangsdaten. Niemand von uns wird nach einem Passwort fragen.
• Jeder unserer Punkte lässt sich selbst überprüfen. Die Anleitung dafür steht weiter oben und funktioniert vollständig ohne uns.
• Der bisherige Dienstleister kann diese Prüfschritte ebenso abarbeiten. Diesen Artikel weiterzugeben und dort nachzufragen, ist ein völlig legitimes Ergebnis.

Der häufigste Verlauf sieht so aus, dass die Rückfrage beim vorhandenen Dienstleister landet und dort das eingespielte Update bestätigt wird. Das ist richtig und wichtig, beantwortet aber nur die erste Hälfte. Sinnvoll sind deshalb zwei Fragen in dieser Reihenfolge. Erstens, auf welcher WordPress-Version läuft die Seite jetzt. Zweitens, wurde nach dem Update auf Kompromittierung geprüft und mit welchem Ergebnis. Bleibt die zweite Frage ohne belastbare Antwort, hat die Prüfung nicht stattgefunden.

Häufige Fragen

Schützen automatische Updates zuverlässig?

Die Lücke selbst ist damit geschlossen. Offen bleibt der Zeitraum zwischen dem Beginn der Massenausnutzung am 18. Juli 2026 und dem Moment, in dem das Update auf dem betreffenden Server tatsächlich lief. Automatische Updates erreichen nicht alle Installationen in derselben Sekunde.

Warum meldet das Sicherheits-Plugin nichts?

Viele Plugins prüfen bekannte Schadcode-Signaturen und die Unversehrtheit der Kern-Dateien. Eine als Plugin getarnte Webshell mit zufälligem Namen und ein manipulierter Datenbank-Eintrag fallen dabei nicht zwangsläufig auf. Sinnvoll ist zusätzlich ein Scanner, der gezielt auf die Artefakte dieser Kampagne prüft.

Die Seite läuft normal und sieht unverändert aus. Genügt das als Entwarnung?

Nein. Eine Webshell verändert die Darstellung für Besucher nicht. Sie ist eine versteckte Datei, die auf einen Aufruf mit dem richtigen Passwort wartet und allen anderen eine gefälschte Fehlerseite ausliefert. Genau darin liegt ihr Zweck.

Quellen

• Rapid7, technische Analyse von CVE-2026-63030 öffnet in neuem Tab
• Eye Security Labs, Leitfaden zur Incident Response öffnet in neuem Tab
• Wiz, beobachtete Ausnutzung in freier Wildbahn öffnet in neuem Tab
• BleepingComputer, Bericht zur Massenausnutzung öffnet in neuem Tab
• Compromise Scanner for wp2shell im Plugin-Verzeichnis öffnet in neuem Tab

---

Ein Befund im Backend lässt sich selten allein einordnen. Wir prüfen eine betroffene Seite auf die Spuren dieser Kampagne und sagen, was davon harmlos ist. Bei akutem Verdacht direkt unter +49 1515 5591467 oder kontakt@plaximo.de.