Elementor-Addons gehackt: Warum Löschen bei BdThemes nicht reicht

Bei der Sicherheitslücke in BdThemes Element Pack und sechs weiteren Plugins kamen zwei Ursachen zusammen. Das erste stammt laut Wordfence von den Plugin-Autoren: Das Feld display_id aus der Server-Antwort landete ungeschützt in einem HTML-Attribut — eine Cross-Site-Scripting-Lücke (XSS), bei der fremder Programmcode als Teil der Seite ausgeliefert und im Browser ausgeführt wird. Das zweite: Angreifer erlangten Schreibzugriff auf den Objektspeicher des Herstellers bei DigitalOcean Spaces.

Dort liegen die Werbebanner, die die Plugins im WordPress-Adminbereich anzeigen — flache JSON-Dateien, die die Angreifer durch präparierte Fassungen ersetzten. Genau das ist ein Lieferkettenangriff: Angegriffen wird nicht Ihre Website, sondern ein Zulieferer, dem Ihre Website vertraut.

Ausgelöst hat sich der Schadcode von selbst. Das Skript lädt bei jedem Aufruf einer beliebigen Seite im Adminbereich, ohne Zutun des Nutzers, und lief im Browser des angemeldeten Administrators. Betroffen ist damit jede Installation, in der eines der Plugins aktiv war und sich ein Administrator im Backend bewegt hat.

Ab da gab es zwei Nutzlasten; welche eine Website traf, hing davon ab, welchen Endpunkt ihr Plugin abfragte. w2.js legte über die REST-API von WordPress ein Administrator-Konto an, mit dem Sicherheits-Token der laufenden Admin-Sitzung, installierte ein getarntes Plugin mit einer Webshell — einer über die Adresszeile bedienbaren Fernsteuerung — und darüber zwei Backdoors im Ordner mu-plugins, die WordPress ohne Aktivierung ausführt und die für Persistenz sorgen, also für dauerhaften Zugang. x.js legte nur ein Administrator-Konto mit berechenbarem Namen und Passwort an. Beide meldeten das Ergebnis an einen C2-Server, den Steuerserver der Angreifer.

Die Zeitachse laut Wordfence: Die Lücke entstand am 1. März 2026 in Prime Slider 4.1.9 und wurde danach auf die übrigen Plugins übertragen; ab dem 23. Juni 2026 kann der eingeschleuste Code aktiv gewesen sein; am 7. August 2026 wurde Wordfence informiert und fünf Plugins wurden gesperrt; am 8. August 2026 folgten die Sperre von Element Pack, der Sicherheitshinweis und die Bereinigung der Endpunkte. Dieselben Täter stecken laut Wordfence hinter zwei weiteren Lieferkettenangriffen auf WordPress-Erweiterungen in den Monaten davor. Eine eigene Stellungnahme von BdThemes lag am 14. August 2026 nicht vor; dokumentiert hat der Hersteller den Vorfall bislang nur im Changelog eines seiner Plugins.

Betroffen sind sieben Plugins von BdThemes. Sechs davon hat das WordPress-Plugin-Verzeichnis gesperrt, eines ist wieder verfügbar. Stand: 14. August 2026, direkt beim WordPress-Plugin-Verzeichnis abgefragt.

Ob eines dieser Elementor-Addons bei Ihnen läuft, sehen Sie unter Plugins → Installierte Plugins; der Slug entspricht dem Ordnernamen unter wp-content/plugins. Alle sieben teilen sich dieselbe Komponente, über die der Angriff lief — auch die beiden, die Elementor nicht im Namen tragen. Die Prime-Slider-Sicherheitslücke von 2026 und der Element-Pack-Vorfall sind deshalb ein und derselbe Vorgang, kein Zufall.

Live Copy Paste for Elementor ist als einziges der sieben Plugins heute wieder im Verzeichnis verfügbar. Zum Zeitpunkt der Wordfence-Meldung waren alle betroffenen Plugins gesperrt; die Sperre gilt laut Verzeichnis ausdrücklich als vorläufig. Warum dieses eine Plugin wieder freigegeben ist, ist nicht bekannt — Wordfence führt es weiterhin als betroffen. Behandeln Sie es wie die übrigen sechs.

