Veröffentlicht am 11.07.2026
Ein einziger Konfigurationsfehler hat eine der größten automatisierten Angriffskampagnen des Jahres gegen WordPress- und Joomla-Websites ans Licht gebracht. Eine Cybercrime-Gruppe, von Sicherheitsforschern WP-SHELLSTORM getauft, ließ ihren eigenen Angriffsserver 22 Tage lang völlig ungeschützt und ohne Passwort im Internet stehen. Das Ergebnis: Rund 800 Megabyte an Werkzeugen, Protokollen und Ziellisten wurden für Forscher einsehbar – und offenbarten das erschreckende Ausmaß der Operation. Auf den Ziellisten standen über 1,4 Millionen Domains. Bestätigt kompromittiert wurden mindestens 25.195 Websites.
Wenn Sie eine WordPress- oder Joomla-Website betreiben, sollten Sie diesen Artikel bis zum Ende lesen. Denn die Angreifer nutzten keine geheimen „Zero-Day"-Lücken (also Schwachstellen, für die es noch keinen Patch gibt), sondern 27 längst bekannte Sicherheitslücken in verbreiteten Plugins. Wer nicht zeitnah aktualisiert, ist ein leichtes Ziel.
Am 11. Juni 2026 entdeckte das Sicherheitsunternehmen SOCRadar ein offenes Verzeichnis auf einem US-amerikanischen Server (IP-Adresse 137.175.93.126). Der Betreiber hatte dort einen einfachen Python-Webserver ohne jede Zugangskontrolle laufen lassen. In diesem Verzeichnis lagen 434 Dateien: Webshells (versteckte Fernsteuerungs-Programme), Exploit-Skripte, Scan-Ergebnisse, die komplette Kommando-Historie des Angreifers und die Konfigurationen der Command-and-Control-Infrastruktur (also der Steuerungsserver, über die kompromittierte Websites ferngesteuert werden).
Die Forscher von Ctrl-Alt-Intel hatten dasselbe Verzeichnis bereits über eine Suchplattform gefunden und am 22. Juni 2026 einen ersten Bericht veröffentlicht. SOCRadar folgte am 9. Juli mit einer ausführlichen Analyse, The Hacker News berichtete am 10. Juli. Das SOCRadar-Team fasst die Bedeutung des Fundes so zusammen:
„Was hier zum Vorschein kam – heute als WP-SHELLSTORM bekannt – ist eine moderne Webshell-Zugangs-Handelsoperation: über 1,4 Millionen anvisierte Domains, 27 als Waffe genutzte CVEs, mehr als 5.700 aktive Webshells und eine zweite, leisere Kampagne gegen Java-Unternehmensinfrastruktur." (SOCRadar Threat Intelligence Team)
Der Begriff „Webshell-Zugangs-Handel" (auf Englisch Webshell Access Brokerage) ist zentral: Die Gruppe kompromittiert Websites nicht nur für eigene Zwecke, sondern verkauft den Zugang weiter. Käufer nutzen die gekaperten Seiten dann für Ransomware, Datendiebstahl, SEO-Spam oder das Hosten von Phishing-Seiten. Eine einmal infizierte Website kann so von mehreren Kriminellen gleichzeitig missbraucht werden.
Die Angreifer arbeiten nach einem industriellen, wiederholbaren Muster. Zunächst suchen sie über eine Suchmaschine namens FOFA (ein chinesisches Gegenstück zu Shodan, das verwundbare Systeme im Internet auffindbar macht) nach angreifbaren Websites. Anschließend starten sie automatisierte Angriffe mit bis zu 500 parallelen Prozessen gleichzeitig. Klappt der Angriff, laden sie zunächst eine kleine Test-Datei hoch, um den Erfolg zu prüfen, und ersetzen diese dann durch die eigentliche Hintertür.
Die mit Abstand produktivste Schwachstelle war CVE-2026-3844 im WordPress-Plugin Breeze Cache (ein Plugin zur Beschleunigung von Websites, mit rund 400.000 aktiven Installationen). Die Lücke hat den Höchstwert-nahen CVSS-Score 9.8. Über 45.000 Seiten wurden angegriffen, bei 17.064 Seiten gibt es bestätigte Belege für eine Kompromittierung. Der technische Trick: Eine Funktion des Plugins lädt Profilbilder (Gravatare) von externen Servern herunter und speichert sie – ohne zu prüfen, ob es sich wirklich um ein Bild handelt. Angreifer schmuggeln über das Autor-Feld eines Kommentars die Adresse einer schädlichen PHP-Datei ein. Der Server lädt diese herunter und legt sie in einem öffentlich erreichbaren Verzeichnis ab. Wichtig: Ausnutzbar ist die Lücke nur, wenn die nicht standardmäßig aktivierte Option „Host Files Locally – Gravatars" eingeschaltet ist.
Wordfence, ein bekanntes WordPress-Sicherheitsunternehmen, beschreibt die Lage:
„Am 22. April 2026 haben wir eine kritische Schwachstelle für das Hochladen beliebiger Dateien in Breeze Cache offengelegt. Unsere Aufzeichnungen zeigen, dass Angreifer begannen, das Problem noch am selben Tag auszunutzen, an dem die Schwachstelle veröffentlicht wurde. Die Wordfence-Firewall hat bereits über 30.000 Exploit-Versuche gegen diese Schwachstelle blockiert." (Wordfence)
Die zweite kritische Lücke, CVE-2026-48907 im Joomla Content Editor (JCE), erhielt den maximal möglichen CVSS-Score von 10.0 und wurde am 16. Juni 2026 von der US-Behörde CISA in den Katalog der aktiv ausgenutzten Schwachstellen aufgenommen. Sie erlaubt es Unbefugten, eigene Editor-Profile anzulegen und darüber PHP-Schadcode auszuführen. Bemerkenswert: Obwohl über 560.000 Joomla-Ziele angegriffen wurden, gab es nur 77 bestätigte Kompromittierungen – ein deutlicher Beleg dafür, dass die Joomla-Gemeinschaft schnell gepatcht hat.
Weitere ausgenutzte Lücken sind CVE-2026-3300 (Everest Forms Pro, ermöglicht die Ausführung von Schadcode über öffentliche Formulare), CVE-2026-1969 (ThemeREX Addons, 3.378 bestätigte Kompromittierungen), CVE-2026-6433 (Custom CSS JS & PHP), CVE-2025-7443 (BerqWP) und CVE-2026-0740 (Ninja Forms File Uploads).
Die zentrale Hintertür trägt den Dateinamen down.php und ist vierfach verschleiert, um von Sicherheitssoftware nicht erkannt zu werden. Sie erlaubt volle Dateiverwaltung, das Ausführen von Betriebssystem-Befehlen, sogenannte Reverse Shells (Fernsteuerung des Servers), sowie den Zugriff auf die Datenbank. Für dauerhaften Zugang installiert die Gruppe zusätzlich ein Werkzeug namens VShell, das sich besonders raffiniert tarnt: Es benennt seinen Prozess in [kworker/0:2] um – den Namen eines legitimen Linux-Kernel-Prozesses. So fällt es bei einer oberflächlichen Kontrolle nicht auf.
Dass es sich um ein koordiniertes Botnet handelt, belegt ein konkreter Fund: Am 11. Juni 2026 luden innerhalb einer einzigen Sekunde 24 verschiedene IP-Adressen dasselbe Schadpaket herunter – genau eine Sekunde, nachdem der Betreiber selbst einen Test durchgeführt hatte. „Das ist koordinierte Befehlsverteilung, kein zufälliges Abgreifen", so SOCRadar.
Grundsätzlich gefährdet sind alle WordPress- und Joomla-Websites, die eines der betroffenen Plugins in einer veralteten Version einsetzen. Besonders im Visier stehen Seiten, die:
Die Patchstack-Analyse „State of WordPress Security 2026" liefert eine erschreckende Zahl:
„Die gewichtete mediane Zeit bis zum ersten Angriff beträgt 5 Stunden. Die am stärksten anvisierten Schwachstellen werden typischerweise innerhalb von Stunden angegriffen, nicht Tagen." (Patchstack)Wer also erst Tage nach Bekanntwerden einer Lücke aktualisiert, ist oft schon zu spät dran.
*.bd.php, *.wp-log.php, brq-*.php, down.php und BZ_*.php. Unter Linux hilft: find /var/www -name '*.php' -newer /var/www/wp-config.php -mtime -90ps aux | grep kworker aus. Ein echter Kernel-Prozess hat unter /proc/<pid>/exe keinen Verweis und keine Netzwerkverbindungen. Zeigt ss -tp | grep <pid> Netzwerkverbindungen für einen [kworker]-Prozess, ist das ein Imposteur./wp-comments-post.php mit srcset= im Inhalt (Breeze-Angriff) oder nach option=com_jce&task=profiles.import (JCE-Angriff). Bekannte Angreifer-IPs: 137.175.93.126 und 43.108.17.80.ctrlaltintel.com/research/Exposure können Sie prüfen, ob Ihre Domain in den erbeuteten Ziellisten auftaucht.wp core verify-checksums ausführen, um manipulierte Core-Dateien zu erkennen.Alle kritischen Patches sind bereits verfügbar. Handeln Sie umgehend:
wp plugin update --all.php_flag engine off. Setzen Sie Dateiberechtigungen restriktiv (644 für Dateien, 755 für Verzeichnisse).Wichtig – auch der Hersteller von JCE warnt ausdrücklich:
„Die Schwachstelle wird aktiv ausgenutzt, funktionierender Exploit-Code ist öffentlich, und die Angriffe sind automatisiert – eine Seite ohne öffentliche Registrierung ist also nicht sicher. Ein wichtiger Punkt: Das Update schließt das Einfallstor, säubert aber keine bereits kompromittierte Seite. Wenn Sie vor dem Update getroffen wurden, entfernt das Update nicht, was der Angreifer hinterlassen hat." (Joomla Content Editor)
Sollten Sie eine Kompromittierung feststellen: Nehmen Sie die Seite sofort offline, erstellen Sie ein forensisches Backup, entfernen Sie alle Hintertür-Dateien, rotieren Sie sämtliche Passwörter und API-Schlüssel, und spielen Sie ein sauberes Backup ein.
Für deutsche KMU ist eine Kompromittierung durch WP-SHELLSTORM in aller Regel eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO. Die installierten Hintertüren ermöglichen vollen Zugriff auf Datenbanken (Kundendaten, Bestelldaten, Kontaktformular-Eingaben, Passwort-Hashes) und Konfigurationsdateien. Das entspricht einer Verletzung der Vertraulichkeit personenbezogener Daten.
Sie müssen die Verletzung innerhalb von 72 Stunden nach Kenntnisnahme bei Ihrer zuständigen Landesdatenschutzbehörde melden. Bei hohem Risiko für Betroffene – etwa bei Zahlungs- oder Zugangsdaten – müssen Sie zusätzlich die betroffenen Personen informieren (Art. 34 DSGVO).
Besonders relevant: Das Unterlassen bekannter Sicherheitsupdates kann als Verstoß gegen Art. 32 DSGVO (Sicherheit der Verarbeitung) gewertet werden. Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes sind möglich, in schweren Fällen sogar bis zu 20 Millionen Euro oder 4 %. Deutsche Aufsichtsbehörden haben auch gegen kleine Unternehmen Bußgelder verhängt, wenn grundlegende Schutzmaßnahmen nachweislich vernachlässigt wurden.
Der BSI-Lagebericht 2025 unterstreicht die Dringlichkeit. BSI-Präsidentin Claudia Plattner fasst zusammen: „Die Gesamtlage ist nach wie vor angespannt." Und Bundesinnenminister Alexander Dobrindt stellt klar: „Es gibt keine uninteressanten Ziele für Cyberangriffe, solange Aufwand und Nutzen in einem für Angreifer günstigen Verhältnis stehen." Laut BSI sind 80 % der Ransomware-Opfer KMU.
WP-SHELLSTORM ist ein Lehrstück dafür, dass Cyberkriminalität heute industriell und vollautomatisiert abläuft. The Hacker News bringt es auf den Punkt:
„Was WP-SHELLSTORM Aufmerksamkeit verdient, ist nicht, wie fortgeschritten die Kampagne ist, sondern wie gewöhnlich. Öffentliche Exploits, automatisiertes Scannen und eine millionenzeilige Zielliste reichten aus, um Seiten in großem Maßstab zu kompromittieren – kein Zero-Day nötig." (The Hacker News)
Die gute Nachricht: Alle notwendigen Patches sind verfügbar, und die Verteidigung ist kein Hexenwerk. Aktualisieren Sie Ihre Plugins konsequent, aktivieren Sie automatische Updates und eine Web Application Firewall, und richten Sie ein Dateiänderungs-Monitoring ein. Angesichts einer medianen Angriffszeit von nur 5 Stunden nach Bekanntwerden einer Lücke ist zeitnahes, automatisiertes Patch-Management heute keine Kür mehr, sondern Pflicht – auch aus Haftungsgründen. Prüfen Sie Ihre Website noch heute.