wp2shell: Wie ein Tag Vorsprung über Kompromittierung entscheidet

Ich geb’s zu: Als die Meldung über die neue kritische WordPress-Lücke reinkam, hab ich erstmal kurz geschluckt. Nicht wegen der Lücke selbst – die kommen und gehen –, sondern wegen des Datums. Ich hatte am 17.07. gepatcht. Die ersten Exploit-Versuche liefen laut meinen Logs am 18.07. an.

Ein Tag. Das war’s.

Hätte ich das Update aufgeschoben – “mach ich nächste Woche, ist ja nur ein Blog” – wäre ich vermutlich mit dabei gewesen.

Was ist wp2shell eigentlich?

Am 17. Juli 2026 hat WordPress mit Version 7.0.2 einen Notfall-Patch veröffentlicht. Kein Routine-Update, sondern die Reaktion auf zwei Schwachstellen, die einzeln schon unangenehm sind, kombiniert aber richtig übel werden:

• CVE-2026-63030 – eine Route-Confusion-Lücke im REST-API-Batch-Endpunkt (/wp-json/batch/v1)
• CVE-2026-60137 – eine SQL-Injection im WP_Query-Parameter author__not_in

Verkettet ergibt das: unauthentifizierte Remote Code Execution. Kein Login nötig, kein verwundbares Plugin, keine besondere Konfiguration – ein Standard-Install reicht. Betroffen waren WordPress 6.9.0–6.9.4 und 7.0.0–7.0.1 (die SQLi-Komponente reichte sogar bis 6.8 zurück).

Der Name wp2shell kommt vom Forscher, der die Kette gefunden hat – und der Titel ist Programm: Aus einem harmlos aussehenden API-Call wird am Ende eine Shell auf dem Server.

Die Krux: Von “entdeckt” zu “ausgenutzt” in drei Tagen

Das eigentlich Beunruhigende an der Geschichte ist nicht die Lücke selbst, sondern das Tempo. Veröffentlicht wurde die CVE am 17.07. Die ersten dokumentierten Exploit-Versuche in freier Wildbahn: 18.07. Innerhalb weniger Tage stieg die Ausnutzung von vereinzelten Versuchen zu massenhaftem, automatisiertem Scanning – am 21.07. landete wp2shell dann folgerichtig auf der CISA-KEV-Liste (Known Exploited Vulnerabilities), mit einer Nachfrist bis zum 24.07.

Ich hatte an dem Punkt bereits vier Tage Vorsprung. Nicht, weil ich besonders wachsam war, sondern weil Updates bei mir kein “irgendwann”-Task sind, sondern Teil der Routine. Und trotzdem: Ein Tag zwischen Patch und ersten Angriffen ist kein großzügiges Zeitfenster. Das ist ein Wimpernschlag.

Die Lehre daraus ist unbequem, aber einfach: “Ich patch das die Tage” ist 2026 keine akzeptable Antwort mehr auf eine kritische Core-Lücke. Die Zeitspanne zwischen Disclosure und aktiver Ausnutzung schrumpft von Wochen auf Stunden, und WordPress hat aus genau diesem Grund bei diesem Release automatische Zwangsupdates aktiviert, auch für Instanzen, die normalerweise manuell aktualisiert werden.

Was ich daraus für meine Sites mitnehme

Ich betreibe mehrer WordPress-Installationen auf einem VPS bei Strato. Alle waren zum Zeitpunkt der ersten Exploit-Versuche bereits gepatcht, das hab ich extra noch mal nachgeprüft. Kein Kompromittierungsfall, nur eine saubere Kontrolle.

Was ich aus der ganzen Sache mitnehme, sind zwei Dinge:

1. Automatische Updates sind kein Kontrollverlust, sondern Risikomanagement. Ich war lange skeptisch gegenüber Auto-Updates auf Core-Ebene – zu viel Angst vor kaputten Plugins nach einem Major-Update. Nach wp2shell sehe ich das differenzierter: Bei Security-Releases überwiegt das Risiko, nicht automatisch zu patchen, das Risiko eines kaputten Updates um Längen.

2. Log-Monitoring allein reicht nicht mehr als alleinige Verteidigungslinie. Ich hab aktuell nur die klassische, log-basierte CrowdSec-Erkennung auf dem Webserver laufen – kein WAF, keine AppSec-Komponente davor. Für wp2shell hätte das nichts gebracht, weil die verfügbare Schutzregel für diese Lücke ausschließlich als AppSec-/Virtual-Patching-Regel existiert, nicht als klassisches Log-Scenario. Sprich: Ohne Request-Inspection vor WordPress wäre ich rein auf den rechtzeitigen Patch angewiesen gewesen – zum Glück hat der gereicht, aber “Glück” ist kein Sicherheitskonzept.

Der zweite Punkt steht bei mir jetzt oben auf der To-Do-Liste. Es gibt einen nativen Apache-Bouncer für CrowdSec (mod_crowdsec), der sich als normales Apache-Modul einklinkt und Requests zusätzlich an eine lokale AppSec-Engine weiterleiten kann – kein separater Reverse-Proxy nötig. Das ist aber ein eigenes Projekt für sich, dazu mehr in einem der nächsten Posts, sobald ich es tatsächlich am Laufen habe.

Fazit

wp2shell ist technisch gesehen “nur” wieder eine Kombination aus zwei mittelschweren Bugs, die zusammen richtig gefährlich werden – wie so oft. Interessant ist eigentlich nicht die Lücke, sondern das Timing: Ein Tag zwischen Patch-Release und ersten Angriffen ist die neue Realität, nicht die Ausnahme. Wer bei WordPress-Core-Updates auf “hab ich noch Zeit für” statt “sofort” setzt, spielt eine Runde Russisch Roulette mit einer sehr kurzen Trommel.

Bei mir hat der Vorsprung gereicht. Aber ich fang jetzt an, mich nicht mehr nur darauf zu verlassen.

Bleibt neugierig, Alex