Eine Schwachstellenkette im WordPress-Kern erlaubt es Angreifern, ohne Anmeldung und ohne verwundbares Plugin eigenen Code auf dem Server auszuführen. WordPress hat am 17. Juli 2026 Notfall-Updates veröffentlicht und automatische Zwangsaktualisierungen aktiviert. Wenige Stunden später kursierten die ersten Exploits, seitdem laufen Angriffe im großen Stil. Das BSI hat die Warnstufe 3 von 4 ausgerufen, die CISA hat beide Schwachstellen in ihren Katalog aktiv ausgenutzter Lücken aufgenommen. Wer WordPress betreibt, sollte jetzt die installierte Version prüfen, und zwar an jeder einzelnen Instanz.

Was passiert ist

Am 17. Juli 2026 hat das WordPress-Projekt drei Notfall-Releases veröffentlicht und weltweit erzwungene automatische Updates ausgelöst. Der Grund ist eine Schwachstellenkette im WordPress-Core, die unter dem Namen „wp2shell“ bekannt geworden ist. Sie erlaubt einem nicht angemeldeten Angreifer, auf einer Standardinstallation eigenen Code auf dem Server auszuführen. Kein Benutzerkonto, kein verwundbares Plugin, keine besondere Konfiguration nötig.

Der Zeitablauf zeigt, wie kurz das Zeitfenster inzwischen ist. Die WordPress-Sicherheitsfirma Defiant beobachtete das erste Abtasten am 17. Juli um 23:29 UTC, 13 Minuten später folgte ein eindeutiger SQL-Injection-Versuch. VulnCheck hatte bis Sonntag, den 19. Juli, mehr als zwei Dutzend eigenständige Proof-of-Concept-Exploits verifiziert. Am 21. Juli nahm die US-Behörde CISA beide CVEs in ihren Katalog bekannter ausgenutzter Schwachstellen auf.

Das BSI hat die Lage in seiner Warnung 2026-271984 mit Bedrohungsstufe 3 von 4 (Orange) bewertet und weist auf die aktive Ausnutzung hin. Für die Einzellücken liegen unterschiedliche Bewertungen vor: CVE-2026-60137 wird laut NVD mit CVSS 9.1 als kritisch geführt, die Werte für CVE-2026-63030 schwanken je nach Quelle zwischen 7.5 und 9.8. Die Kette insgesamt bewertet das BSI mit CVSS 9.8.

Wie die Angriffskette funktioniert

wp2shell ist kein einzelner Fehler, sondern die Kombination aus zwei unabhängigen Schwachstellen.

CVE-2026-63030 steckt im Batch-Endpunkt der REST-API (/wp-json/batch/v1 beziehungsweise ?rest_route=/batch/v1), der mit WordPress 6.9 eingeführt wurde. Der Batch-Handler prüft und führt Teilanfragen in getrennten Schleifen aus und verwaltet dabei parallele Arrays. Scheitert wp_parse_url() an einem Pfad einer Teilanfrage, landet der Fehler nur in einem der beiden Arrays. Die Arrays laufen auseinander, und alle folgenden Anfragen werden dem falschen Handler zugeordnet. Damit lässt sich die Berechtigungsprüfung umgehen.

CVE-2026-60137 ist eine SQL-Injection im Parameter author__not_in von WP_Query. Übergibt man den Wert als einfache Zeichenkette statt als Array, wird er direkt in rohes SQL eingesetzt. Für sich genommen setzt diese Lücke eine Anmeldung voraus.

Erst zusammen wird es gefährlich: Die Routenverwechslung hebelt die Authentifizierung aus, die SQL-Injection wird dadurch anonym erreichbar. Über Objekt-Hydration im weiteren Verlauf legen Angreifer ein Administratorkonto an und gelangen von dort zur Codeausführung. Laut Cloudflare ist der Pfad zur Codeausführung nur erreichbar, wenn kein persistenter Object Cache aktiv ist. Wer Redis oder Memcached einsetzt, ist damit aber nicht abgesichert, denn die SQL-Injection bleibt bestehen.

Entdeckt hat die Kette das Assetnote-Team von Searchlight Cyber, nach eigenen Angaben mit Unterstützung eines KI-Modells beim Auffinden der Schwachstelle.

