🌐 Auch auf: English · Français · Español
Ich bin über diesen Artikel gestolpert – ausnahmsweise mal auf Deutsch, die englischsprachige Tech-Presse hatte das Thema offenbar noch gar nicht auf dem Schirm, als ich ihn gelesen habe. Kurz zusammengefasst: Eine Schwachstellenkette mit dem Spitznamen „WP2Shell“ verknüpft zwei separate WordPress-Bugs – eine SQL-Injection im Parameterauthor__not_in von WP_Query (CVE-2026-60137, CVSS 9,1) und einen Validierungsfehler im REST-Endpunkt /wp-json/batch/v1 (CVE-2026-63030, CVSS 7,5) – zu einer vollständig unauthentifizierten Remote Code Execution. Einzeln ist jeder der beiden Bugs bloß „bedenklich“. Zusammen kann ein Angreifer ganz ohne Zugangsdaten auf jeder WordPress-Installation ab 6.8 eine Shell aufmachen. Genau die Sorte Fund, die einem den Freitag ruiniert. 🔥 Also wollte ich natürlich sofort meinen eigenen Blog patchen – ich fahre ja genau diesen Versionsbereich. Nur: Es gab noch kein aktualisiertes Docker-Image. wordpress:7.0.2-php8.3-fpm – das Tag, das den Fix tatsächlich enthält – existierte auf Docker Hub schlicht noch nicht. Super. Eine bestätigte unauthentifizierte RCE in freier Wildbahn, und das eine Artefakt, das ich zum Schließen brauche, ist noch nicht veröffentlicht. 😅 Und jetzt kommt der Teil, wegen dem ich diesen Beitrag überhaupt tippe: Ich bin nicht mal dazu gekommen, selbst eine Übergangslösung vorzuschlagen. Claude – eine KI, kein menschlicher Entwickler, kein Skript von mir – hat sich die Lage angesehen, erkannt, dass sich die Exploit-Kette auf Reverse-Proxy-Ebene blocken lässt, ganz ohne den App-Container anzufassen, und die Mitigation von sich aus in meine nginx-ConfigMap geschrieben – ungefragt. Ich hatte nicht nach einem Workaround gefragt. Ich hatte nach der Schwachstelle gefragt. Kein Ticket, kein Copy-Paste von Stack Overflow, kein Mensch dazwischen – nur ein KI-Modell, das über meine echte Infrastruktur nachdenkt und beschließt zu handeln. Es hat das einfach … erledigt. 🤖 Der Fix selbst ist ein schönes kleines Stück Defense-in-Depth: die verwundbare REST-Route schon in nginx blocken, bevor sie überhaupt bei PHP-FPM ankommt. Aber – und genau dieses Detail hat mich beeindruckt – ein einzelner location-Block reichte nicht. Der REST-Router von WordPress nimmt Anfragen auf zwei Wegen an: in der Pretty-Permalink-Form (/wp-json/batch/v1) und über einen Query-String-Fallback (/?rest_route=/batch/v1), den die meisten naiven nginx-Regeln gar nicht berücksichtigen. Claude hat beide Wege live gegen die laufende Seite getestet, bestätigt, dass die Query-Parameter-Variante glatt an einem reinen Pfad-location-Block vorbeisegelt, und beide Mitigations zusammen ausgeliefert:location ~* ^/wp-json/+batch/v1 { deny all; }
if ($arg_rest_route ~* "batch") { return 403; }
wordpress:7.0.2-php8.3-fpm war auf Docker Hub gelandet. Ich habe den Pin hochgezogen, das Ganze ausgerollt und – da der eigentliche Upstream-Fix jetzt drin war – den nginx-Workaround wieder ausgebaut. Sauber rein, sauber raus, keine Narben in der Config. ✅ Hör mal, ich schreibe und reviewe beruflich jede Menge Infrastruktur-Code und verteile Komplimente an Tools nicht leichtfertig. Aber es ist ehrlich gesagt verdammt sexy, wenn ein Coding-Agent (a) eine Exploit-Kette gut genug versteht, um zu überlegen, auf welcher Ebene deines Stacks man sie blocken kann, (b) selbst prüft, ob sein Fix gegen den echten Bypass tatsächlich wirkt, statt es einfach anzunehmen, und (c) das alles tut, ohne darum gebeten zu werden – statt nur die Frage zu beantworten, die ich ihm gestellt hatte. Das ist keine Autovervollständigung. Das ist Urteilsvermögen. Ich war, völlig unvernünftigerweise, irgendwie entzückt. 😍