Zur Sperrung selbst hält das Verzeichnis nur einen Satz bereit. Auf der Plugin-Seite im offiziellen WordPress-Verzeichnis von Element Pack steht: „This closure is temporary, pending a full review.“ Ein Freigabedatum nennt niemand.

Was tun, wenn ein WordPress-Plugin gesperrt wurde? Zunächst einmal nichts überstürzen: Es bleibt installiert und aktiv, gestoppt sind nur Download und Updates. Darin liegt die unangenehme Nebenwirkung — der Hersteller hat die Lücke geschlossen, aber über das Verzeichnis erreicht Sie dieses Update nicht. Und zur Einordnung: Betroffen heißt nicht automatisch kompromittiert. Prüfen müssen Sie trotzdem.

Weil der Schadcode nie über ein Plugin-Update kam. In dem Sicherheitshinweis von Wordfence vom 8. August 2026 heißt es: „No plugin update is required to become a victim. No file is modified on disk.“ Auf Deutsch: Niemand musste etwas installieren, um Opfer zu werden. Der Quellcode der Plugins war nie bösartig, vergiftet war der Datenstrom, den sie luden. Eine Integritätsprüfung, die die Plugin-Dateien mit dem Original vergleicht, schlägt deshalb nicht an. Das gilt aber nur für die Plugin-Dateien: Wo der Angriff durchlief, liegen die nachgeladenen Schaddateien sehr wohl auf dem Server, und Wordfence liefert eigens Prüfsummen dafür. Ein Malware-Scan des Dateisystems ist also keineswegs sinnlos. Daneben steht die WordPress-Sicherheitslücke wp2shell vom Juli 2026 — dort schließt ein Update die Lücke, hier hätte kein Update geholfen.

Der Hersteller bestätigt die Lücke im eigenen Changelog

Live Copy Paste ist das einzige der sieben Plugins, das nicht gesperrt ist — deshalb ist sein Changelog überhaupt noch öffentlich abrufbar. Dort beschreibt der Hersteller den Mechanismus mit eigenen Worten. Zu Version 1.5.5 vom 8. August 2026 steht im offiziellen Changelog des Herstellers: „Fixed: Security issue where data returned by the promotions API could be injected as script into the WordPress admin area.“ Sinngemäß: Daten der Werbe-Schnittstelle konnten als Skript in den WordPress-Adminbereich eingeschleust werden. Auch der Komponentenname passt: Die vergifteten Endpunkte lauten api[.]sigmative[.]io/…/biggopti/…, und zu Version 1.5.6 heißt es „Updated: Admin API Biggopti removed“. Zwei unabhängige Primärquellen, eine Bezeichnung.

Laut Wordfence entstand die Lücke am 1. März 2026 in Prime Slider 4.1.9 und wurde danach auf die übrigen Plugins übertragen. Der öffentliche Changelog von Live Copy Paste zeigt diesen Rollout: Am 3. März 2026 kam die Komponente dort an. Am 8. August 2026 folgte der Sicherheitsfix, am 10. August 2026 wurde die Komponente ganz entfernt.

Der Hersteller hat die Lücke geschlossen und die Werbebanner-Komponente am 10. August 2026 entfernt. Über das WordPress-Verzeichnis erreicht Sie dieses Update aber nicht, solange die sechs Plugins gesperrt sind — und ein geschlossener Programmfehler bereinigt keine Website, auf der bereits Konten und Backdoors liegen. Der Changelog belegt, dass und wann BdThemes die Lücke geschlossen hat, nicht, dass Version 1.5.5 oder 1.5.6 eine kompromittierte Website bereinigt.

Warum Sie den Vorfall in keiner Schwachstellendatenbank finden

Für die Lücke, um die es hier geht, ist bis heute keine CVE-Nummer vergeben: Weder unter der Komponentenbezeichnung Biggopti noch unter der Adresse der Sigmative-API findet sich ein Eintrag in der National Vulnerability Database (Stand 14. August 2026). Andere, davon unabhängige Schwachstellen in BdThemes-Plugins sind dort durchaus verzeichnet — mit diesem Lieferkettenangriff haben sie nichts zu tun. Wer die Lage über CVE-Listen oder einen Schwachstellen-Scanner beurteilt, sieht diesen Vorfall nicht.

