Supply-Chain-Angriff auf Elementor-Plugins: was der BdThemes-Fall zeigt

Anfang August wurden sieben Erweiterungen des Herstellers BdThemes zu Schadcode-Verteilern — sechs davon für Elementor, und ohne dass sich in ihnen eine einzige Zeile änderte. Die Angreifer kamen nicht über die Plugins, sondern über einen Werbebanner-Feed, den die Plugins bei jedem Aufruf des Adminbereichs beim Hersteller abholen. Wer nur auf Updates schaut, hätte diesen Angriff nie kommen sehen — und hätte ihn danach auch nicht bemerkt. Dieser Beitrag erklärt, was passiert ist, und zeigt fünf Kontrollen, mit denen Sie Ihre eigene Website prüfen.

Das Wichtigste in Kürze

Sieben Plugins, keine veränderte Datei. Im offiziellen WordPress-Verzeichnis wurde kein Quellcode manipuliert. Vergiftet wurde ein JSON-Feed auf dem Speicher des Herstellers — dateibasierte Schadcode-Scanner sehen so etwas nicht.
Der Schadcode lief im Browser der eingeloggten Administration. Bei jedem Aufruf einer Adminseite, still. Er legte versteckte Administratorkonten an, installierte eine Webshell als Fake-Plugin und zwei Hintertüren im Verzeichnis mu-plugins.
Das grösste betroffene Plugin hat über 100’000 Installationen. Wie viele Websites tatsächlich übernommen wurden, ist nicht bekannt — dazu hat weder Wordfence noch BdThemes eine Zahl veröffentlicht. Wer «100’000 betroffene Seiten» liest, liest eine Installationszahl, keine Opferzahl.
Sechs der sieben Plugins sind bis heute nicht zurück im Verzeichnis. Wir haben es am 21. August selbst abgefragt, zwei Wochen nach der Schliessung. Nur eines ist wieder verfügbar.
Prüfen können Sie das selbst. Fünf Kontrollen, alle ohne Zusatzsoftware — Benutzerliste, mu-plugins, Plugin-Verzeichnis, zwei Datenbankeinträge. Der Ablauf steht weiter unten.

Was passiert ist

Am 7. August 2026 erhielt das Threat-Intelligence-Team der Sicherheitsfirma Wordfence einen Hinweis auf einen laufenden Angriff. Die Spur führte nicht zu einer Sicherheitslücke in WordPress und nicht zu einem manipulierten Plugin-Download, sondern zu einer Datei, an die kaum jemand denkt: einer JSON-Datei mit Werbebannern, die der Hersteller BdThemes auf einem Cloud-Speicher ablegt und die seine Plugins bei jedem Aufruf des Adminbereichs abholen.

Diese Banner erscheinen im Dashboard als Hinweis auf Angebote — «Build more. Pay less. This Summer» etwa. Der Baustein dahinter heisst intern Biggopti. Er lädt die JSON-Datei, liest ein Feld daraus aus und baut daraus ein HTML-Element im Adminbereich. Genau bei diesem Zusammenbauen steckte der Fehler: Ein Feld namens display_id wurde ungeprüft in den Seitenquelltext geschrieben. Wer den Inhalt dieses Feldes bestimmen konnte, konnte damit eigenen JavaScript-Code in den Adminbereich jeder Website einschleusen, die eines dieser Plugins einsetzt.

Und genau das taten die Angreifer. Sie verschafften sich Schreibzugriff auf den Speicherplatz des Herstellers — einen statischen Objektspeicher bei DigitalOcean, abgesichert hinter Cloudflare — und ersetzten die harmlosen Werbedaten durch präparierte. Wordfence beschreibt den Befund deutlich: Dass die vergifteten Datensätze und ein zweites Schadskript direkt im Speicher des Herstellers lagen, deute auf eine schwerwiegende Kompromittierung von BdThemes‘ Cloud-Zugangsdaten oder interner Infrastruktur hin.

Der eingeschleuste Code nutzte einen Trick, der ohne Zutun der Betrachterin auskommt: Er hängte sich an eine CSS-Animation, die nach einer Hundertstelsekunde startet. Kein Klick, kein Hinsehen, keine Meldung — sobald eine angemeldete Administratorin irgendeine Seite im Adminbereich öffnete, lief der Code in ihrem Browser, mit ihren Rechten und ihrer aktiven Sitzung.

