Die „wp2shell“-Exploit-Kette stellt ein kritisches Sicherheitsereignis dar, das auf die grundlegende Architektur des WordPress-Ökosystems abzielt. Es handelt sich um eine vor der Authentifizierung auftretende Sicherheitslücke, die die Ausführung von Remote-Code (RCE) ermöglicht und vollständig im WordPress-Kern liegt. Für die Ausführung sind weder Plugins noch Themes von Drittanbietern noch ein authentifizierter Zugriff erforderlich. Eine einzige speziell gestaltete HTTP-Anfrage an eine standardmäßige „Stock“-Installation kann dazu führen, dass ein nicht authentifizierter Angreifer die vollständige Kontrolle über das System erlangt.

Die Schwere dieser Bedrohung spiegelt sich in ihrem CVSS-Wert von 9,8 wider. Die CISA hat beide CVEs in ihren Katalog „Known Exploited Vulnerabilities“ (KEV) aufgenommen, nachdem kurz nach der Offenlegung Ausnutzungsaktivitäten beobachtet wurden. Daten deuten darauf hin, dass etwa 60 % der Organisationen, die WordPress nutzen, zum Zeitpunkt der Offenlegung anfänglich anfällig waren, wobei ein erheblicher Teil dieser Server direkt mit dem Internet verbunden war.

Eine erfolgreiche Ausnutzung kann zur vollständigen Kompromittierung der Datenbank, zu dauerhaftem Zugriff auf den Webserver über verschleierte Webshells sowie zur Erstellung nicht autorisierter Administratorkonten führen.

Übersicht über die Sicherheitslücke

Die „wp2shell“-Exploit-Kette kombiniert mehrere Schwachstellen im WordPress-Kern, um eine nicht authentifizierte Rechteausweitung zu erreichen. Der Angriff nutzt zunächst eine Schwachstelle bei der Verarbeitung von Batch-Anfragen der REST-API aus, um die Validierung von Anfragen und Autorisierungsprüfungen zu umgehen. Dieser Zugriff wird anschließend genutzt, um eine SQL-Injection-Schwachstelle in der WP_Query-Verarbeitung des Parameters „author_exclude“ auszunutzen.

Mithilfe der SQL-Injection-Technik kann ein Angreifer zwischengespeicherte WordPress-Objekte manipulieren und den oEmbed-Caching-Mechanismus missbrauchen, um schädliche Daten in die Datenbank zurückzuschreiben. Der Exploit nutzt anschließend die Changeset-Funktionalität des Customizers, um vorübergehend die Berechtigungen eines Administratorkontos zu übernehmen und schließlich einen dauerhaften Administratorbenutzer anzulegen.

Zusammenfassend lässt sich sagen, dass der Angriff in vier Phasen abläuft:

1. Umgehung der REST-API-Validierung durch Desynchronisation von Batch-Anfragen.
2. SQL-Injection durch unsachgemäße Parameterbereinigung.
3. Objekt-Cache-Poisoning und Datenbankmanipulation unter Ausnutzung des oEmbed-Write-Back-Verhaltens.
4. Rechteausweitung und Persistenz durch die Erstellung eines Administratorkontos.

Werden diese Schwachstellen miteinander kombiniert, kann ein nicht authentifizierter Angreifer die vollständige administrative Kontrolle über eine anfällige WordPress-Installation erlangen.

Die folgenden Sicherheitslücken im WordPress-Kern werden in diesem Exploit ausgenutzt:

• CVE-2026-63030 (REST-API-Batch-Route-Verwechslung): Ein Logikfehler in WP_REST_Server::serve_batch_request_v1(), bei dem die fehlerhafte Verarbeitung von WP_Error-Objekten zu einer Desynchronisation zwischen internen Arrays zur Anforderungsverarbeitung führt, wodurch ungültige Anforderungen die Berechtigungen harmloser Handler übernehmen können.
• CVE-2026-60137 (WP_Query-SQL-Injection): Eine Schwachstelle durch Typverwechslung in der WP_Query-Engine. Wenn bestimmte Parameter anstelle eines erwarteten Arrays eine rohe Zeichenkette erhalten, wird die Integer-Sanierung umgangen, was zu einer Interpolation roher Zeichenketten in SQL-WHERE-Klauseln führt .

Betroffene vs. behobene Versionen

Strategische Bewertung: WordPress-Risiko

In der Vergangenheit konzentrierte sich die WordPress-Sicherheit auf den „Plugin-Perimeter“. Dieser Angriff zeigt, dass erhebliche Sicherheitsrisiken auch innerhalb des WordPress-Kerns entstehen können und nicht ausschließlich durch Erweiterungen von Drittanbietern. Unternehmen sollten sicherstellen, dass ihre WordPress-Instanzen in formelle Programme zum Schwachstellen- und Patch-Management eingebunden sind.

Aus defensiver Sicht sollte WordPress als hochrangiges Ziel betrachtet werden. Seine weit verbreitete Nutzung in mit dem Internet verbundenen Umgebungen macht es zu einer attraktiven Plattform für Angreifer, was die Wahrscheinlichkeit von Schwachstellenforschung, automatisierten Scans und Ausnutzungsversuchen erhöht.

