Forscher im Bereich Cybersicherheit haben einen Supply-Chain-Vorfall im WordPress-Ökosystem gemeldet, der mit dem Plugin-Anbieter BdThemes in Verbindung steht. Statt wie bei klassischen Angriffen Code direkt im offiziellen Repository zu verändern, setzten die Angreifer auf eine andere Methode: Sie vergifteten einen statischen JSON-Datenstrom, der von einer Admin-Komponente genutzt wird. Das Ergebnis ist besonders kritisch, weil sich die Schadlogik im Browser angemeldeter Administratoren ausführt und anschließend versteckte Kontrolle über kompromittierte Websites aufbaut.
Als Reaktion darauf wurden die Downloads der betroffenen BdThemes-Plugins vorübergehend deaktiviert. Gleichzeitig erscheinen die jeweiligen Plugin-Einträge im WordPress-Verzeichnis mit Hinweisen auf eine vorläufige Schließung bis zu einer „vollständigen Prüfung“.
Wie der BdThemes Supply-Chain-Angriff funktioniert
Ein wichtiges Detail in der Analyse: Laut Wordfence wurden in der offiziellen WordPress.org-Infrastruktur keine Quellcode-Dateien verändert. Der Angriff lief stattdessen über eine administrative Anzeige-Komponente, die Werbebanner einbindet und dafür JSON-Daten aus einer externen Quelle abruft.
Konkret hängt das Ganze an einer internen Bibliothek namens Biggopti, die zusammen mit den Plugins ausgeliefert wird. Dieses System ist dafür ausgelegt, relevante Werbebanner im WordPress-Adminbereich darzustellen, indem es JSON-Dateien aus einem DigitalOcean-Spaces-Bucket bezieht.
Der Schwachpunkt liegt dabei nicht primär im Plugin-Quelltext selbst, sondern im Parsing der JSON-Antwort. Die Forschenden berichten von einer Cross-Site-Scripting-(XSS)-Lücke, ausgelöst über einen Parameter aus der Sigmative API („display_id“). Weil auf Client-Seite nicht ausreichend escaped wurde, konnte ein Angreifer durch manipulierte JSON-Daten beliebige Webskripte einschleusen.
Warum Administratoren sofort betroffen sind
Das Schadskript läuft nicht nur in einem isolierten Kontext. Es startet bei jedem Seitenaufruf im wp-admin-Bereich, sobald die betroffene Komponente geladen wird. Damit wird die Attacke bei jedem Zugriff eines eingeloggten Admins effektiv „angestoßen“.
Aus Sicht der Angreifer ist das ein entscheidender Vorteil: Selbst wenn ein Administrator den Angriff nicht aktiv bemerkt, wird das eingeschleuste Skript still ausgeführt. Erst danach beginnt die eigentliche Eskalation: Rogue Administratorkonten werden erstellt, zusätzliche Komponenten werden installiert und anschließend wird aus dem kompromittierten System Kontakt zu einer Steuerinstanz aufgenommen.
Betroffene BdThemes-Plugins und typische Installationsbasis
Wordfence nennt mehrere betroffene Plugins, darunter Installationen mit teils sehr hoher Verbreitung. Dazu zählen unter anderem:
- Element Pack Addons for Elementor (u. a. Elementor Widgets/Template/Addon-Bausteine) – 100.000+ aktive Installationen
- Live Copy Paste for Elementor – 6.000+ aktive Installationen
- Pixel Gallery Addons for Elementor – genaue aktive Installationen werden in der Quelle nicht beziffert
- Prime Slider Addons for Elementor – aktive Installationen werden nicht beziffert
- Smart Admin Assistant – aktive Installationen werden nicht beziffert
- Ultimate Post Kit Addons for Elementor – aktive Installationen werden nicht beziffert
- Ultimate Store Kit (für WooCommerce/EDD/Elementor) – 6.000+ aktive Installationen
Auf den Plugin-Seiten im WordPress-Verzeichnis erscheint laut den Angaben jeweils eine Meldung, dass die Downloads ab dem 7. oder 8. August 2026 geschlossen wurden und bis zu einer vollständigen Prüfung nicht verfügbar sind.
Vergiftete JSON-Daten statt Plugin-Updates
Ein besonders bemerkenswerter Aspekt des Vorfalls ist, dass die Angreifer keine Plugin-Dateien auf der Festplatte anpassen mussten. Der Angriff wurde vollständig über die API-Antworten und den dazugehörigen JSON-Datenstrom durchgeführt.
Die Forschenden gehen davon aus, dass die Angreifer Schreibzugriff auf den DigitalOcean-Storage-Bucket erlangt haben. Dadurch konnten sie legitime JSON-Antworten durch speziell präparierte Inhalte ersetzen, die die XSS-Schwachstelle ausnutzen.
Die Payload: w2.js und der Aufbau von persistenter Kontrolle
Den Kern der ersten Phase bildet laut Analyse eine Payload, die über einen API-Endpunkt mit dem Namen api-data-all-records geliefert wird. Als Teil der Ausführung wird ein JavaScript namens w2.js verwendet, das nacheinander mehrere Schritte durchführt.
Im Einzelnen umfasst die Sequenz:
- Kontaktaufnahme zu einem Command-and-Control-(C2)-Server unter „ia-cdn[.]com/fz/c“. Dabei wird die Herkunft (Origin) der betroffenen Website übermittelt. Wenn der Server ein „skip“ oder „done“ zurückgibt, wird die Ausführung abgebrochen.
- Erstellung eines neuen Rogue-Administratorkontos über die WordPress REST API.
- Download eines scheinbaren Plugin-ZIPs vom C2-Server und Installation über das Standardformular zum Hochladen von Plugins. So wird ein PHP-Webshell mit dem Dateinamen emer-run.php bereitgestellt.
- Aufruf der Webshell, um zwei Persistenz-Module in das mu-plugins-Verzeichnis (Must-Use Plugins) einzuspielen: ein „Magic-Login“-Backdoor, das über einen URL-Parameter (z. B. ?_wplogin=<token>) einen nicht authentifizierten Adminzugang ermöglicht, sowie ein Stealth-Modul. Dieses Modul soll die Sichtbarkeit des Rogue-Users im Administrationskontext manipulieren, indem es u. a. Datenbankabfragen so „versteckt“, dass die Nutzerliste und die Gesamtanzahl nicht korrekt erscheinen.
Weil die XSS-Phase auf jeder wp-admin-Seite ausgelöst wird, laufen diese Schritte in der Praxis oft ohne auffällige Interaktion. Dadurch entsteht für Betreiber schnell eine Situation, in der Kontrolle und Nachweisbarkeit besonders schwierig werden.
Alternative Payload: x.js mit deterministischen Zugangsdaten
Neben w2.js wurde laut Wordfence außerdem eine alternative Payload entdeckt, die als x.js beschrieben wird. Diese wird über einen anderen API-Endpunkt, api-data-records, an betroffene Systeme ausgeliefert und ist darauf ausgelegt, deterministische Administratorzugänge zu erzeugen.
Das bedeutet: Die Zugangsdaten werden aus der Hostname-Adresse der Zielseite mathematisch abgeleitet. Laut der Analyse entstehen dabei vorhersehbare Benutzernamen im Muster „bd_“ plus eine 6-stellige base36-Kodierung. Die Passwörter folgen dem Schema „Bd@26!“ plus Hash und ein zusätzlicher Suffix. Als E-Mail wird eine Adresse im Bereich @wordpress.org verwendet.
Weil diese Credentials vorhersagbar sind, müssen die Angreifer offenbar keine zentralen Listen kompromittierter Domains speichern. Für Incident-Responder kann das dagegen eine Chance sein: Mit demselben Berechnungsprinzip lassen sich mögliche Rogue-Zugänge auf verdächtigen Systemen gezielt überprüfen.
Ausmaß und Einordnung: weitere Supply-Chain-Spuren
Wordfence ordnet den Vorfall in eine Reihe ähnlicher Software-Lieferkettenangriffe ein. Dabei wurden in den vergangenen Monaten WordPress-Plugins backdoored, um Angreifern vollständigen Administratorzugriff auch ohne vorherige Authentifizierung zu ermöglichen. In einzelnen Fällen soll der Einstieg über Tokens oder über versteckte Administratorkonten erfolgen, die erst beim Login eines Admins aktiv werden.
Die Forschenden betonen außerdem, dass das Hochladen bösartiger JSON-Inhalte und die Bereitstellung der sekundären Payload direkt in das eigene Bucket-Infrastruktursystem des Anbieters erfolgt sein sollen. Das spricht für einen gravierenden Kompromittierungspfad entlang der Cloud-Speicherzugänge oder interner Infrastrukturkomponenten bei BdThemes.
Warum das Zeitfenster wichtig ist
Die Analyse nennt zudem, dass die problematische Änderung erstmals am 1. März 2026 in „bdthemes-prime-slider-lite“ eingeführt worden sein soll. Danach wurde sie offenbar auf weitere Plugins übertragen. Für Betreiber ist das relevant, weil es hilft, Zeitlinien einzuordnen und mögliche Kompromittierungsphasen abzuleiten.
Was Betreiber jetzt beachten sollten
Wenn Sie eines der genannten BdThemes-Plugins nutzen, sollten Sie die Lage ernst nehmen. Die kurzfristige Maßnahme der Plugin-Downloads zeigt bereits, dass die WordPress-Community den Vorfall als behandlungsbedürftig einstuft.
Praktisch empfiehlt sich vor allem, nach Anzeichen für Rogue-Accounts und mögliche Webshells zu suchen und die betroffenen Systeme danach zu bereinigen. Da die Ausführung auf wp-admin-Seiten passiert, kann außerdem die Protokollierung und das Prüfen von Admin-Aktivitäten in den betroffenen Zeiträumen hilfreich sein.
Zusätzlich ist es sinnvoll, die allgemeinen WordPress-Sicherheitsupdates im Blick zu behalten. In den Tagen um den Vorfall herum berichtete WordPress auch über eine weitere reflektierte XSS-Schwachstelle vor Authentifizierung, die in Kombination mit anderen Problemen das Risiko erhöhen kann.
Fazit: BdThemes Supply-Chain-Angriff zeigt das Risiko von Cloud-abhängigen Admin-Komponenten
Der BdThemes Supply-Chain-Angriff macht deutlich, wie gefährlich Angriffe über Lieferketten sein können, selbst wenn der sichtbare Plugin-Quellcode unverändert bleibt. Durch manipulierte JSON-Daten und eine XSS-Lücke in der Admin-Komponente konnten Angreifer still im Browser von Administratoren aktiv werden und anschließend persistente Kontrolle etablieren.
Für Betreiber gilt: Risiko nicht nur auf „Plugin-Update“ reduzieren, sondern auch externe Datenquellen, Admin-Komponenten und Spuren von Rogue-Zugängen systematisch prüfen.
Quelle: https://thehackernews.com/2026/08/bdthemes-supply-chain-attack-poisons.html
