BdThemes-Plugins: Supply-Chain-Angriff über manipulierte JSON-API

Ein kompromittierter externer Datenstrom kann eine WordPress-Installation angreifen, obwohl im Plugin-Verzeichnis keine einzige Quelldatei verändert wurde. Genau dieses Muster traf mehrere Plugins von BdThemes: Manipulierte JSON-Antworten lieferten JavaScript in jedes eingeloggte wp-admin-Dashboard und verschafften Angreifern dauerhaften Administratorzugriff.

Die betroffenen Plugins sind im offiziellen WordPress-Plugin-Verzeichnis vorübergehend geschlossen, während das WordPress-Plugins-Team sie prüft. Wenn du eines dieser Plugins betreibst, solltest du deine Installation sofort auf die unten aufgeführten Kompromittierungsindikatoren prüfen.

Warum dieser Angriff besonders gefährlich ist

Ein Plugin-Update oder eine manipulierte Datei auf dem Server war für den Angriff nicht nötig. Der Schadcode kam über eine Remote-API, lief im Browser eines angemeldeten Administrators und konnte dadurch neue Administratoren anlegen sowie weitere Malware installieren.

Betroffene Sicherheitslücke und Plugins

Die Biggopti Library enthält in mehreren Versionen eine Cross-Site-Scripting-Schwachstelle (XSS). XSS bedeutet, dass Angreifer eigenen Webcode in eine Seite einschleusen können, den der Browser anschließend im Kontext der betroffenen Website ausführt. Hier betrifft die Lücke den Wert display_id, den die Sigmative-API liefert.

Die Schwachstelle hat einen CVSS-Score von 5,4 (Medium) und ist ungepatcht. Weil die Ausgabe nicht ausreichend maskiert wird, kann ein Angreifer mit Schreibzugriff auf den Sigmative-API-Server beliebige Skripte in ausgelieferten Seiten platzieren. Jeder Aufruf einer präparierten Seite führt den Code dann aus.

Die folgende Software ist betroffen:

Element Pack Addons for Elementor – Elementor Widgets, Elementor Templates, Elementor Addons (bdthemes-element-pack-lite)
Live Copy Paste for Elementor – Cross Domain Copy Paste & Page Duplicator (live-copy-paste)
Pixel Gallery Addons for Elementor – Easy Grid, Creative Gallery, Drag and Drop Grid, Custom Grid Layout, Portfolio Gallery (pixel-gallery)
Prime Slider Addons for Elementor – Widgets, Templates & Elementor Addons (bdthemes-prime-slider-lite)
Smart Admin Assistant – Dashboard and Site Enhancements (smart-admin-assistant)
Ultimate Post Kit Addons for Elementor (ultimate-post-kit)
Ultimate Store Kit – Addon For WooCommerce, EDD and Elementor (ultimate-store-kit)

So nutzte die manipulierte API die Biggopti-Komponente aus

BdThemes liefert mit den Plugins die interne Komponente Biggopti aus. Sie lädt Werbebanner von einem API-Server und zeigt sie im WordPress-Adminbereich an. Hinter der API stehen statische JSON-Dateien in einem durch Cloudflare geschützten DigitalOcean-Spaces-Bucket, nicht etwa ein dynamischer Application Server.

Jedes Plugin mit Biggopti registriert auf admin_init ein clientseitiges JavaScript-Asset. Dieses Asset läuft dadurch bedingungslos bei jedem Laden einer beliebigen wp-admin-Seite. Es lädt Banner-Daten vom API-Endpoint und baut daraus einen Hinweis im Document Object Model (DOM).

Dabei übernimmt der Code display_id aus der JSON-Antwort direkt in das HTML-Attribut id. Er maskiert den Wert im Browser nicht:

// Nicht maskierter Wert aus der Remote-JSON-Antwort
var f = t.display_id || t.id || "default";

// Der Wert landet im HTML-Attribut id
var m = "bdt-admin-biggopti-api-biggopti-" + f;
A = 'id="' + m + '"';