Strategische Governance-Säulen

• Erfassung der Angriffsfläche: Führen Sie eine kontinuierliche Bestandsaufnahme aller WordPress-Ressourcen durch. Die meisten Kompromittierungen finden auf vergessenen, nicht gepatchten Staging-Instanzen statt.
• Kontinuierliche Überprüfung: Verlassen Sie sich nicht auf den Status „Auto-Update“. Implementieren Sie eine automatisierte Versionsprüfung, um sicherzustellen, dass Patches tatsächlich aktiv sind.
• Vertrauen ist gut, Kontrolle ist besser: WordPress.org ermöglicht zwar erzwungene Updates, doch Administratoren müssen den Abschluss des Updates bei jeder Host-Konfiguration überprüfen.
• Rotation von Anmeldedaten und Salts: Bei Verdacht auf eine Kern-Sicherheitslücke ist die Rotation der Datenbank-Salts in der Datei „wp-config.php“ eine zwingende strategische Abwehrmaßnahme, um bestehende Sitzungen ungültig zu machen.

Threat Hunting & Indikatoren für Kompromittierung (IoCs)

Netzwerksignale

• HTTP 207 Multi-Status: Dies ist ein sehr aussagekräftiges Signal für erfolgreiche Ausnutzungsversuche über die Batch-API.
• WAF-Umgehung: Angreifer können %2F-Escape-Zeichen im Parameter „?rest_route=“ verwenden, um einfache Zeichenfolgenabgleiche zu umgehen. WAFs müssen so konfiguriert werden, dass sie vor dem Abgleich eine URL-Dekodierung durchführen.
• User-Agents: Achten Sie auf „wp2shell“, „rezwp2shell“ oder „cve-2026-63030/1.0“.

Hostbasierte Artefakte

• Dateimarker: Suchen Sie im Verzeichnis „wp-content/“ nach „temp-write-test-“, das von Exploit-Kits zur Überprüfung von Schreibberechtigungen verwendet wird.
• Schädliche Plugins: Suchen Sie nach Verzeichnissen mit einem Hex-Suffix, wie z. B. „wp-content/plugins/wp2shell_/“.
• Unterscheidung bei CMSmap: Forensik-Teams müssen zwischen dem legitimen 11-KB-Tool „CMSmap“ und der 150-KB-verschleierten Plattform unterscheiden, die in aktuellen Kampagnen beobachtet wurde.

Bekannte IOCs

Maßnahmen zur Risikominderung und Sanierung

Organisationen müssen den WordPress-Kernunverzüglich auf die Versionen 7.0.2, 6.9.5 oder 6.8.6 aktualisieren. Obwohl WordPress.org automatische Updates durchgesetzt hat, müssen Administratoren diese Installationen nach dem Prinzip „Vertrauen ist gut, Kontrolle ist besser“ überprüfen, da der erfolgreiche Abschluss des automatischen Updates nicht bei allen Host-Konfigurationen garantiert ist. Vorrang müssen dabei Instanzen der Zweige 6.9.x und 7.0.x haben, die für die gesamte RCE-Kette anfällig sind.

Vorübergehende Abhilfemaßnahmen

Ist eine sofortige Installation von Patches nicht möglich, sollten Administratoren WAF-Regeln implementieren, um den nicht authentifizierten Zugriff auf die betroffenen REST-API-Batch-Endpunkte zu blockieren. Vor dem Abgleich mit den Regeln sollte eine URL-Dekodierung durchgeführt werden, um kodierte Anfragen zu erkennen.

Blockierte Endpunkte:

• /wp-json/batch/v1
• ?rest_route=/batch/v1 (einschließlich URL-kodierter Varianten wie %2Fbatch%2Fv1)

Maßnahmen nach einer Kompromittierung

Wenn Grund zur Annahme besteht, dass ein Angriff stattgefunden hat, werden folgende Maßnahmen empfohlen:

• Integrität der Core-Dateien überprüfen: Führen Sie den Befehl „wp core verify-checksums“ aus , um veränderte oder nicht autorisierte WordPress-Core-Dateien zu identifizieren.
• Anmeldedaten aktualisieren: Setzen Sie die Datenbank-Anmeldedaten zurück und generieren Sie die Authentifizierungs-Salts und Sicherheitsschlüssel in der Datei „wp-config.php“ neu.
• Benutzerkonten überprüfen: Überprüfen Sie die Tabelle „wp_users“ auf nicht autorisierte Konten, insbesondere auf Konten, die die Namenskonvention „w2s_“ verwenden.
• Suche nach IOCs: Durchsuchen Sie Webserver-Protokolle, Dateisysteme und Sicherheitsüberwachungstools nach den in dieser Sicherheitsempfehlung aufgeführten Indikatoren für eine Kompromittierung (IOCs).

Wenn Sie Bedenken hinsichtlich einer der in diesem Bulletin beschriebenen Bedrohungen haben oder Hilfe bei der Festlegung geeigneter Maßnahmen benötigen, um sich vor den für Ihr Unternehmen relevantesten Bedrohungen zu schützen, wenden Sie sich bitte an Ihren Kundenbetreuer oder kontaktieren Sie uns, um zu erfahren, wie Sie Ihr Unternehmen schützen können.