Auch der Scanner hilft hier nur bedingt weiter. Wordfence hat die Erkennungsregeln für diesen Vorfall am 7. August 2026 an seine zahlenden Kunden ausgeliefert; in die kostenlose Version fließen sie erst nach rund 30 Tagen ein, also etwa ab Anfang September 2026. Ein unauffälliger Scan mit der freien Version sagt zu diesem Vorfall vorerst nichts aus.

Wordfence bewertet die XSS-Lücke über display_id mit einem CVSS-Wert von 5,4, also als mittel. Der Wert gilt ausschließlich für die Schwachstelle selbst, nicht für die Angriffskette, die auf ihr aufsetzt — und deren reale Folge ist die vollständige Übernahme der Website. Eine Gesamtbewertung der Kette gibt es nicht. Wer nach der Zahl 5,4 entscheidet, unterschätzt den Vorfall.

Das Entfernen des Plugins beendet den Angriffsweg, aber nicht den Zugriff. Die Angreifer hinterlassen versteckte Administratorkonten, Backdoors im Ordner mu-plugins, ein zusätzlich installiertes Plugin mit einer Webshell und Datenbank-Einträge, die alle unabhängig vom entfernten Plugin bestehen bleiben. Wer nur deinstalliert, schließt die Tür — während der Einbrecher noch im Haus ist.

Prüfen Sie jedes Administratorkonto, das Sie nicht selbst angelegt haben. Zwei Merkmale sind bekannt, und sie treten unabhängig voneinander auf: Benutzernamen aus bd_ und sechs weiteren Zeichen sowie Konten mit E-Mail-Adressen auf @wordpress.org oder @developer.wordpress.org. Ein Konto kann auch nur eines der beiden Merkmale tragen — und für einen Teil der Fälle ist gar kein Namensmuster bekannt.

Die beiden Backdoors liegen im Ordner wp-content/mu-plugins/. MU-Plugins führt WordPress ohne Aktivierung aus, in der normalen Plugin-Liste tauchen sie nicht auf. Das erste Modul öffnet über den URL-Parameter ?_wplogin= einen Zugang ohne Anmeldung, gezielt auf das am längsten bestehende Administratorkonto der Website; das zweite ist ein Tarnmodul.

Dazu kommt das getarnte Plugin mit der Webshell. Sie kam als komplettes Plugin mit harmlos klingendem Namen auf den Server, Wordfence nennt wp-smart-thumbnails als Beispiel. Darin liegt die Datei emer-run.php, die direkt über ihre Adresse aufgerufen wird. Deaktivieren genügt hier nicht, der Ordner muss weg. In der Datenbank bleiben außerdem die Optionen fz_emer_login_tokens und fz_emer_done_v1 stehen.

Aus der Praxis: Ich erlebe regelmäßig, dass Kunden das schadhafte Plugin löschen und die Sache damit für erledigt halten. Es geht aber um den Unterschied zwischen infiziert und kompromittiert. Infiziert heißt, es liegt etwas auf der Website, das dort nicht hingehört. Kompromittiert heißt, jemand hat einen Schlüssel — und den nimmt ihm keine Deinstallation ab.

Die Benutzerliste allein reicht nicht

Die angelegten Konten können aus der Benutzerliste ausgeblendet sein. Ein Blick unter Benutzer reicht als Prüfung deshalb nicht. Das Tarnmodul aus dem Ordner mu-plugins hängt sich in die Datenbankabfragen von WordPress, filtert die fremden Konten aus der Anzeige und zählt die Gesamtzahl entsprechend herunter — die Zahl im Dashboard scheint also zu stimmen. Wer versteckte Admin-Accounts in WordPress finden will, muss die Tabelle wp_users direkt in der Datenbank auslesen, meist über phpMyAdmin. Dass die WordPress-Benutzerliste unvollständig ist, fällt erst bei diesem Abgleich auf.

Diese Spuren suchen Sie

Für die Datei- und Datenbankpunkte brauchen Sie Zugriff auf den Webspace — über FTP oder den Dateimanager Ihres Hosters — und auf die Datenbank, meist über phpMyAdmin im Hoster-Panel. Nur der erste Punkt kommt ohne beides aus.

