Die WordPress-Webshell-Welle 2024–2026: Was die Daten zeigen

WordPress läuft laut W3Techs auf 40,7 Prozent aller Websites und auf 58,9 Prozent der Sites, deren CMS bekannt ist (geprüft am 4. September 2026 – beide Zahlen werden regelmäßig vermischt, es lohnt sich also zu sagen, welche gemeint ist). Dieser Anteil ist der Grund, warum eine Upload-Lücke in einem Formular-Plugin aus Sicht eines Hosting-Betreibers ein Infrastrukturproblem ist und kein Kundenproblem – und warum sie ausgerechnet Betreiber trifft, die gerade ihren Scanner verloren haben, wie wir in CXS ist Geschichte beschrieben haben.

Dieser Artikel fasst zusammen, was zur Backdoor-Welle 2024–2026 tatsächlich belegt ist: die Kampagnen, die Dateiindikatoren, die Größenordnungen mit ihren Jahreszahlen – und die Fälle, die gegen unsere eigene Produktkategorie sprechen.

Das Angebot an Schwachstellen, mit Jahreszahl

Die Jahresreihe von Patchstack ist die sauberste Zählung dessen, was ins Ökosystem gelangt.

Von den 2025er Fällen waren 1.966 (17 Prozent) hochgradig kritisch, ein Anstieg von 113 Prozent gegenüber dem Vorjahr; die Verteilung lag bei 91 Prozent Plugins, 9 Prozent Themes und sechs Fällen im Core (Patchstack 2026 ).

Der Jahresbericht 2024 von Wordfence , veröffentlicht am 8. April 2025, zählt für 2024 8.223 offengelegte Schwachstellen (+68 Prozent), davon 96 Prozent in Plugins, rund 35 Prozent weiterhin ungepatcht. Das für diesen Artikel entscheidende Detail: Arbitrary File Upload war der häufigste hochkritische Schwachstellentyp, und die zweithäufigste erkannte Malware-Familie war „a generalized obfuscated backdoor" auf 78.500 Sites.

Zwei Vorbehalte zu dieser Reihe. Für 2025 und 2026 gibt es keinen Wordfence-Jahresbericht – das Format wurde durch Quartalsberichte ersetzt, und weil die Ausgaben für Q1 und Q2 2025 nie erschienen sind, existiert keine Jahressumme für 2025 und lässt sich auch nicht durch Addition rekonstruieren. Und die Seite der Patchstack-Ausgabe 2024 trägt einen fehlerhaften Kopfbereich, der den Einleitungstext der Ausgabe 2025 wiederholt; wer den Seitenanfang ausliest, ordnet 2024er Zahlen dem Berichtsjahr 2023 zu.

Geschwindigkeit ist der Teil, den Patchen nicht löst

Patchstack hat einen gewichteten Median bis zur ersten Ausnutzung von fünf Stunden gemessen, 45 Prozent der Ausnutzung erfolgte innerhalb von 24 Stunden nach der Veröffentlichung (Patchstack 2026 ). Dem gegenüber steht, wann die Ausnutzung in vier gut dokumentierten Fällen tatsächlich begann:

Und die Population, die nie patcht, ist nicht klein. Imunify360 hat gemessen, dass 84 Prozent von 2,6 Millionen Elementor-Pro-Sites zwei Wochen nach der Veröffentlichung noch ungepatcht waren – rund 2,1 Millionen weiterhin verwundbare Sites zum Stand 31. August 2026 (Imunify360-Blog ).

Patchen bleibt die richtige Lösung, und nichts im Folgenden sagt etwas anderes. Aber „schneller patchen" ist keine Anweisung, die ein Hoster für 2,1 Millionen fremde Sites ausführen kann, und einer Ausnutzung, die vor dem Advisory beginnt, ist durch Patchen grundsätzlich nicht beizukommen. Genau diese Lücke füllt eine Erkennungsschicht auf Hostebene.

Was die Telemetrie sagt – und was nicht