Warum das ein «Supply-Chain-Angriff» ist

Der klassische Angriff auf eine Website ist ein Einbruch: Jemand findet ein offenes Fenster — ein schwaches Passwort, eine ungepatchte Lücke — und steigt ein. Dagegen hilft, was jeder kennt: Fenster schliessen, Updates einspielen, gute Schlösser.

Ein Supply-Chain-Angriff funktioniert anders. Hier bricht niemand bei Ihnen ein. Stattdessen wird ein Zulieferer manipuliert — und Sie holen die Ware freiwillig ins Haus, weil Sie ihm vertrauen. Ein Gastronomiebetrieb kann seine Küche noch so sauber führen: Wenn der Lieferant verdorbene Ware bringt, nützt die Hygiene in der Küche nichts. Der Fehler steckt nicht im Betrieb, sondern in der Lieferkette.

Auf die Website übertragen: Ihr WordPress war aktuell, Ihre Plugins waren aktuell, Ihre Passwörter waren gut. Es half nichts. Der Lieferant hat vergiftete Ware geliefert, und Ihre Website hat sie pflichtbewusst abgeholt — sie ist ja darauf ausgelegt, diesen Feed regelmässig zu laden.

Was diesen Fall besonders macht: Es wurde nicht einmal ein Plugin verändert. Bei früheren Supply-Chain-Angriffen schleusten Täter Schadcode in ein Update ein — dann half wenigstens noch, das Update nicht einzuspielen oder die Dateien zu vergleichen. Hier blieb auf der Festplatte alles unverändert. Ein Prüfwerkzeug, das Dateien mit dem Original abgleicht, hätte auf einer befallenen Website «keine Auffälligkeiten» gemeldet.

Was der Schadcode auf befallenen Seiten tat

Der eingeschleuste Einzeiler war nur der Zünder. Er lud ein grösseres Skript von einem fremden Server nach, das dann in vier Schritten vorging — jeder davon nutzt aus, dass er bereits in einer angemeldeten Administrator-Sitzung läuft und deshalb alles darf, was die Person selbst dürfte.

Anfrage beim Steuerserver. Das Skript meldet die Adresse der Website an den Server der Angreifer und fragt, ob diese Seite überhaupt bearbeitet werden soll. Kommt «überspringen» oder «erledigt» zurück, bricht es ab — das reduziert Spuren und Doppelarbeit.
Ein zusätzliches Administratorkonto. Über die REST-Schnittstelle von WordPress, mit dem gültigen Sicherheitstoken der laufenden Sitzung, wird ein neues Konto mit Administratorrechten angelegt. Für WordPress sieht das aus wie eine ganz normale Handlung der angemeldeten Person.
Eine Webshell als Fake-Plugin. Das Skript lädt eine Plugin-ZIP-Datei vom fremden Server und installiert sie über das reguläre Upload-Formular — unter einem unauffälligen Namen wie wp-smart-thumbnails. Darin steckt eine Datei namens emer-run.php, die sich direkt über die Adresszeile aufrufen lässt und dem Angreifer Befehle auf dem Server erlaubt.
Zwei Hintertüren, die bleiben. Diese Webshell installiert zwei Bausteine im Verzeichnis mu-plugins. Der erste ist ein Zugang ohne Passwort: Wer eine bestimmte Adresse mit gültigem Token aufruft, ist sofort als Administrator angemeldet. Der zweite versteckt die neu angelegten Konten aus der Benutzerliste und korrigiert die angezeigte Benutzerzahl passend nach unten.

Der letzte Punkt verdient Aufmerksamkeit, weil er die naheliegendste Kontrolle aushebelt: Ein Blick in «Benutzer» im Adminbereich zeigt auf einer so präparierten Website nichts Auffälliges. Die Konten sind da, sie sind nur unsichtbar gemacht. Wordfence fand ausserdem, dass die abgelegten Hintertür-Dateien auf September 2025 zurückdatiert waren — damit fallen sie nicht auf, wenn jemand nach kürzlich geänderten Dateien sucht.

