Kapibala-Kampagne: Angreifer stiehlt 18.566 Datensätze über die wp2shell-Lücke, Deutschland unter den Opfern

GreyNoise dokumentiert eine mehrmonatige Kampagne, in der ein einzelner Akteur die im Juli 2026 gepatchte WordPress-Lücke ausnutzt, um in mindestens 49 Organisationen in 29 Ländern einzudringen. Aus einer westlichen Behörde flossen 18.566 Datensätze samt Klartext-Passwörtern und Personendaten ab, Deutschland gehört zu den vier meistgetroffenen Ländern.

Was der Angreifer gemacht hat

Am 22. Juli 2026 traf die Angriffskette ein Behördenportal automatisiert: CVE-2026-63030 plus CVE-2026-60137, gemeinsam als wp2shell-Exploit-Kette bekannt, luden eine eigene Webshell mit dem sprechenden Namen „kapibala-plugin“ nach. Danach lief das Skript einen kompletten Nutzerdatenbank-Dump, exfiltrierte 13 bestehende Administratoren im Klartext und legte einen 14. Admin an, dessen Registrierungsdatum sauber ins Jahr 2025 zurückdatiert war, damit der Zugriff im Audit unauffällig bleibt.

Von dort ging es weiter: 17 Script-Varianten gegen Microsofts Antimalware-Scan-Interface, Diebstahl von Windows-Authentifizierungstokens, ein lokaler Admin mit dem Kürzel „kapibala2″, Klartext-Passwörter aus Serverdateien, Password-Spraying gegen interne Server bis zum Zugriff auf die zentrale Datenbank. Ergebnis, so GreyNoise: „18,566 records including accounts, plaintext passwords, and personally identifiable information (PII)“.

Warum das jetzt wichtig ist, obwohl der Patch alt ist

WordPress hat wp2shell schon im Juli mit der Notfall-Version 7.0.2 gestopft. Wer damals sofort gepatcht hat, ist gegen den Initial-Zugriff geschützt, aber genau darin liegt das Problem: das Update entfernt keine Hintertüren, die vor dem Patch gelegt wurden. Ein zurückdatierter Admin-Account, eine getarnte Plugin-Datei im Uploads-Verzeichnis oder ein hinterlegter Cronjob überleben Updates unauffällig, wenn niemand nachschaut. Für Webdesigner heißt das: bei jedem WordPress-Kundenprojekt, das im Juli in den Panic-Update-Modus lief, mindestens einmal manuell die Nutzerliste und die aktiven Plugins abgleichen, bevor Ruhe einkehrt.

49 Organisationen, 29 Länder, Deutschland an der Spitze

Laut GreyNoise trifft die WordPress-Welle mindestens 49 Organisationen in 29 Ländern. Deutschland ist mit vier Opfern der schwerste Fall, gefolgt von Kolumbien und der Schweiz mit je drei, Brasilien, Japan, Polen und Großbritannien mit je zwei, dazu 22 weitere Länder mit je einem Treffer. Betroffen sind laut Bericht sowohl Behörden als auch kleinere Unternehmen, ein Muster, das die Ende Juli veröffentlichten Notfall-Warnungen bestätigt: die Lücke wurde breit gescannt, nicht chirurgisch eingesetzt.

WordPress ist nur ein Teil der Kampagne

Ab dem 17. August 2026 dokumentiert GreyNoise zusätzlich die aktive Ausnutzung eines bis dahin unbekannten Fehlers in Zyxels Smart-Managed-Switch-Serie GS1900 (CVE-2026-7273). 996 Geräte in 48 Ländern wurden über Python-Skripte ferngesteuert, es ist laut Bericht der erste öffentlich dokumentierte In-the-Wild-Fall. Parallel testet der Akteur laut GreyNoise Ubiquiti UniFi (CVE-2026-34908, -34909, -34910) sowie Gitea, Nuclio, SENAITE LIMS und Proxmox VE.

Wer steckt dahinter

GreyNoise ordnet den Akteur einem chinesischen Muttersprachler in Zeitzone UTC+8 zu, gestützt auf Sprachkommentare in den Skripten und den Aktivitätsrhythmus. Über die C2-Domain und die Malware-Familie ergibt sich ein möglicher Bezug zur bereits von Acronis dokumentierten Gruppe „Red Heron“; GreyNoise labelt das ausdrücklich als Vermutung, nicht als Bestätigung. Ebenfalls unbelegt bleibt die Hypothese, der Akteur habe für die vielen Skriptvarianten ein großes Sprachmodell zur Hand: der Bericht spricht von „suspects“, nicht von Beweisen.

Was heute konkret zu tun ist

Für alle, die WordPress-Kundenprojekte betreuen, drei Handgriffe, die keine Software brauchen:

• Nutzerliste komplett prüfen. Im WordPress-Backend unter „Benutzer“ nach Rollen sortieren und jeden Administrator einzeln bestätigen. Auffällig sind Registrierungsdaten aus 2025 oder früher, die nicht zum Projekt passen, Namen wie „kapibala2″ oder generische Kürzel und E-Mail-Domains, die nicht zum Kunden gehören.
• Plugin-Verzeichnis händisch inspizieren. wp-content/plugins/ nach Ordnern durchsehen, die nicht im Backend gelistet sind, keinen Header-Kommentar tragen oder mit „kapibala“ beginnen. Aktive Plugins über wp plugin list gegen den tatsächlichen Verzeichnisinhalt spiegeln.
• Netzwerkgeräte checken. Zyxel-GS1900-Switches im Kundennetz auf aktuelle Firmware ziehen und, falls das Modell End-of-Life ist, austauschen. Bei Ubiquiti UniFi den aktuellen Patch installieren.

Wenn du beim Prüfen merkst, dass ein Kunde eine dieser Baustellen offen hat, ist das oft der schnellste Weg in ein Folgeprojekt: so findest du systematisch die Websites in deiner Region, die genau solche Sicherheits- und Wartungslücken haben und die perfekte Kundschaft für eine saubere Betreuung sind.