Firewall-Anbieter veröffentlichen große Zahlen blockierter Versuche. Vier davon, mit ihrem Zeitraum:

• wp2shell (WordPress Core, CVE-2026-63030 und CVE-2026-60137) – über 11 Millionen blockierte Versuche seit dem 17. Juli 2026 (Wordfence ).
• Super Forms – über 250.000 seit dem 14. Juli 2026 (Wordfence ).
• Elementor Pro – über 190.000 seit dem 19. August 2026 (Wordfence ).
• Ninja Forms File Upload – über 118.600 seit dem 6. April 2026 (Wordfence ).

Imunify360 hat unabhängig davon 3,6 Millionen Webshell-Zugriffe an einem einzigen Tag protokolliert (20. August 2026), dazu 757.000 Exploit-Fingerprint-Anfragen über zwölf Tage für Elementor Pro (Imunify360 ).

Das sind Versuche, keine Kompromittierungen, und dieser Unterschied ist keine Spitzfindigkeit. Wordfence schreibt es im wp2shell-Beitrag selbst: Trotz der elf Millionen blockierten Versuche habe man keinen entsprechenden Anstieg tatsächlicher Kompromittierungen beobachtet – „we have not observed such a surge". F5 Labs formuliert es zur selben Kampagne noch deutlicher: Die eigenen Sensoren hätten „did not observe a web shell being deployed in the captured activity". Wordfence weist zudem darauf hin, dass die Zahlen nur Kunden mit einer bestimmten Premium-Firewall-Regel abbilden, also einen kleinen Teil des Kundenstamms.

Behandeln Sie diese Zahlen als das, was sie sind: Angriffsversuche gegen den Kundenstamm eines Anbieters, gemessen mit dessen Instrumentierung. Wer elf Millionen blockierte Versuche als elf Millionen gehackte Sites darstellt, sagt Ihnen etwas Falsches.

Das Zählproblem wirkt in beide Richtungen. SOCRadars Analyse des Exploit-Kits WP-SHELLSTORM aus dem Jahr 2026 nennt erfrischend unschmeichelhafte Konversionszahlen: Breeze Cache, 45.000 Ziele und daraus rund 17.000 Shells; Joomla JCE, 560.000 Ziele und daraus 77 (SOCRadar ). Massenhaftes Scannen ist billig, das Platzieren einer Shell gelingt keineswegs gleichmäßig.

Die Backdoor-Quote und ihr Jahrgang

Die meistzitierte Statistik dieses Felds stammt aus dem Hacked Website Report 2023 von Sucuri :

In 2023, 49.21% of compromised websites were discovered to contain at least one backdoor at the time of infection. Our team successfully removed 21,062 backdoors from these infected sites.

Derselbe Bericht hält fest, dass 95,5 Prozent der von Sucuri bereinigten Infektionen WordPress betrafen, dass 39,1 Prozent der infizierten Sites zum Infektionszeitpunkt veraltet waren und dass im Schnitt 610 Dateien je Auftrag bereinigt wurden.

Nennen Sie das Jahr. Für 2024, 2025 und 2026 gibt es keinen Hacked Website Report; die Ausgabe 2023 ist die letzte mit Bereinigungsdaten. Der SiteCheck-Bericht 2024 enthält ausschließlich Fernscan-Daten – 70,8 Millionen Scans, 1.176.701 infizierte Sites, eine Infektionsrate von 1,66 Prozent – und überhaupt keine Backdoor-Quote. „Die Hälfte aller gehackten Sites enthält eine Backdoor" ohne Jahresangabe ist der am leichtesten vermeidbare Fehler in diesem Thema.

Was tatsächlich auf der Platte landet

Kampagnennamen altern schlecht. Dateiindikatoren nicht – und sie sind das, was ein Scanner sieht.

Polyglots und Handler-Missbrauch. Der Ninja-Forms-Beitrag von Wordfence enthält wörtlich mitgeschnittene Angriffsanfragen und ist damit der klarste reale Beleg dafür, dass Handler-Missbrauch keine graue Theorie ist:

• Eine als Bild getarnte .htaccess – der Zieldateiname trug %2ehtaccess, während der Upload sich als image.jpg ausgab – mit dem Inhalt AddType application/x-httpd-php .txt. Diese eine Zeile lässt jede .txt-Datei im Verzeichnis als PHP ausführen.
• Ein %PDF-1.4-Polyglot, abgelegt als nf_lab_10e31d63.php.
• Ein GIF89a-Polyglot, deklariert als image/jpeg, per Path Traversal zwei Verzeichnisse höher als wp_cache.php geschrieben.

(Wordfence, Ninja Forms .) Die Erklärung von Wordfence, warum das funktioniert, lohnt die Wiederholung: Manche Prüfungen sehen sich die Magic Bytes an, manche die Dateiendung, manche vertrauen dem MIME-Typ des Clients – und ein gut gebauter Polyglot erfüllt mehrere Prüfungen gleichzeitig.

Vorhersagbare Ablagepfade. Die Ausnutzung von Elementor Pro landet unter /wp-content/uploads/elementor/forms/ mit einem uniqid()-Dateinamen und einer vom Angreifer gewählten .php-Endung (Wordfence ). Die IoC-Empfehlung von Wordfence zu dieser Kampagne läuft auf eine einzige Regel hinaus: Jede .php-Datei an dieser Stelle ist ein starker Hinweis auf eine Kompromittierung. Bei Super Forms wurde ein browserbasierter Uploader namens Mushr00w_upl.php abgelegt (Wordfence ), bei der Hunk-Companion-Kette die Datei /htdocs/aea74fff3c02.php.

Balada Injector ist das Gegenargument zu pfadbasierten Positivlisten: Sucuri dokumentiert 176 verschiedene Backdoor-Pfade, darunter eine Plugin-Datei namens wp-felody.php (Sucuri ).

mu-plugins verdienen besondere Aufmerksamkeit, weil sie automatisch geladen werden und in der Plugin-Oberfläche nie auftauchen. Sucuri hat das Muster 2025 zweimal dokumentiert (März , Juli ); im Juli-Fall liegt die Nutzlast in wp_options unter dem Schlüssel _hdra_core, und es wird ein Administratorkonto officialwp angelegt.

Zu benannten Shell-Familien, mit Sorgfalt. In der primären Vorfallsberichterstattung der Anbieter tauchen WSO/FilesMan, b374k, BestShell, Godzilla und VShell/SNOWLIGHT auf. Zwei Namen, die in Blogbeiträgen ständig wiederholt werden – p0wny und IndoXploit –, fanden sich in keiner von uns gelesenen Quelle von Wordfence, Patchstack oder Sucuri; wir ordnen sie deshalb keiner WordPress-Kampagne zu. p0wny-shell taugt weiterhin als allgemeine Illustration der Gattung, laut eigener README „a very basic, single-file, PHP shell … used to quickly execute commands on a server when pentesting a PHP application", mit der Warnung des Projekts selbst: „THIS SCRIPT IS A SECURITY HOLE." Eine Datei im Webroot, und der Server gehört jemand anderem.

Das Gegenbeispiel, das wir veröffentlichen müssen

Sign1 lebte ausschließlich in der Datenbank. Die Kampagne infizierte rund 39.000 Sites und hinterließ keinerlei Dateiartefakte (Sucuri ); der Fernscanner von Sucuri verzeichnete 2024 insgesamt 96.084 Sign1-Funde (SiteCheck 2024 ). Ein Dateiscanner hätte das nicht gefunden.

Wir führen das an, weil eine Bedrohungsübersicht, die nur die für das eigene Produkt günstigen Fälle listet, eine Verkaufspräsentation ist. Die ehrliche Einordnung ist enger und trotzdem nützlich: Die Überwachung von Schreibvorgängen adressiert dateibasierte Persistenz – den größten Teil und genau den Teil, der eine Site-Bereinigung überlebt –, während Injektionen in der Datenbank eine andere Maßnahme erfordern.