• In der Plugin-Liste: ein Plugin, das Sie nie installiert haben. Die Webshell kommt laut Wordfence als ganz normal aussehendes Plugin mit unauffälligem Namen ins System, Beispiel wp-smart-thumbnails; andere Namen sind möglich.
• Im Ordner wp-content/mu-plugins/: emer-run.php (MD5 1024732009983dd5e54b4cf5593f04d4, die Webshell im getarnten Plugin), class-wp-token-validate.php (MD5 7719cd98a35ffad2771f26d1ceab7d27, die Magic-Login-Hintertür), class-wp-query-9d127ff3.php oder ein ähnlicher Name nach dem Muster class-wp-query-*.php (MD5 9aadc3e5c5242b273bd17c5bdc358845, das Tarnmodul) sowie wp-cache-optimizer.php (MD5 e450ae5bc4bfc0d960dded06a76bb8e9).
• In der Options-Tabelle (standardmäßig wp_options): fz_emer_login_tokens mit den Token der Hintertür und fz_emer_done_v1 als Merker für eine abgeschlossene Kompromittierung.
• In der Benutzertabelle: Konten mit E-Mail-Adressen auf @wordpress.org oder @developer.wordpress.org und Benutzernamen nach dem Muster bd_ plus sechs Zeichen. Das Namensmuster gilt nur für eine der beiden Nutzlasten, die E-Mail-Domains treten unabhängig davon auf.
• Vom Angreifer betriebene Adressen: ia-cdn[.]com/fz/w2.js als Hauptnutzlast, ia-cdn[.]com/fz/c als Meldekanal und api[.]sigmative[.]io/prod/store/api/biggopti/x.js als zweite Nutzlast, die die Angreifer in den Speicher des Herstellers hochgeladen haben. Ein Treffer darauf ist ein Befund.
• Reguläre Endpunkte des Herstellers, die vergiftet waren und seit dem 8. August 2026 wieder sauberes JSON liefern: …/biggopti/api-data-all-records und …/biggopti/api-data-records, beide unter api[.]sigmative[.]io/prod/store/api/. Ein Treffer allein beweist hier nichts.

Die vier Dateinamen sind die Namen aus den untersuchten Fällen. Wordfence weist ausdrücklich darauf hin, dass sie sich von Fall zu Fall unterscheiden können. Sehen Sie den Ordner mu-plugins deshalb vollständig durch: Alles, was Sie dort nicht selbst abgelegt haben und was nicht von Ihrem Hoster stammt, gehört geprüft. Verlassen Sie sich dabei nicht auf das Änderungsdatum — die beiden Backdoor-Module, die Wordfence sichern konnte, waren auf September 2025 zurückdatiert, um zwischen den übrigen Dateien nicht aufzufallen.

Ein Hinweis zur Log-Auswertung: Die beiden ia-cdn-Adressen wurden vom Browser des Administrators abgerufen, nicht vom Server. Im Zugriffsprotokoll Ihres Hosters stehen sie deshalb in aller Regel nicht. Ihr Fehlen dort ist kein Entlastungsbeweis.

Diese Liste deckt den Kenntnisstand vom 8. August 2026 ab, nicht alle denkbaren Spuren. Ein unauffälliger Befund ist ein gutes Zeichen, aber kein Nachweis: Wer die Indikatoren nicht findet, ist damit nicht nachweislich sauber.

Logs und Backups bis zum 23. Juni zurück prüfen

Ab dem 23. Juni 2026 kann der eingeschleuste Code aktiv gewesen sein — wer erst seit der Warnung vom 8. August prüft, sieht nur das Ende. Suchen Sie in den Zugriffslogs ab dem 23. Juni 2026 gezielt nach vier Spuren: Aufrufen mit dem Anhängsel ?_wplogin=, direkten Aufrufen der Datei emer-run.php, POST-Anfragen an wp-admin/user-new.php und Plugin-Uploads, die Sie nicht selbst ausgelöst haben. Die Zugriffslogs des Servers liegen beim Hoster; ich fordere sie dort für Sie an. Den Weg zu den Protokollen von WordPress selbst zeigt WordPress Error-Logs finden und lesen.