Ein zweites, einfacheres Schadskript ging anders vor: Es berechnete Benutzername und Passwort direkt aus der Adresse der Website. Für die Angreifer bedeutet das, dass sie gar keine Liste befallener Seiten führen müssen — sie können die Zugangsdaten jederzeit neu ausrechnen. Für die Verteidigung ist das ein Glücksfall: Auch wir können sie ausrechnen und gezielt danach suchen. Die Konten dieser Variante beginnen mit bd_ und tragen eine E-Mail-Adresse auf @wordpress.org.

Die sieben Plugins — und ihr Stand heute

Betroffen sind alle Plugins von BdThemes, die den Werbebanner-Baustein enthielten. Sechs davon sind Erweiterungen für den Seitenbaukasten Elementor; nur Smart Admin Assistant ist es nicht. Das WordPress-Plugin-Team hat sie am 7. und 8. August aus dem offiziellen Verzeichnis genommen. Wir haben am 21. August 2026 den Status jedes einzelnen direkt bei der Schnittstelle von WordPress.org abgefragt:

Plugin	Geschlossen am	Stand 21. August 2026
Element Pack Addons for Elementor über 100’000 Installationen	8. August	weiterhin geschlossen
Prime Slider Addons for Elementor	7. August	weiterhin geschlossen
Pixel Gallery Addons for Elementor	7. August	weiterhin geschlossen
Ultimate Post Kit Addons for Elementor	7. August	weiterhin geschlossen
Ultimate Store Kit	7. August	weiterhin geschlossen
Smart Admin Assistant	7. August	weiterhin geschlossen
Live Copy Paste for Elementor rund 6’000 Installationen	7. August	wieder verfügbar, Version 1.5.9

Eigene Abfrage der WordPress.org-Plugin-Schnittstelle am 21. August 2026. Sechs der sieben Plugins waren zwei Wochen nach dem Vorfall weiterhin nicht im Verzeichnis.

Ein geschlossenes Plugin verschwindet nicht von Ihrer Website. Es bekommt nur keine Updates mehr und ist nicht mehr installierbar. Wer eines dieser Plugins einsetzt, sitzt also derzeit auf einer Erweiterung ohne Update-Weg — und das ist der unangenehmste Teil der Lage.

Aufschlussreich ist das Änderungsprotokoll des einen Plugins, das zurück ist. Es liest sich wie ein Rückzug in Etappen: Am 3. März 2026 wurde der Werbebanner-Baustein eingebaut. Am 8. August, einen Tag nach der Entdeckung, kam der Vermerk, dass Daten aus der Werbe-Schnittstelle als Skript in den Adminbereich gelangen konnten. Am 10. August wurde der Baustein ganz entfernt. Am 18. August folgte das Dashboard-Widget mit «allen zugehörigen externen Anfragen». Der Hersteller hat die Funktion also nicht repariert, sondern ausgebaut — nach gut fünf Monaten im Bestand.

Selbst prüfen: fünf Kontrollen

Setzen Sie keines der sieben Plugins ein, sind Sie von diesem Vorfall nicht betroffen — Punkt eins klärt das. Setzen Sie eines ein, gehen Sie alle fünf Punkte durch, auch wenn die Website unauffällig wirkt. Genau darauf ist der Angriff ausgelegt.

Plugin-Liste durchgehen. «Plugins → Installierte Plugins». Suchen Sie nach den sieben Namen aus der Tabelle oben. Auch deaktivierte zählen — der Baustein lief beim aktiven Plugin, aber die Aufräumarbeit betrifft beide.
Benutzerkonten prüfen, und zwar nicht nur im Adminbereich. Achten Sie auf Konten, die mit bd_ beginnen, und auf E-Mail-Adressen mit @wordpress.org oder @developer.wordpress.org. Weil die Schadsoftware Konten aus der Liste ausblenden kann, ist der Blick in die Datenbank oder über die Kommandozeile zuverlässiger als die Benutzerübersicht.
In das Verzeichnis mu-plugins schauen. Es liegt unter wp-content/mu-plugins und ist im Adminbereich nicht vollständig sichtbar. Dateien, die Sie oder Ihre Agentur nicht dort abgelegt haben, gehören geprüft — im dokumentierten Fall hiessen sie unter anderem class-wp-token-validate.php, wp-cache-optimizer.php und class-wp-query- mit angehängter Zeichenfolge.
Nach der Webshell suchen. Gesucht ist eine Datei namens emer-run.php irgendwo unter wp-content, häufig in einem Plugin mit unauffälligem Namen wie wp-smart-thumbnails. Ein Plugin, das Sie nie installiert haben, ist immer ein Fund.
Zwei Einträge in der Datenbank. Der Angriff hinterlässt in der Optionen-Tabelle die Einträge fz_emer_login_tokens und fz_emer_done_v1. Existiert einer von beiden, ist die Website befallen.