Wer betroffen ist

• Vollständige Angriffskette bis zur Codeausführung: WordPress 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1
• Nur die SQL-Injection: WordPress 6.8.0 bis 6.8.5
• Nicht betroffen: Versionen älter als WordPress 6.8

Die gepatchten Versionen sind 7.0.2, 6.9.5 und 6.8.6. Auch die Beta von WordPress 7.1 war anfällig.

Zur Einordnung der Reichweite: WordPress treibt je nach Erhebung rund 41 bis 42 Prozent aller Websites an. Wiz Research meldet, dass zum Zeitpunkt der Veröffentlichung 60 Prozent der Organisationen mit WordPress mindestens eine verwundbare Instanz betrieben und 25 Prozent einen verwundbaren Server im Internet exponiert hatten. Binnen 24 Stunden sanken diese Werte auf 50 beziehungsweise 10 Prozent.

Das eigentliche Risiko liegt heute nicht mehr bei den gepflegten Hauptseiten. Es liegt bei vergessenen Instanzen: Staging-Umgebungen, alten Kampagnenseiten, Tochter-Blogs, Testsystemen auf Subdomains. Genau dort greifen erzwungene Auto-Updates am unzuverlässigsten.

Wiz Research hat mehrere Akteure beobachtet, die selbst gehostete WordPress-Instanzen erfolgreich übernommen haben. Nach dem Einbruch folgten:

• Upload bösartiger Plugins über /wp-admin/update.php?action=upload-plugin
• Auslesen von Administrator-Benutzernamen und E-Mail-Adressen über /wp-json/wp/v2/users?context=edit
• Local-File-Inclusion-Versuche über admin-ajax.php?template=../../../wp-config, um Datenbank-Zugangsdaten und Authentifizierungsschlüssel abzugreifen
• Zugriff auf /wp-admin/ mit HTTP-200-Antworten, also erfolgreiche angemeldete Sitzungen

Bei der abgelegten Schadsoftware reicht das Spektrum vom Einzeiler bis zum Baukasten. Wiz fand einerseits eine minimale PHP-Backdoor, die auf einen bekannten POST-Parameter reagiert und ansonsten HTTP 404 zurückgibt, um nicht aufzufallen. Andererseits eine rund 150 KB große Webshell, die sich als Plugin namens „CMSmap“ tarnt und eine grafische Oberfläche, Passwortschutz, Dateimanager, Datenbankzugriff, Portscanner und mehrere Module zur Rechteausweitung mitbringt. Ein drittes bösartiges Plugin registrierte einen eigenen REST-Endpunkt mit dem Berechtigungs-Callback __return_true und führte base64-kodierte Befehle direkt auf dem Server aus.

Laut Johannes B. Ullrich vom SANS Technology Institute laufen viele Angriffe zweistufig: erst eine tastende SQL-Injection zur Bestätigung, dann die Auslieferung der PHP-Webshell. Teilweise legen die Angreifer zusätzlich eigene Administratorkonten an. Wiz hat bisher weder laterale Bewegung noch Datenabfluss beobachtet, beobachtet die Lage aber weiter.

IOC

• HTTP-207- oder HTTP-200-Multi-Status-Antworten auf Anfragen an den Batch-Endpunkt. Laut Wiz ist das ein zuverlässiger Hinweis auf erfolgreiche Ausnutzung.
• User-Agent-Strings, die wp2shell oder rezwp2shell enthalten. Das sind Signaturen fertiger Angriffswerkzeuge.
• Anfragen an /wp-json/batch/v1 oder ?rest_route=/batch/v1 in den Webserver-Logs, rückwirkend ab dem 17. Juli 2026
• Neue Administratorkonten, die niemand angelegt hat
• Neue oder veränderte Plugins, insbesondere solche, die niemand installiert hat
• Unerwartete PHP-Dateien im Dateisystem, unter anderem im Verzeichnis /cache/
• Auffällige Einträge in den Logs von WAF oder Security-Plugin rund um die REST-API

Wichtig: Ein Patch entfernt keinen Angreifer, der bereits eine Webshell abgelegt hat. Wer Anzeichen einer Kompromittierung findet, sollte von einer vollständigen Serverübernahme ausgehen.