Eines der beiden Backdoor-Module öffnet über einen Aufruf mit ?_wplogin= einen Administratorzugang ohne Passwort — und zwar auf das am längsten bestehende Administratorkonto der Website. Verdächtige Aktivität kann deshalb auch unter einem Konto auftauchen, das Sie kennen und für harmlos halten. Die zugehörigen Token liegen in der Datenbank-Option fz_emer_login_tokens. Und rechnen Sie damit, dass Backups aus diesem Zeitraum die Backdoors bereits enthalten.

Sieben Schritte, in dieser Reihenfolge:

1. Website auf Serverebene vom Netz nehmen: Ein Wartungsmodus aus WordPress heraus genügt dafür nicht. Die Webshell wird direkt über ihre eigene Adresse aufgerufen und läuft an einem Wartungsmodus vorbei, und die Backdoor im Ordner mu-plugins startet vor jedem normalen Plugin. Wirklich zu ist die Seite erst, wenn Ihr Hoster sie sperrt oder der Zugriff serverseitig auf Ihre eigene IP-Adresse beschränkt wird.
2. Backup anlegen und Logs sichern lassen: Legen Sie ein vollständiges Backup von Dateien und Datenbank an — wie das geht, zeigt meine Anleitung WordPress-Backup erstellen. Bitten Sie Ihren Hoster im selben Zug, die Zugriffs- und Fehlerlogs ab dem 23. Juni 2026 zu sichern und den letzten Backup-Stand von vor dem 23. Juni 2026 aus der Rotation zu nehmen. Logs und alte Backup-Stände sind das Einzige an diesem Vorfall, das von selbst verschwindet; alles andere können Sie auch morgen noch prüfen.
3. Betroffene Plugins deaktivieren und entfernen: notwendig, aber nicht hinreichend — die Reste bleiben liegen.
4. MU-Plugins, das getarnte Plugin und die Datenbank-Optionen bereinigen: die Webshell samt ihrem Plugin-Ordner, die beiden Module aus wp-content/mu-plugins/ und die Einträge fz_emer_login_tokens und fz_emer_done_v1.
5. Benutzerliste prüfen und fremde Administratoren entfernen: Erst wenn das Tarnmodul aus dem Ordner mu-plugins entfernt ist, zeigt WordPress die angelegten Konten wieder in der Benutzerliste an. Löschen Sie sie dann über WordPress selbst, nicht in der Datenbank — dabei werden Metadaten und Inhalte der Konten sauber mitbehandelt. Solange das Modul noch aktiv ist, ist die Anzeige manipuliert; dann hilft nur der Blick direkt in die Datenbank.
6. Passwörter und Auth-Salts erneuern: alle Passwörter neu setzen und die Auth-Salts in der wp-config.php austauschen. Das beendet alle bestehenden Sitzungen.
7. Logs ab dem 23. Juni auswerten: nach den vier oben genannten Spuren suchen und Ihren Hoster einbeziehen, denn die Zugriffslogs des Servers liegen dort.

Diese sieben Schritte decken den bekannten Angriffsweg und die bekannten Spuren ab, Stand 8. August 2026. Ein Freitest sind sie nicht: Wer sie abgearbeitet hat, hat den bekannten Weg geschlossen und die gefundenen Spuren beseitigt — nicht bewiesen, dass nichts übrig ist. Wenn die Website Geld verdient oder Kundendaten führt, gehört danach eine vollständige Prüfung dazu; die übernehme ich für Sie.

Prüfen können Sie alles selbst: die Plugin-Liste, den Ordner mu-plugins, die Benutzerliste und die angezeigte Benutzerzahl. Das ist reines Ansehen und richtet keinen Schaden an. Beim Eingreifen verläuft die Grenze woanders: Sobald in der Datenbank gelöscht, im Ordner mu-plugins aufgeräumt oder die wp-config.php geändert wird, ist ein Fehlgriff nicht mehr rückgängig zu machen. Wenn Sie dabei unsicher sind, übernehme ich das.

Die ausführliche Bereinigungsanleitung über diesen Vorfall hinaus steht im Ratgeber Website gehackt: Malware finden und entfernen; wann ein alter Stand der bessere Weg ist, klärt Website aus einem Backup wiederherstellen. Was danach dauerhaft absichert, fasst Website-Sicherheit für Unternehmen zusammen.