Aus der Werkstatt: Wir haben unsere eigenen Seiten geprüft

Am 21. August haben wir die fünf WordPress-Installationen auf unserem eigenen Hosting durchgeprüft — auf BdThemes-Plugins, auf die vier Hintertür-Dateien, auf Konten mit bd_-Präfix und auf die beiden Datenbankeinträge. Ergebnis: nichts. Keine der Seiten setzt eines der Plugins ein, keine setzt überhaupt Elementor ein.

Ein Nicht-Fund ist allerdings nur so viel wert wie die Prüfung, die ihn erzeugt hat. Deshalb haben wir gegengeprüft: Wir haben in einem Container testweise zwei Dateien mit den gesuchten Namen angelegt und die Suche erneut laufen lassen. Sie meldete beide. Erst damit war klar, dass das Nichts ein echtes Nichts ist und kein stillschweigend fehlgeschlagener Befehl.

Dabei ist uns ein Fehler unterlaufen, der es wert ist, weitererzählt zu werden. Für die Datenbankprüfung hatten wir zuerst die Abfrage benutzt, die in fast jeder Anleitung zu diesem Vorfall steht — sinngemäss «suche in der Tabelle wp_options nach diesen beiden Einträgen». Die Abfrage lief durch und meldete auf allen fünf Seiten: nichts gefunden. Beruhigend, aber wertlos. Denn drei der fünf Seiten benutzen gar keine Tabelle namens wp_options: Ihr Tabellenpräfix lautet seo_ beziehungsweise wpcg_, weil ein abweichendes Präfix seit Jahren zur Grundhärtung gehört. Die Abfrage hat dort nicht «nichts gefunden» — sie hat am falschen Ort gesucht und dafür eine Entwarnung ausgegeben.

Wir haben die Prüfung daraufhin auf einen Befehl umgestellt, der das Präfix selbst ermittelt, und zur Kontrolle jedes Mal zusätzlich einen Eintrag abgefragt, den es garantiert gibt. Erst wenn der antwortet, ist das Schweigen bei den beiden gesuchten Einträgen eine Aussage. Wenn Sie diese Kontrolle selbst oder von Ihrer Agentur durchführen lassen: Fragen Sie nach, ob das Tabellenpräfix berücksichtigt wurde. Eine Härtungsmassnahme, die man vergisst, wird zur Blindstelle.

Wenn Sie fündig werden

Dann ist die Website kompromittiert, und das Entfernen der gefundenen Datei genügt nicht. Wer Administratorrechte und eine Webshell hatte, kann weitere Zugänge gelegt haben, die keine der bekannten Kennungen tragen. Das Vorgehen entspricht dem, was wir nach der wp2shell-Welle im Juli beschrieben haben: Zugänge sperren, alle Passwörter und Schlüssel erneuern, Sitzungen beenden, den Bestand gegen eine saubere Quelle abgleichen — und im Zweifel neu aufsetzen statt reparieren. Der ausführliche Ablauf steht in unserem Beitrag WordPress gehackt — was jetzt zu tun ist.

