wp2shell: Als der Support-Posteingang wegen einer WordPress Sicherheitslücke explodierte

Eine der kritischsten WordPress-Sicherheitslücken der letzten Jahre wurde im Juli bekannt: wp2shell Besonders gemein: Angreifer konnten durch die Kombination zweier Lücken Code auf Servern ausführen, ohne sich authentifizieren zu müssen.   

Sehr viele Website-Betreibende waren betroffen. Allein in Deutschland werden schätzungsweise rund 2 Millionen aktive Websites mit WordPress betrieben. Bei mittwald waren ca. 15 % aller WordPress-Installationen von der Sicherheitslücke betroffen. 

Dabei ging es um die Versionen 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1. Die Sicherheitsprobleme wurden behoben mit den Versionen 6.9.5 und 7.0.2. Die offiziellen CVE-IDs (Common Vulnerabilities and Exposures) für die wp2shell Sicherheitslücken lauten: CVE-2026-63030 und CVE-2026-60137. 
 
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Sicherheitslücke mit der zweithöchsten von vier Stufen ein. Hier geht’s zum offiziellen Bericht.

Kunden mit betroffenen Projekten haben wir per Mail über die Sicherheitslücke informiert. In den Tagen danach, erlebten wir einen deutlichen Anstieg an Support-Anfragen im Zusammenhang mit gehackten WordPress-Installationen. Bei unseren Kunden hat sich das vor allem durch folgende Aktivitäten gezeigt:  

• Anlegen neuer Benutzer  
• Hochladen von Dateien über die Webshell  
• Installation von Fake-Plugins 

Im Accesslog gab es zudem einen ganz bestimmten Eintrag, der immer wieder auffiel. 
Die Zeichenkette sah wie folgt aus: POST /?rest_route=/batch/v1 

Um die betroffenen Websites wieder in einen sicheren Zustand zu bringen, haben wir Kunden folgende Wege angeboten: Das Einspielen eines Backups oder eine gezielte Schadcode-Bereinigung durch unser Team. 

Die Anzahl der Support-Anfragen mit den Stichworten Backup, Schadcode und WordPress ist im Zeitraum vom 20.07. bis 07.08.2026 im Vergleich zu einem dreiwöchigen Vergleichszeitraum im Mai 2026 um rund 276 % gestiegen. 

Bei betroffenen Projekten haben wir – sofern möglich – ein Backup gesichert und über den regulären Aufbewahrungszeitraum hinaus vorgehalten. Damit können wir bei einem Teil der betroffenen Projekte länger ein Backup zur Verfügung stellen, das aus der Zeit vor Bekanntwerden bzw. Ausnutzen der Sicherheitslücke stammt. 

Auch an unserer allgemeinen Backup-Routine haben wir etwas gefeilt: Wir haben beispielsweise das Beenden der PHP-Prozesse fest integriert, um laufende Schadcode-Prozesse zu unterbinden. 

Die wp2shell wird nicht die letzte große Sicherheitslücke bleiben. Der Grund, warum Sicherheitslücken heute so schnell und in großem Umfang ausgenutzt werden können, ist KI. 

Bereits kurze Zeit nach Bekanntmachung der Lücke waren erste Skripte öffentlich verfügbar, die zeigten, wie sie sich ausnutzen lässt. KI kann solche Informationen und vorhandenen Code für Angreifer leichter zugänglich und nutzbar machen und damit die technische Einstiegshürde deutlich senken. Umso wichtiger ist es, bei Sicherheitslücken schnell zu reagieren und gefährdete Installationen sicher zu machen. 

„Sicher machen“ alleine reicht jedoch nicht immer aus. In diesem Fall zeigte sich, dass Kunden auch nach zeitnahen Versions-Updates bereits mit Schadcode infiziert waren. Die Lücke war zwar geschlossen, aber der Zugang der Angreifer war bereits da.  

Auch fällt nicht jeder Hack sofort auf und wird erst nach mehreren Tagen oder Wochen entdeckt. Besonders ärgerlich, wenn die Sicherungen dann nicht mehr zur Verfügung stehen. Das unterstreicht, wie wichtig regelmäßige Sicherungen sind, um handlungsfähig zu bleiben.  

Der richtige Umgang im Ernstfall ist entscheidend: Welche Sofortmaßnahmen sind jetzt wichtig? Was kann ich tun, wo muss ich mir Hilfe holen? Diese Frage beantworten wir dir bald in einem zweiten Artikel.