// Nicht maskierter Wert aus der Remote-JSON-Antwort
var f = t.display_id || t.id || "default";

// Der Wert landet im HTML-Attribut id
var m = "bdt-admin-biggopti-api-biggopti-" + f;
A = 'id="' + m + '"';

Später im selben Code maskiert Biggopti das Attribut data-display-id dagegen korrekt. Die Funktion ersetzt &, <, >, und Anführungszeichen, bevor sie den Wert ausgibt. Diese Absicherung schützt jedoch nicht die zuvor eingefügte id.

function escapeDisplayId(value) {
  return (value || "")
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;");
}

function escapeDisplayId(value) {
  return (value || "")
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;");
}

Die unmaskierte Attribut-Injektion kam am 1. März 2026 mit Prime Slider 4.1.9 in SVN-Revision r3471891 hinzu und wurde anschließend in weitere Plugins übernommen. Spätere Versionen ergänzten zwar einen auf DOMParser basierenden Sanitizer für das Bannerfeld content, der gefährliche HTML-Tags und Inline-Handler entfernt. Das id-Attribut blieb jedoch weiterhin unmaskiert.

Ein unbefugter Akteur ersetzte die legitimen JSON-Antworten im Storage-Bucket durch präparierte Datensätze. Der manipulierte Wert display_id schließt das id-Attribut, fügt einen onanimationstart-Handler ein und startet eine CSS-Animation. Sie löst den Handler nach rund zehn Millisekunden aus, sobald ein Administrator irgendeine Dashboard-Seite lädt.

Der manipulierte Datensatz trug unter anderem einen display_id, der mit SAFE" onanimationstart=eval(String.fromCharCode(...)) style=animation:wrapperSlideInTop .01s ease-out both begann. Der kodierte Handler lud ein externes Skript von https://api.sigmative.io/prod/store/api/biggopti/x.js?_=1 nach und führte dessen Inhalt aus. Als Titel tarnte sich der Banner als „Build more. Pay less. This Summer“.

Zweistufige Payloads erzeugten Administratorzugriff und Persistenz

Die Event-Handler luden je nach verfügbarer Infrastruktur unterschiedliche Skripte. Beide Varianten arbeiteten im authentifizierten Browser-Kontext des Administrators und konnten daher dessen Berechtigungen für WordPress-Anfragen missbrauchen.

Primäre Payload: w2.js

Plugins, die den Endpoint api-data-all-records nutzten, erhielten die primäre Payload w2.js. Sie führte eine mehrstufige Kompromittierung aus:

C2-Prüfung: Das Skript kontaktierte ia-cdn[.]com/fz/c und übermittelte die Origin der betroffenen Website. Meldete der Command-and-Control-Server (C2) den Status skip oder done, brach das Skript ab.
Anlegen eines fremden Administratorkontos: Das Skript verwendete den in der aktiven Administratorsitzung vorhandenen Header X-WP-Nonce, um über die WordPress-REST-API einen Administrator anzulegen. Falls das scheiterte, nutzte es normale Formularübermittlungen als Rückfallweg.
Installation einer Webshell: Das Skript lud ein gefälschtes Plugin-ZIP vom C2-Server und installierte es über das Standardformular für Plugin-Uploads. Das Plugin tarnte sich unter dem Slug wp-smart-thumbnails oder ähnlich unauffälligen Slugs. Es enthielt die direkt per URL aufrufbare Webshell emer-run.php.
Persistenz über Must-Use-Plugins: Der Aufruf von emer-run.php installierte zwei Persistenzmodule im Verzeichnis für Must-Use-Plugins. Die untersuchten Exemplare waren auf September 2025 zurückdatiert, um sich in Dateisystem-Zeitstempel einzufügen. Dateinamen können je nach Infektion abweichen. Das erste Modul erlaubte einen nicht authentifizierten Admin-Login über ?_wplogin=<token> und zielte auf das am längsten registrierte Administratorkonto. Das zweite Modul hakte sich in WordPress-Datenbankabfragen ein, versteckte die angelegten fremden Konten aus der Admin-Benutzerliste und verringerte die angezeigte Gesamtzahl der Benutzer entsprechend.
Exfiltration: Das Skript übermittelte die Ergebnisse jeder Ausführungsphase mit navigator.sendBeacon an den C2-Server.