Ein Punkt, der in der internationalen Berichterstattung fehlt und für Schweizer Betriebe wichtig ist: Wenn dabei Personendaten betroffen sind — Kundenkonten, Formulareingänge, Bestellungen in einem Shop —, greift möglicherweise Artikel 24 des Datenschutzgesetzes. Er verlangt, dass die verantwortliche Stelle dem EDÖB eine Verletzung der Datensicherheit «so rasch als möglich» meldet, sofern sie voraussichtlich zu einem hohen Risiko für die betroffenen Personen führt. Anders als die DSGVO nennt das DSG dafür keine 72-Stunden-Frist. Nicht zu verwechseln ist das mit der Meldepflicht ans Bundesamt für Cybersicherheit: Die gilt seit April 2025 für Betreiber kritischer Infrastrukturen, nicht für die gewöhnliche KMU-Website.

Der dritte Fall in zwei Monaten

Der BdThemes-Vorfall ist kein Einzelfall, sondern der jüngste von drei ähnlich gelagerten Angriffen innert weniger Wochen. Wordfence ordnet den Steuerserver denselben Tätern zu, die schon hinter zwei früheren Fällen standen:

Fall	Was manipuliert wurde	Reichweite
OptinMonster Juni 2026	JavaScript-Dateien im Content-Delivery-Netz des Herstellers — der Zugangsschlüssel dafür lag auf einem Marketing-Server, den die Täter über eine bekannte Lücke im Plugin UpdraftPlus erreichten	über 1,2 Millionen Websites erreichbar; betroffen waren auch TrustPulse und PushEngage
Advanced Responsive Video Embedder Juli 2026	Schadcode direkt im Plugin-Quellcode (Version 10.8.7): ein Aufruf mit dem richtigen Wert meldete den Angreifer als bestehenden Administrator an	rund 20’000 Installationen; als CVE-2026-18072 mit CVSS 9.8 geführt
BdThemes August 2026	ein Werbebanner-Feed auf dem Cloud-Speicher des Herstellers — kein Quellcode berührt	sieben Plugins, grösstes davon mit über 100’000 Installationen

Drei Wege zum selben Ziel: Nicht die Website wird angegriffen, sondern der Weg, auf dem sie beliefert wird.

Die Reihenfolge zeigt eine Entwicklung. Beim ARVE-Plugin lag der Schadcode noch im Quellcode — auffindbar, vergleichbar, und tatsächlich von einem automatischen System innerhalb von zwei Stunden entdeckt. Bei OptinMonster lag er in ausgelieferten Skriptdateien. Bei BdThemes liegt er in Daten. Mit jedem Schritt rückt der Schadcode weiter weg von dem, was Prüfwerkzeuge überhaupt anschauen.

Das Muster in allen drei Fällen ist dasselbe: Das Skript wird nur aktiv, wenn eine angemeldete Administratorin im Adminbereich unterwegs ist, es legt ein zusätzliches Administratorkonto an, und es installiert ein Plugin, das sich selbst versteckt. Für Besucherinnen und Besucher der Website ist nichts zu sehen. Das ist kein Zufall, sondern der wirtschaftlichste Weg zu dauerhaftem Zugriff.

Was Updates nicht leisten

Die verbreitete Vorstellung von Website-Sicherheit lautet: aktuell halten, dann passiert nichts. Das ist nicht falsch — die meisten erfolgreichen Angriffe laufen nach wie vor über längst geschlossene Lücken. Aber es beschreibt nur einen Teil.

Gegen den BdThemes-Angriff hätte Aktualität nichts ausgerichtet. Wer die Plugins am 1. August auf dem neuesten Stand hatte, war ab dem 1. August auf dem neuesten Stand — und trotzdem exponiert, weil die Gefahr nicht im Plugin steckte, sondern in dem, was das Plugin lud. Die ehrliche Formulierung lautet deshalb nicht «Updates schützen nicht mehr», sondern: Updates schützen gegen bekannte Lücken in Ihrer Installation. Sie sagen nichts darüber, was Ihre Installation von aussen nachlädt.

Daraus folgen drei Fragen, die über «ist alles aktuell?» hinausgehen und die sich jede Betreiberin stellen kann:

Was lädt meine Website von fremden Servern nach — und muss sie das? Dashboard-Werbebanner, Neuigkeiten-Widgets und Angebotshinweise im Adminbereich sind für Sie ohne Nutzen. Sie waren in diesem Fall der Einfallsweg. BdThemes hat sie am Ende selbst ausgebaut.
Würde ich es überhaupt merken? Ein neues Administratorkonto, eine neue Datei in mu-plugins, ein Plugin, das niemand installiert hat: Solche Veränderungen sind erkennbar — aber nur, wenn jemand oder etwas hinschaut. Die Benutzerübersicht im Adminbereich allein reicht nicht, wie dieser Fall zeigt.
Wie viele Erweiterungen brauche ich wirklich? Jedes Plugin ist ein Zulieferer mit eigener Infrastruktur, eigenen Zugangsdaten und eigener Sorgfalt. Sechs der sieben betroffenen Plugins sind Erweiterungen für Elementor — Zubehör, das es ohne den Baukasten nicht bräuchte. Wer mit den Bordmitteln von WordPress auskommt, hat schlicht weniger Lieferanten. Wir haben das in Block-Themes statt Page-Builder ausführlicher aufgeschrieben.

Eine Anmerkung zu Sicherheits-Plugins, weil sie in diesem Zusammenhang oft als Antwort genannt werden: Wordfence hat die Erkennungsregeln für diesen Angriff am 7. August ausgeliefert — an zahlende Kundinnen und Kunden. Die kostenlose Version erhält dieselben Regeln nach der üblichen Verzögerung von 30 Tagen, also um den 6. September. Das ist keine Kritik am Geschäftsmodell, sondern eine Tatsache, die man kennen sollte, wenn die kostenlose Version die einzige Sicherheitsmassnahme ist: In den vier Wochen, in denen ein Angriff läuft, schaut sie an dieser Stelle nicht hin.

Technisch abriegeln: was eine Content-Security-Policy leistet

Es gibt tatsächlich einen Mechanismus, der genau an dieser Stelle ansetzt: die Content-Security-Policy, kurz CSP. Das ist eine Liste, die Ihr Server jeder Seite mitgibt und die dem Browser sagt, von welchen Adressen er Programmcode ausführen darf und wohin er Daten schicken darf. Alles, was nicht auf der Liste steht, verweigert der Browser — unabhängig davon, wie die Anweisung in die Seite gelangt ist. Genau das ist der Punkt: Die CSP fragt nicht, ob der Code aus einem vertrauenswürdigen Plugin stammt. Sie fragt nur, ob das Ziel erlaubt ist.

Der BdThemes-Angriff lief vollständig im Browser ab und berührt dabei vier Stellen, an denen eine CSP eingreift:

Der Zünder war ein Ereignis-Attribut direkt im Seitenquelltext (onanimationstart). Eine CSP, die nur Code aus richtigen Skriptdateien zulässt, führt so etwas gar nicht erst aus.
Der Zünder baute den eigentlichen Befehl zur Laufzeit aus Zeichencodes zusammen und führte ihn aus. Diese Technik lässt sich per CSP gezielt verbieten.
Das Hauptskript kam von einer fremden Domain. Steht sie nicht auf der Liste, lädt der Browser sie nicht.
Das Ergebnis ging per Funkfeuer an den Steuerserver zurück. Die Regel für ausgehende Verbindungen — connect-src — deckt auch diesen Weg ab, zusammen mit allen übrigen Wegen, auf denen eine Seite Daten nachlädt oder abschickt.

Die ersten beiden Punkte lassen sich im Adminbereich von WordPress heute allerdings nicht durchsetzen. Im Ticketsystem des WordPress-Projekts liegt dazu Ticket #59446. Es hält fest, dass die strenge Variante bewusst auf öffentliche Seiten und die Anmeldemaske beschränkt wurde — «wegen der schieren Menge an Inline-Skripten, die im wp-admin ausgegeben werden». Dazu kommen die dynamisch erzeugten Skript-Tags des Block-Editors. Das Ticket ist seit drei Jahren offen und auf «Future Release» gesetzt, also ohne Termin. Auch das Referenz-Plugin dazu schreibt ausdrücklich, die Richtlinie lasse sich «noch nicht auf das WP-Admin anwenden». Und dieser Angriff lief genau dort.

