Wenn ein WordPress Plugin gehackt wurde, ohne dass sich eine einzige Datei auf deinem Server verändert hat, hilft dir kein Update und kein Dateiscan. Genau das ist im August 2026 bei sieben Elementor-Erweiterungen des Anbieters BdThemes passiert. Die Angreifer haben nicht den Plugin-Code manipuliert, sondern eine Werbe-Schnittstelle, die diese Plugins im WordPress-Backend abrufen. Ergebnis: versteckte Administratorkonten und Hintertüren auf Seiten, deren Betreiber alles brav aktuell gehalten hatten. Hier steht, welche Plugins betroffen sind, woran du einen Befall erkennst und was du heute noch prüfen solltest.
Letzte Aktualisierung: August 2026
Was genau passiert ist: WordPress Plugin gehackt ohne Dateiänderung
BdThemes ist kein Nischenanbieter. Die Firma baut Erweiterungen für den Seitenbaukasten Elementor, also für genau die Technik, mit der sehr viele Handwerks- und Dienstleisterseiten in Deutschland zusammengesetzt sind. Element Pack Addons for Elementor allein läuft auf über 100.000 Seiten.
Das BdThemes-Portfolio kommt nach Angaben des Anbieters auf über 350.000 aktive Installationen, Element Pack Addons for Elementor allein auf mehr als 100.000. Quelle: WordPress.org Plugin-Verzeichnis und BdThemes, 2026
Diese Plugins zeigen im WordPress-Backend kleine Werbebanner an, etwa Hinweise auf neue Funktionen oder Rabattaktionen. Dafür holen sie sich Daten von einem Server des Herstellers. Ein Bestandteil namens Biggopti verarbeitet diese Antwort und baut sie in die Backend-Oberfläche ein.
Seit dem 1. März 2026 steckte in diesem Bestandteil ein Fehler: ein Feld aus der Server-Antwort wurde ungeprüft in ein HTML-Attribut geschrieben. Für sich genommen war das monatelang harmlos, weil die Antwort ja vom Hersteller kam. Dann verschafften sich Angreifer Schreibzugriff auf den Speicher hinter dieser Schnittstelle und tauschten den Inhalt aus.
Ab diesem Moment lieferte eine vertrauenswürdige Adresse Schadcode aus. Sobald sich jemand mit Administratorrechten ins Backend einloggte, lief dieser Code im Browser des Admins und damit mit dessen vollen Rechten.
Was ist ein Supply-Chain-Angriff?
Ein Supply-Chain-Angriff ist ein Angriff, der nicht die Zielseite selbst trifft, sondern einen Zulieferer, dem diese Seite vertraut. Das kann ein Plugin-Hersteller sein, ein Update-Server oder eben eine Schnittstelle, die im Hintergrund Daten nachlädt. Der Angreifer muss deine Webseite gar nicht knacken, er muss nur jemanden knacken, dem deine Webseite automatisch glaubt.
Das ist der Grund, warum die üblichen Sicherheitsreflexe hier ins Leere laufen. Es gab kein verdächtiges Update, das man hätte vermeiden können. Die Plugin-Dateien auf dem Server waren zu jedem Zeitpunkt exakt die, die auch im offiziellen Verzeichnis lagen.
Diese sieben Plugins sind betroffen
Ob bei dir ein WordPress Plugin gehackt wurde, hängt an einer einzigen Frage: Läuft eine dieser sieben Erweiterungen auf deiner Seite? Das WordPress-Team hat alle sieben am 7. und 8. August 2026 aus dem offiziellen Plugin-Verzeichnis genommen, bis die Prüfung abgeschlossen ist. Sie sind derzeit nicht herunterladbar.
Plugin | Typische Nutzung |
|---|---|
Element Pack Addons for Elementor | Zusatzelemente für den Seitenbau, über 100.000 Installationen |
Prime Slider Addons for Elementor | Slider und Hero-Bereiche auf Startseiten |
Ultimate Post Kit Addons for Elementor | Blog- und Artikellisten |
Ultimate Store Kit | Shop-Darstellung bei WooCommerce |
Pixel Gallery Addons for Elementor | Bildergalerien, oft für Referenzen |
Live Copy Paste for Elementor | Bausteine zwischen Seiten kopieren |
Smart Admin Assistant | Backend-Hilfsfunktionen |
Wenn du keines dieser Plugins installiert hast, bist du von diesem Vorfall nicht betroffen. Prüfe das aber wirklich nach, statt es zu vermuten. Viele Betriebe wissen gar nicht, welche Elementor-Erweiterungen ihre Agentur damals eingebaut hat. Unter Plugins im WordPress-Menü steht die vollständige Liste.
Woran du erkennst, ob deine Webseite betroffen ist
Wenn ein WordPress Plugin gehackt wurde, meldet sich das selten von allein. Die Angreifer haben sich hier besonders viel Mühe gegeben, unsichtbar zu bleiben. Die angelegten Administratorkonten werden aus der Benutzerliste im Backend herausgefiltert, du siehst sie dort also nicht einfach so. Trotzdem hinterlässt die Kampagne klare Spuren.
Die Angreifer legten Administratorkonten an und installierten Hintertüren, ohne eine einzige Datei der betroffenen Plugins zu verändern. Quelle: Wordfence Threat Intelligence, Vorfall-Analyse 2026
Diese Punkte solltest du prüfen lassen, wenn eines der sieben Plugins bei dir läuft oder in den vergangenen Monaten lief:
Benutzerkonten: Konten, deren Name mit bd_ beginnt, oder Konten mit einer E-Mail-Adresse auf wordpress.org. Beides gehört dort nicht hin.
Verzeichnis mu-plugins: Dateien in wp-content/mu-plugins, die niemand bewusst angelegt hat. Diese Plugins laufen immer mit und lassen sich im Backend nicht deaktivieren.
Verdächtige Dateien: Namen wie emer-run.php oder Dateien, die sich als class-wp-query tarnen.
Datenbank-Optionen: Einträge namens fz_emer_login_tokens und fz_emer_done_v1 in der Optionstabelle.
Ausgehende Verbindungen: Aufrufe an eine Domain namens ia-cdn, über die der Schadcode nachgeladen wurde.
Der frühestmögliche Angriffszeitpunkt liegt laut den Analysen beim 23. Juni 2026. Aufgefallen ist die Sache erst am 7. August, als eine Sicherheitsfirma ungewöhnliche Muster in ihrem Schutzfilter sah. Dazwischen liegen rund sechs Wochen, in denen sich niemand sicher sein kann, ob die eigene Seite in dieser Zeit angefasst wurde.
Was tun, wenn du fündig wirst?
Dann reicht es nicht, das Plugin zu löschen. Ein Angreifer, der ein Administratorkonto und eine Hintertür hinterlassen hat, kommt auch ohne das ursprüngliche Plugin wieder rein. Die Reihenfolge, die hier zählt:
Seite vom Netz nehmen oder in den Wartungsmodus schalten, damit sich nichts weiter ausbreitet.
Alle unbekannten Administratorkonten löschen, auch die versteckten.
Fremde Dateien in mu-plugins und im Plugin-Verzeichnis entfernen.
Sämtliche Passwörter ändern: WordPress, Datenbank, FTP, Hosting-Konto.
Die Sicherheitsschlüssel in der Datei wp-config.php neu erzeugen, damit alle bestehenden Sitzungen ungültig werden.
Ein sauberes Backup von vor dem 23. Juni 2026 bereithalten, falls sich der Befund nicht restlos aufräumen lässt.
Wenn dir dabei mulmig wird: das ist eine berechtigte Reaktion. Eine bereinigte Seite, bei der ein Zugang übersehen wurde, ist in zwei Wochen wieder befallen. Im Zweifel lohnt es sich, jemanden draufschauen zu lassen, der das öfter macht.
Warum die Bewertung als mittleres Risiko täuscht
Die Schwachstelle im Plugin-Code hat einen CVSS-Wert von 5.4 bekommen, also mittleres Risiko. Diese Zahl bewertet nur die technische Lücke für sich. Es braucht einen eingeloggten Administrator, damit der Code überhaupt losläuft. Und der Angreifer muss die Datenquelle kontrollieren. Beides ist eine Hürde.
Nur waren im konkreten Fall beide Hürden genommen. Die Datenquelle war übernommen, und Administratoren loggen sich nun einmal ein. Was als mittelschwere Lücke bewertet wird, endete für betroffene Seiten in einer vollständigen Übernahme. Eine Kennzahl ersetzt hier keine Prüfung.
Das ist ein Muster, das ich in diesem Jahr öfter gesehen habe. Bei der WordPress-Kernlücke, über die ich in meinem Artikel zur Sicherheitslücke wp2shell geschrieben habe, war die Bewertung eindeutig kritisch und die Reaktion entsprechend schnell. Hier steht eine unauffällige Zahl über einem Vorfall, der real Seiten gekostet hat. Wer nur auf Schweregrade schaut, sortiert falsch.
Was dieser Fall über Update-Routinen sagt
Die gängige Empfehlung lautet: halte WordPress, Theme und Plugins aktuell, dann passiert dir wenig. Das stimmt weiterhin für den Großteil aller Angriffe. Dieser Vorfall zeigt aber die Grenze davon.
Hier wurde ein WordPress Plugin gehackt, das auf dem neuesten Stand war. Betroffen waren Seiten mit aktuellen Erweiterungen aus dem offiziellen Verzeichnis. Kein Nulled-Theme, keine Raubkopie, keine vergessene Erweiterung von 2019. Wer alles richtig gemacht hat, war trotzdem angreifbar. Was zusätzlich hilft:
Weniger Plugins: Jede Erweiterung ist ein zusätzlicher Zulieferer, dem deine Seite vertraut. Zwölf Elementor-Addons für drei Effekte sind ein Risiko, kein Komfort.
Getrennte Administratorkonten: Nicht jeder, der Texte pflegt, braucht Administratorrechte. Ein Redakteurskonto hätte diesen Angriff nicht ausgelöst.
Regelmäßige Benutzerprüfung: Einmal im Monat einen Blick auf die Konten werfen dauert zwei Minuten.
Externe Backups: Ein Backup, das auf demselben Server liegt wie die befallene Seite, ist im Ernstfall wertlos.
Ein Blick ins Sicherheitsprotokoll: Wer merkt, dass sich um drei Uhr nachts jemand eingeloggt hat, gewinnt Wochen.
Ausführlicher habe ich diese Punkte in der Übersicht zu den wichtigsten WordPress-Schutzmaßnahmen beschrieben. Die aktuellen Untersuchungsergebnisse zu diesem Vorfall veröffentlicht Wordfence Threat Intelligence laufend.
Was das für einen normalen Betrieb bedeutet
Ein Malerbetrieb mit einer Elementor-Seite hat keine IT-Abteilung, die Sicherheitsmeldungen liest. In der Praxis läuft es meistens so: Die Seite wurde vor drei Jahren gebaut und tut seitdem ihren Dienst. Ins Backend schaut niemand, außer wenn ein neues Referenzbild hochgeladen wird.
Genau diese Seiten sind bei so einem Vorfall am längsten betroffen. Nicht weil sie besonders interessant wären, sondern weil niemand hinschaut. Der Schaden zeigt sich dann Wochen später. Google markiert die Seite als unsicher, Kunden bekommen eine Warnung im Browser, der Hoster sperrt das Postfach wegen Spamversands.
Der wirtschaftliche Schaden ist selten der Hack selbst. Er entsteht dadurch, dass eine Woche lang niemand anrufen kann, weil das Kontaktformular tot ist, und dass die mühsam aufgebauten Google-Positionen einbrechen. Wer davon lebt, dass Anfragen über die eigene Seite reinkommen, verliert damit direkt Umsatz.
Deshalb rate ich Betrieben, für die die Webseite ein Vertriebskanal ist, zu einer festen Zuständigkeit. Entweder jemand im Betrieb hat den Hut auf und schaut monatlich rein, oder das läuft über eine Wartung mit klarem Umfang. Was nicht funktioniert: dass sich alle darauf verlassen, dass schon jemand anderes hinschaut.
Der Punkt, den fast alle übersehen: die Meldepflicht
Wenn ein Angreifer Administratorrechte auf deiner Webseite hatte, hatte er auch Zugriff auf alles, was dort an Daten liegt. Bei einer typischen Betriebsseite sind das Kontaktformular-Einträge, Newsletter-Adressen, bei einem Shop zusätzlich Bestell- und Rechnungsdaten. Das macht aus einem technischen Vorfall einen rechtlichen.
Artikel 33 der DSGVO verlangt eine Meldung an die zuständige Aufsichtsbehörde, wenn personenbezogene Daten betroffen sind. Dafür hast du 72 Stunden ab dem Moment, in dem dir der Vorfall bekannt wird. Die Frist beginnt mit der Kenntnis, nicht mit dem Angriff. Eine Ausnahme gibt es, wenn ein Risiko für die Betroffenen unwahrscheinlich ist. Diese Einschätzung musst du aber begründen und dokumentieren können.
Praktisch heißt das: Notiere bei einem Befund sofort Datum und Uhrzeit der Feststellung. Dazu, was du gefunden hast und welche Daten auf der Seite liegen. Diese Notiz ist später deine Grundlage, egal ob du meldest oder begründet darauf verzichtest.
Ich sehe oft, dass Betriebe die Seite in aller Eile säubern und dabei genau die Spuren löschen, die sie für diese Bewertung gebraucht hätten. Sicher dir vor dem Aufräumen ein vollständiges Abbild des befallenen Stands, inklusive Datenbank. Das kostet zehn Minuten und kann dir eine unangenehme Diskussion mit der Aufsichtsbehörde ersparen.
Häufige Fragen zu gehackten WordPress Plugins
Reicht es, das betroffene Plugin einfach zu löschen?
Nein. Wenn der Angriff auf deiner Seite erfolgreich war, existieren zusätzliche Administratorkonten und Hintertüren, die unabhängig vom Plugin funktionieren. Das Löschen entfernt nur den ursprünglichen Weg hinein, nicht den Zugang, den sich der Angreifer danach gebaut hat.
Wie erkenne ich, ob mein WordPress Plugin gehackt wurde?
Prüfe die Benutzerliste auf unbekannte Administratorkonten, das Verzeichnis wp-content/mu-plugins auf fremde Dateien und die Optionstabelle auf Einträge mit dem Kürzel fz_emer. Ein Sicherheits-Plugin mit Dateiprüfung findet die Webshells zusätzlich.
Sind auch Seiten ohne Elementor betroffen?
Bei diesem konkreten Vorfall nur, wenn eines der sieben BdThemes-Plugins installiert war. Sechs davon setzen Elementor voraus, Smart Admin Assistant nicht. Ohne diese Plugins bist du hier außen vor.
Gibt es inzwischen ein Update, das die Lücke schließt?
Zum Zeitpunkt der Veröffentlichung dieses Artikels sind die sieben Plugins aus dem offiziellen Verzeichnis genommen und werden geprüft. Ein Sicherheitsupdate stand noch aus. Deaktivieren ist bis dahin die sichere Entscheidung.
Kann mein Hoster den Angriff bemerken?
Manchmal. Viele Hoster schlagen erst an, wenn die Seite auffällig wird, etwa durch Spamversand oder ungewöhnliche Last. Auf diese Erkennung solltest du dich nicht verlassen, sie kommt in der Regel zu spät.
Fazit: Ein gehacktes WordPress Plugin merkst du nicht von allein
Der BdThemes-Vorfall ist kein Grund, Elementor oder WordPress abzuschreiben. Er zeigt aber, dass die Frage nicht mehr nur lautet, ob deine Software aktuell ist, sondern wem deine Webseite im Hintergrund automatisch vertraut. Ein WordPress Plugin gehackt zu bekommen, ohne dass sich eine Datei ändert, war vor ein paar Jahren noch eine Ausnahme.
Konkret für heute: Schau nach, ob eines der sieben Plugins bei dir läuft. Falls ja, deaktiviere es und geh die Prüfliste oben durch. Falls nein, nimm den Fall als Anlass, einmal deine Benutzerliste anzusehen und zu klären, wer sich bei dir eigentlich um solche Meldungen kümmert.
Wenn du nicht sicher bist, was auf deiner Seite installiert ist oder ob sie sauber ist, schau einmal mit mir gemeinsam drauf. Im kostenlosen Erstgespräch gehen wir deine Seite durch und du weißt danach, wo du stehst. Unverbindlich, ohne Verkaufsdruck.