Alternative Payload: x.js

Die zweite Payload x.js lag direkt auf der BdThemes-Infrastruktur. Sie traf Plugins, die den Endpoint api-data-records verwendeten. Das Skript leitete Administratorzugangsdaten deterministisch aus dem Hostnamen der betroffenen Website ab.

Dafür berechnete es aus den Zeichen des Hostnamens einen 32-Bit-Hash, wandelte dessen Absolutwert in Base36 um und nutzte die ersten sechs Zeichen. Daraus entstanden Benutzernamen im Muster bd_ plus sechsstelliger Base36-Hash und Passwörter im Muster Bd@26! plus Hash plus x. Als E-Mail-Adresse verwendete das Skript <Benutzername>@wordpress.org.

Die festen Zugangsdaten ersparen den Angreifern eine zentral gespeicherte Liste kompromittierter Websites. Bei einem Verdacht kannst du den erwarteten Benutzernamen und das Passwort aus dem Domainnamen ableiten und gezielt danach suchen.

Anschließend rief das Skript /wp-admin/user-new.php mit den Cookies der aktuellen Sitzung ab, extrahierte Nonce und Logout-URL aus dem HTML und sendete eine Formularanfrage mit role=administrator. Es speicherte bei Erfolg ein lokales localStorage-Flag, erkannte Weiterleitungen mit Status 301, 302 oder opaqueredirect als Erfolg und meldete auch vorhandene Benutzernamen, fehlende Nonces, Fehler und Fehlschläge. Die Meldung enthielt Status, Zugangsdaten, Website-Origin, Logout-URL und aktuelle Seiten-URL; navigator.sendBeacon diente als erster Übertragungsweg, ein fetch()-POST mit no-cors und keepalive als Rückfallweg.

Einordnung und Reichweite

Die C2-Domain wird denselben Akteuren zugeordnet, die in den vorangegangenen zwei Monaten auch hinter den Supply-Chain-Angriffen auf Advanced Responsive Video Embedder und OptinMonster standen.

Die Kampagne zielte auf breite, unauffällige Admin-Persistenz und Remote Code Execution in sehr vielen WordPress-Umgebungen. Sie benötigte keinen direkten Zugriff auf die einzelnen Websites: Das Manipulieren eines Werbe-Feeds reichte aus, weil dessen Anzeigecode die XSS-Schwachstelle enthielt.

Dass die bösartigen JSON-Datensätze und x.js direkt im Bucket des Anbieters lagen, weist auf einen schwerwiegenden vorgelagerten Kompromiss von Cloud-Storage-Zugangsdaten oder interner BdThemes-Infrastruktur hin.

Kompromittierungsindikatoren prüfen

Prüfe Benutzerliste, Plugin-Verzeichnisse, Must-Use-Plugins und die Optionstabelle der Datenbank auf die folgenden Indikatoren. Die beiden manipulierten API-Endpoints waren bis zum 8. August 2026 wieder bereinigt, doch eine bereits erfolgte Kompromittierung bleibt dadurch bestehen.

Externe Ressourcen

Primäre Payload: ia-cdn[.]com/fz/w2.js
C2-Beacon-Endpoint: ia-cdn[.]com/fz/c
Manipulierter Vendor-API-Endpoint, inzwischen bereinigt: api[.]sigmative[.]io/prod/store/api/biggopti/api-data-all-records
Manipulierter Vendor-API-Endpoint, inzwischen bereinigt: api[.]sigmative[.]io/prod/store/api/biggopti/api-data-records
Manipulierte Payload auf der Vendor-Infrastruktur, inzwischen bereinigt: api[.]sigmative[.]io/prod/store/api/biggopti/x.js