Der vierte Punkt ist dagegen erreichbar — und er hätte gereicht. Die Regel für ausgehende Verbindungen lässt sich unabhängig davon verschärfen, ob der Editor Inline-Skripte braucht. Wer dort die konkret benötigten Adressen aufzählt, statt pauschal «alles, was verschlüsselt erreichbar ist» zu erlauben, unterbricht die Kette an zwei Stellen gleichzeitig: Das Hauptskript kann nicht geladen werden, und das Ergebnis kann nicht zurückgemeldet werden. Der Adminbereich funktioniert dabei unverändert weiter.

Wir haben unsere eigene Website daraufhin geprüft: wp-profis.com liefert seit Längerem eine CSP aus — und sie hätte diesen Angriff nicht gestoppt. Die Regel für Skripte enthält die beiden Ausnahmen, die der Block-Editor braucht, und die Regel für ausgehende Verbindungen endet auf einem pauschalen «alles Verschlüsselte». Damit wären der Abruf des Schadskripts und die Rückmeldung an den Steuerserver beide durchgegangen. Eine CSP zu haben und die richtige CSP zu haben, sind zwei verschiedene Dinge — das gilt für uns wie für alle anderen.

Wer das angehen will, führt eine CSP nicht per Schalter ein. Es gibt einen Meldemodus, in dem der Browser Verstösse nur meldet, ohne etwas zu blockieren. Damit findet man erst heraus, was die eigene Website tatsächlich alles nachlädt — und schaltet danach scharf. Ohne diesen Zwischenschritt legt eine zu enge Regel zuverlässig irgendein Formular, eine Schriftart oder eine Kartenansicht lahm. Das ist Arbeit für jemanden, der die Website ohnehin betreut — aber es ist die wirksamste Antwort auf die erste der drei Fragen von oben.

Häufige Fragen

Ich benutze Elementor, aber keines der sieben Plugins. Bin ich betroffen?

Nein. Der Angriff betrifft ausschliesslich Plugins des Herstellers BdThemes, die den Werbebanner-Baustein enthielten. Elementor selbst ist nicht betroffen, und die Erweiterungen anderer Hersteller sind es ebenfalls nicht. Der Fall ist trotzdem ein Anlass, die eigene Plugin-Liste einmal daraufhin durchzusehen, welche Erweiterungen tatsächlich gebraucht werden.

Wie viele Websites wurden tatsächlich übernommen?

Das ist nicht bekannt. Weder Wordfence noch BdThemes haben eine Zahl veröffentlicht, und bis zum Redaktionsschluss lag von BdThemes überhaupt keine öffentliche Stellungnahme vor. Kursierende Zahlen wie «100’000 betroffene Websites» stammen aus den Installationszahlen des grössten betroffenen Plugins und sagen nichts darüber aus, wie viele Seiten tatsächlich Schadcode ausgeführt haben. Betroffen war eine Seite nur, wenn sich in der fraglichen Zeit auch jemand mit Administratorrechten eingeloggt hat.

Seit wann lief der Angriff?

Der Fehler im Programmcode wurde am 1. März 2026 eingebaut. Das früheste Datum, an dem er über den vergifteten Feed ausnutzbar gewesen sein kann, ist laut den Zeitstempeln in den manipulierten Daten der 23. Juni 2026. Beobachtet und gemeldet wurde der laufende Angriff am 7. August, tags darauf lieferten die Schnittstellen wieder saubere Daten. Das Zeitfenster für einen Befall liegt also zwischen wenigen Tagen und rund sechs Wochen.

Ich habe eines der Plugins. Soll ich es jetzt löschen?

Deaktivieren Sie es und prüfen Sie die Website nach den fünf Punkten oben — in dieser Reihenfolge, denn eine Deinstallation kann Spuren beseitigen, die Sie für die Beurteilung noch brauchen. Ist die Website sauber, ist die Entscheidung eine geschäftliche: Ein Plugin ohne Update-Weg sollte nicht dauerhaft im Bestand bleiben. Da die Erweiterungen meist das Layout tragen, braucht der Ersatz Vorbereitung — planen Sie ihn, statt das Plugin spontan zu löschen.

Ich habe die Pro-Version gekauft, nicht die kostenlose. Ändert das etwas?