Zwei weitere Dinge, die Patchen nicht abdeckt

Lieferkette. Vier dokumentierte Vorfälle reichen vom Credential Stuffing bei WordPress.org 2024 über eine kompromittierte Build-Pipeline bei ShapedPlugin bis zu einer vergifteten API-Antwort bei BdThemes . Keiner dieser Fälle wird durch zügiges Patchen verhindert, denn der Schadcode kommt über den Update-Mechanismus – signiert und erwartet. Dateiintegrität ist die Schicht, die das sieht.

Alter. Wir haben den vollständigen CISA-KEV-Katalog ausgewertet (v2026.09.02, 1.694 Einträge) und darin nur sechs WordPress-bezogene Einträge gefunden. Keine der vielzitierten Plugin-CVEs – Bricks, LiteSpeed Cache, GiveWP, die Hunk-Companion-Kette, die 2026er Lücken in Elementor Pro und Ninja Forms – ist darunter; aufgenommen wurden lediglich die WordPress-Core-CVEs vom Juli 2026, mit einer Frist von drei Tagen. Wenn Sie irgendwo lesen, eine Plugin-CVE stehe im KEV, ist das überprüfbar – und meistens falsch. Nützlich ist die Umkehrung: CVE-2020-25213 (WP File Manager, 2021 ins KEV aufgenommen) taucht 2026 weiterhin im WP-SHELLSTORM-Kit von SOCRadar auf – eine sechs Jahre alte Schwachstelle, die immer noch massenhaft ausgenutzt wird.

Ein Hinweis für alle, die Schweregrade zitieren: Sechs CVEs in diesem Umfeld tragen widersprüchliche CVSS-Werte verschiedener Zuweiser, besonders auffällig CVE-2026-60137 mit 5,9 von WPScan und 9,1 von CISA-ADP. Nennen Sie immer den Zuweiser.

Was das für CyberPanel-Betreiber bedeutet

1. Behandeln Sie .php in einem Upload-Verzeichnis als Vorfall, nicht als Befund. Es ist der wertvollste Dateiindikator im gesamten Datenbestand, und er stammt aus den IoC-Empfehlungen der Anbieter, nicht von uns.
2. Überwachen Sie mu-plugins und .htaccess, nicht nur Plugin-Verzeichnisse. Beide wirken automatisch, beide sind in der WordPress-Oberfläche unsichtbar, und beide tauchen in dokumentierten Kampagnen von 2024 bis 2026 auf.
3. Gehen Sie davon aus, dass der Schreibvorgang vor dem Patch kommt. Bei einem Median von fünf Stunden bis zur ersten Ausnutzung und Fällen, die vor dem Advisory beginnen, hilft die Maßnahme, die eine neue Datei bemerkt – nicht die, die auf den nächtlichen Durchlauf wartet. Die Begründung finden Sie unter Warum Webshell-Erkennung auf den Server gehört .
4. Behalten Sie eine Maßnahme für die Datenbank im Plan. Sign1 erinnert daran, dass Dateiüberwachung eine klar definierte Grenze hat. Site-Scans und Datenbankprüfung bleiben Teil einer vollständigen Antwort.
5. Datieren Sie jede Statistik, die Sie weitergeben. Die 49,21 Prozent sind von 2023. Die Wordfence-Jahresreihe endet bei 2024. Beides als aktuell auszugeben ist der Fehler, der Sie bei einem nachrechnenden Kunden am meisten kostet.

Shelltrap überwacht Schreibvorgänge unterhalb Ihrer Kundenverzeichnisse in Echtzeit, bewertet Funde mit ClamAV, YARA, Hash-Sets und Heuristik in einem gekapselten Worker und kann einen Web-Upload zur Prüfung anhalten, bevor die Anwendung ihn sieht. Die Installationsdokumentation zeigt, was das auf Ihrem Host voraussetzt; die Konditionen stehen auf der Preisseite .