Dateisystem und Datenbank

Webshell: emer-run.php mit MD5 1024732009983dd5e54b4cf5593f04d4
MU-Plugin für Magic Login: class-wp-token-validate.php mit MD5 7719cd98a35ffad2771f26d1ceab7d27
MU-Plugin für Tarnung: class-wp-query-9d127ff3.php oder ein ähnlich benanntes class-wp-query-*.php; MD5 9aadc3e5c5242b273bd17c5bdc358845
MU-Plugin mit Tarnbezeichnung „Health Check“: wp-cache-optimizer.php mit MD5 e450ae5bc4bfc0d960dded06a76bb8e9
Datenbankoption fz_emer_login_tokens, die Magic-Login-Token speichert
Datenbankoption fz_emer_done_v1, die eine abgeschlossene Kompromittierung markiert
Konten mit E-Mail-Adressen der Domains @wordpress.org oder @developer.wordpress.org
Benutzernamen nach dem Muster bd_ gefolgt von sechs alphanumerischen Zeichen

Zeitlicher Ablauf

1. März 2026: Biggopti-API-JavaScript wird in Prime Slider 4.1.9 aufgenommen, SVN-Revision r3471891. display_id fließt unmaskiert in ein id-Attribut; der API-Endpoint lautet api-data-records.
10. Mai 2026: Der Endpoint wechselt zu api-data-all-records. Ein DOMParser-Sanitizer kommt für das Feld content hinzu, das id-Attribut bleibt unmaskiert.
23. Juni 2026: Das Feld start_date der manipulierten API-Kampagne trägt diesen Zeitpunkt für den „Summer Sale“-Hinweis. Ab diesem Datum könnte die XSS frühestens aktiv gewesen sein.
6. August 2026, 22:40 UTC: Letzte Änderung am manipulierten api-data-records.
7. August 2026, 09:11 UTC: Letzte Änderung am manipulierten api-data-all-records.
7. August 2026: Der Angriff wird in freier Wildbahn beobachtet und das Threat-Intelligence-Team erhält die Meldung.
7. August 2026: Das WordPress-Plugin-Verzeichnis schließt die Plugins bis zum Abschluss der Prüfung.
7. August 2026, 16:56 UTC: Untersuchungsartefakte werden gesichert.
8. August 2026: Beide API-Endpoints liefern wieder sauberes JSON.

Jetzt kontrollieren und bereinigen

Deaktiviere die betroffenen BdThemes-Plugins, solange sie geschlossen sind, und prüfe anschließend alle Benutzerkonten, insbesondere versteckte oder verdächtige Administratoren. Durchsuche wp-content/plugins, das Verzeichnis wp-content/mu-plugins sowie die Optionstabelle nach sämtlichen genannten Dateien, Hashes und Optionsnamen.

Behandle jeden Fund als vollständige Website-Kompromittierung: entferne fremde Konten und Backdoors, prüfe die Integrität der Installation und rotiere Zugangsdaten. Da die Plugin-Dateien auf dem Server unverändert bleiben konnten, reichen dateibasierte Integritätsprüfungen allein nicht aus; kontrolliere zwingend auch Datenbank und Must-Use-Plugins.

Für Wordfence Premium, Care, Response und zahlende Wordfence-CLI-Kunden standen Malware-Signaturen und WAF-Regeln zur Erkennung dieser Supply-Chain-Kompromittierung seit dem 7. August 2026 bereit. Kostenlose Wordfence- und Wordfence-CLI-Nutzer erhalten diese Signaturen und Regeln nach der üblichen Verzögerung von 30 Tagen. Der Wordfence-Scanner und Wordfence CLI erkennen mit dem Premium-Signatursatz nach eigenen Angaben mehr als 99 Prozent der über 4,4 Millionen bekannten Malware-Samples und Kompromittierungsindikatoren; Wordfence CLI kann auch auf Serverebene scannen, wenn WordPress nicht mehr funktionsfähig ist.