Mitte Juli traf eine kritische Schwachstelle den Kern von WordPress, das Content-Management-System hinter geschätzt über 500 Millionen Websites. Die Lücke kursiert unter dem Namen „wp2shell“ und erlaubt die vollständige Übernahme einer Seite, ganz ohne Anmeldung. WordPress spielte kurzfristig ein erzwungenes Notfall-Update aus. Trotzdem wurden bald darauf Angriffe beobachtet. Genau der Abstand zwischen „Patch verfügbar“ und „Patch überall eingespielt“ ist das eigentliche Problem.
Was bei wp2shell passiert
Anders als bei den meisten WordPress-Vorfällen steckt der Fehler nicht in einem Plugin oder Theme, sondern im Kern selbst. Verwundbar sind die Versionen 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1; behoben ist die Lücke in 6.9.5 und 7.0.2. Damit ist auch eine blanke Standardinstallation ohne jede Zusatzsoftware angreifbar.
Technisch handelt es sich um eine Remote-Code-Execution, die sich über die REST-Programmierschnittstelle ohne vorherige Authentifizierung auslösen lässt, konkret über den Batch-Endpunkt unter /wp-json/batch/v1. Am Ende steht die Kontrolle über das CMS, meist in Form einer persistenten Webshell, also eines dauerhaften Fernzugangs. Entdeckt und gemeldet wurde die Schwachstelle vom Sicherheitsforschungsunternehmen Searchlight Cyber, das unter wp2shell.com eine technische Analyse samt Prüf-Tool veröffentlicht hat, mit dem sich eine Installation direkt auf Betroffenheit testen lässt. Das BSI führt die verkettete Lücke unter den Kennungen CVE-2026-60137 und CVE-2026-63030, stuft sie mit einem CVSS-Score von 9,8 als kritisch ein und hat eine Warnung samt Kompromittierungsindikatoren veröffentlicht.
Warum der Patch das Problem nicht löst
Die Reihenfolge war hier sogar günstig: Der Fix kam vor der breiten Offenlegung, und WordPress erzwang das Update. Trotzdem setzten Angriffe ein, obwohl die Forscher bewusst auf die Veröffentlichung von Exploit-Code verzichteten. Das ist kein Widerspruch, sondern die Regel. Ein veröffentlichter Patch ist für Angreifer eine Landkarte: Aus dem Vergleich von alter und neuer Version lässt sich rekonstruieren, wo die Lücke saß, oft innerhalb von Stunden.
Dazu kommt, dass ein erzwungenes Update längst nicht jede Installation sofort erreicht. Automatische Aktualisierungen sind nicht überall aktiv, gemanagte oder eingefrorene Umgebungen aktualisieren erst nach Freigabe, veraltete Systeme oft gar nicht. Jede Seite, die nicht in diesem kurzen Fenster aktualisiert wurde, stand offen, während automatisierte Angreifer das Netz gezielt nach dieser Version absuchten. Die entscheidende Frage ist deshalb nicht, wie man schneller patcht, sondern wie man die Zeit bis zum wirksamen Patch übersteht.
Virtual Patching: Schutz, bevor der Patch greift
Genau hier setzt Application Security an. Eine Web Application Firewall (WAF) prüft eingehende Anfragen am Edge, bevor sie WordPress überhaupt erreichen. Kennt sie das Muster des Angriffs, blockiert sie ihn, ohne dass an der Software etwas geändert werden muss. Bei wp2shell ist dieses Muster sogar klar benennbar: Anfragen auf den verwundbaren Batch-Endpunkt lassen sich am Edge abweisen, solange dafür kein legitimer Bedarf besteht. Dieses Prinzip heißt Virtual Patching: Die Abwehr wandert vor die Anwendung, der eigentliche Patch folgt, sobald er getestet und ausgerollt ist.
Das ist keine Theorie. Anbieter wie Cloudflare rollten binnen Stunden Regeln aus, die die Exploit-Muster am Edge abfingen, noch bevor die betroffenen Seiten aktualisiert waren. Wer seinen Datenverkehr über eine solche Plattform leitet, hatte das kritische Fenster damit weitgehend geschlossen, unabhängig vom eigenen Update-Tempo.
Warum das mehr ist als eine Notlösung
Virtual Patching wirkt wie ein Feuerlöscher, ersetzt aber nicht die Reparatur. Der Patch muss trotzdem kommen. Was sich verschiebt, ist der Druck: Aus einem Notfall mitten in der Nacht wird ein geplanter Wartungsschritt.
Als Dauerschicht leistet eine gepflegte Plattform mehr als die eine Regel im Ernstfall. Managed Rulesets werden bei neuen Schwachstellen automatisch nachgezogen, sodass frische Angriffsmuster ohne eigenes Zutun geblockt werden. Bot-Management trifft die automatisierten Scanner, die solche Lücken massenhaft absuchen, bevor sie ein einzelnes Ziel überhaupt ansteuern. Rate Limiting und API-Schutz begrenzen, was ein Angreifer pro Zeiteinheit versuchen kann. Die Anwendung steht damit nicht schutzlos zwischen Offenlegung und Patch, und das gilt für die nächste Lücke genauso wie für wp2shell.
Was das für Betreiber heißt
Die Lehre aus wp2shell ist nicht „schneller patchen“, sondern „nicht allein auf das Patchen setzen“. Selbst ein vorbildlich schnelles, erzwungenes Update schließt das Zeitfenster nicht für alle. Ein Schutzschild vor der Anwendung verschafft genau den Puffer, den ein realistischer Betrieb braucht. Wer viele Seiten oder geschäftskritische Anwendungen betreibt und diese Schicht nicht selbst aufbauen und rund um die Uhr pflegen will, findet Managed Application Security, die WAF, Bot- und API-Schutz samt automatischer Regel-Updates als betreuten Dienst bereitstellt.
Ein sinnvoller erster Schritt lässt sich ohne großes Projekt gehen: prüfen, welche der eigenen Anwendungen heute überhaupt eine Abwehrschicht vor sich haben, die im Ernstfall in Stunden statt in Tagen reagiert. wp2shell war nicht die erste Lücke dieser Art und wird nicht die letzte sein.
Passende Managed Services
- Application Security – WAF, DDoS-Schutz, Bot- und API-Management samt automatisiertem Zertifikatsmanagement als betreuter Dienst.