Für die Schliessung im Verzeichnis ja, für den Angriff nicht. Betroffen war der Werbebanner-Baustein, und der steckt in den Plugins unabhängig davon, über welchen Weg sie bezogen wurden. Die kostenpflichtigen Versionen laufen ohnehin nicht über das WordPress-Verzeichnis, sondern über den Hersteller — dieselbe Infrastruktur, die kompromittiert wurde. Prüfen Sie in jedem Fall.

Schützt ein Sicherheits-Plugin vor so etwas?

Teilweise. Eine Firewall kann den Nachladeversuch blockieren und ein Scanner die abgelegten Dateien finden — beides aber erst, wenn er die passenden Erkennungsmerkmale hat. Die gab es hier ab dem 7. August, in den kostenlosen Versionen 30 Tage später. Was ein Sicherheits-Plugin grundsätzlich nicht leisten kann: verhindern, dass ein Hersteller, dem Sie vertrauen, kompromittiert wird. Dagegen hilft, die Zahl der Zulieferer klein zu halten, regelmässig hinzuschauen — und dem Browser vorzugeben, wohin er überhaupt Daten schicken darf. Zum letzten Punkt steht oben ein eigener Abschnitt.

Fazit

Der BdThemes-Fall ist unangenehm, weil er eine bequeme Annahme aufhebt: dass eine gepflegte Website eine sichere Website ist. Gepflegt war hier vieles — und der Weg führte trotzdem hinein, über einen Werbebanner, den niemand je gebraucht hat.

Die Konsequenz daraus ist trotzdem kein Alarm, sondern etwas Nüchternes: Jedes Plugin ist ein Zulieferer, dem Sie Adminrechte auf Ihrer Website einräumen. Wer weniger Zulieferer hat, hat weniger Wege ins Haus. Und wer regelmässig hinschaut — Benutzerliste, mu-plugins, Plugin-Bestand —, merkt es, wenn einer davon etwas mitgebracht hat. Drei Vorfälle in zwei Monaten sagen, dass sich das Hinschauen künftig häufiger lohnt.

Wenn Sie eines der sieben Plugins einsetzen und bei den fünf Kontrollen nicht weiterkommen: Melden Sie sich. Wir schauen die Punkte mit Ihnen durch und sagen Ihnen, woran Sie sind — und was danach zu tun ist. Wer diese Taktzahl grundsätzlich nicht selbst halten möchte, findet den geordneten Weg unter WordPress Support & Wartung und Security & Härtung.

Quellen

Wordfence: Supply Chain Compromise in BdThemes Ecosystem via Poisoned API Response ↗ — die technische Untersuchung mit Zeitleiste, Angriffskette und allen Kompromittierungsmerkmalen
BleepingComputer: BdThemes plugins supply-chain hack creates rogue WordPress admins ↗ — Einordnung vom 10. August 2026
The Hacker News: BdThemes Supply Chain Attack Poisons JSON to Create Rogue WordPress Admins ↗ — Bericht vom 11. August 2026
WordPress.org: Element Pack Lite ↗ — Verzeichniseintrag; Status und Änderungsprotokolle der sieben Plugins am 21. August 2026 über die Plugin-Schnittstelle abgefragt
Sansec: OptinMonster supply chain attack hits 1.2 million sites ↗ — der Vorfall vom Juni 2026
GitHub Advisory: CVE-2026-18072 ↗ — die Hintertür im Plugin Advanced Responsive Video Embedder, Juli 2026
Fedlex: Datenschutzgesetz, SR 235.1 ↗ — Artikel 24, Meldung von Verletzungen der Datensicherheit
WordPress Trac #59446 ↗ — warum die strenge Content-Security-Policy den Adminbereich bisher aussenlässt; Meilenstein «Future Release»
Plugin «Strict CSP» ↗ — Referenz-Umsetzung für öffentliche Seiten und Anmeldemaske, ausdrücklich nicht für das WP-Admin
MDN: connect-src ↗ — welche Wege die Regel für ausgehende Verbindungen abdeckt, einschliesslich sendBeacon

Stand: 21. August 2026. Der Status der Plugins im WordPress-Verzeichnis kann sich ändern; die Angaben dazu stammen aus einer eigenen Abfrage an diesem Tag. Sollte BdThemes eine Stellungnahme veröffentlichen oder eine Opferzahl bekannt werden, ergänzen wir diesen Beitrag.