Brevo Supply-Chain-Angriff konnte versteckte Backdoor auf WordPress-Websites installieren

Brevo Supply-Chain-Angriff: Ein Sicherheitsvorfall in der Brevo-Infrastruktur führte am 14. September 2026 dazu, dass schädliches JavaScript über Brevo-Scripts ausgeliefert wurde, die auf externen Websites eingebunden waren.

Brevo bestätigte, dass Angreifer einen Cloudflare-API-Key erbeuteten und damit einen schädlichen Cloudflare Worker erstellten. Dieser konnte Inhalte am CDN-Rand manipulieren, bevor sie an Besucher ausgeliefert wurden.

Für WordPress-Administratoren ist der Angriff besonders relevant. Erkannte das schädliche JavaScript einen Besucher, der als WordPress Administrator angemeldet war, versuchte es unbemerkt ein schädliches WordPress-Plugin zu installieren und zu aktivieren.

Andere ausgewählte Besucher konnten stattdessen eine gefälschte Cloudflare-Verifizierungsseite sehen. Über die sogenannte ClickFix-Methode sollten Windows-Benutzer dazu gebracht werden, selbst einen schädlichen Befehl auszuführen.

Sansec schätzt, dass die betroffenen Brevo-Komponenten auf mehr als 100.000 Websites verwendet wurden.

Fakten zum Brevo Supply-Chain-Angriff

• Betroffener Dienst: eingebettete Brevo-JavaScript-Komponenten und Website-Integrationen
• Betroffene Plattformen: externe Websites, darunter WordPress-Websites
• Angriffstyp: Supply-Chain-Kompromittierung über Cloudflare-Infrastruktur
• CVE: nicht zutreffend; es handelt sich um eine Infrastrukturkompromittierung und nicht um eine klassische Software-Schwachstelle
• CVSS: nicht zutreffend
• Angriffsdatum: 14. September 2026
• Brevo-Angriffsfenster: die schädliche Manipulation war mehrere Stunden am 14. September aktiv
• Geschätzte Reichweite: laut Sansec wurden betroffene Brevo-Komponenten von mehr als 100.000 Websites verwendet
• WordPress-Auswirkung: Versuch, bei einem angemeldeten Administrator ein schädliches Plugin zu installieren und zu aktivieren
• Auswirkung auf Besucher: ClickFix-Seiten konnten Windows-Benutzer zur Ausführung eines schädlichen Befehls verleiten
• Aktueller Angriffsstatus: die ursprüngliche schädliche Auslieferung über Brevo wurde beendet
• Aktuelles Risiko: Persistence kann auf WordPress-Websites bestehen bleiben, auf denen das schädliche Plugin erfolgreich installiert wurde
• Erforderliche Maßnahme: WordPress-Websites prüfen, die während des Vorfalls betroffene Brevo-Komponenten verwendeten und von einem angemeldeten Administrator besucht wurden

Was ist bei Brevo passiert?

Der Angriff entstand nicht durch eine Schwachstelle in WordPress selbst.

Angreifer erhielten Zugriff auf einen Cloudflare-API-Key von Brevo und nutzten diesen Zugang, um über die Brevo-Infrastruktur ausgelieferte Inhalte zu manipulieren.

Mit einem schädlichen Cloudflare Worker konnten HTTP-Responses am CDN-Rand verändert werden, bevor sie die Besucher erreichten.

Dadurch konnten eigentlich legitime Brevo-JavaScript-Ressourcen zusätzlichen schädlichen JavaScript-Code an Websites und deren Besucher ausliefern.

Die ursprünglichen Website-Dateien konnten unverändert bleiben

Dies ist eine wichtige Besonderheit dieses Supply-Chain-Angriffs.

Eine WordPress-Website konnte lokal vollständig saubere Dateien besitzen und ihren Besuchern dennoch schädliches JavaScript ausliefern, weil der Schadcode von einem externen vertrauenswürdigen Dienst stammte.

Eine klassische Dateiintegritätskontrolle auf dem WordPress-Server musste den ursprünglichen Angriff deshalb nicht erkennen.

Welche Brevo-Komponenten waren betroffen?

Während des Vorfalls wurden schädliche Änderungen an verschiedenen Brevo-Ressourcen festgestellt, darunter:

• Brevo Forms;
• Brevo Conversations Widget;
• Brevo SDK Loader;
• von Brevo gehostete Seiten und Formulare.

Websites, die betroffene JavaScript-Dateien direkt aus der Brevo-Infrastruktur geladen haben, konnten den eingeschleusten Code während des Angriffs an ihre eigenen Besucher weitergeben.

WordPress-Administratoren wurden gezielt angegriffen

Das schädliche JavaScript prüfte auf WordPress-Websites, ob der aktuelle Besucher bei WordPress angemeldet war.

Wurde eine Administrator-Sitzung erkannt, versuchte der Angriff die vorhandenen Rechte des Administrators zu verwenden, um ein schädliches WordPress-Plugin hochzuladen und zu aktivieren.

Dadurch konnte aus einer vorübergehenden Kompromittierung eines externen JavaScript-Anbieters eine persistente Kompromittierung der WordPress-Installation entstehen.

Schädliches Plugin Web Media Optimizer

BleepingComputer konnte das während des Angriffs verbreitete WordPress-Plugin analysieren.

Das schädliche Plugin gab sich aus als:

Web Media Optimizer

Trotz des legitim wirkenden Namens arbeitet das Plugin als persistente Backdoor und JavaScript-Loader.

Die Analyse zeigt außerdem, dass sich das Plugin aus der normalen WordPress-Pluginliste verstecken und eine Kopie in:

wp-content/mu-plugins/

ablegen kann.

Deshalb reicht es nicht aus, ausschließlich die Plugin-Übersicht im WordPress-Backend zu kontrollieren.

Welche WordPress-Websites sollten überprüft werden?

Eine zusätzliche Untersuchung ist insbesondere erforderlich, wenn:

• die WordPress-Website am 14. September 2026 ein betroffenes Brevo-Script, Formular, SDK oder Conversations Widget verwendet hat; und
• ein WordPress Administrator die Website während des betroffenen Zeitraums angemeldet besucht hat.

In diesem Fall sollte geprüft werden, ob während des Vorfalls unerwartete Plugins installiert oder aktiviert wurden.

Plugin-Dateien direkt auf dem Server kontrollieren

Verlassen Sie sich nicht ausschließlich auf die Pluginliste in wp-admin, da schädlicher Code ein Plugin dort verbergen kann.

Kontrollieren Sie die tatsächlichen Plugin-Verzeichnisse auf dem Server:

find wp-content/plugins -maxdepth 2 -type f -ls

Kontrollieren Sie zusätzlich die Must-Use-Plugins:

find wp-content/mu-plugins -type f -ls 2>/dev/null

Untersuchen Sie unbekannte Plugins und Dateien, die rund um den 14. September 2026 erstellt oder verändert wurden.

Am 14. September geänderte PHP-Dateien prüfen

Eine erste Übersicht der an diesem Tag geänderten PHP-Dateien kann beispielsweise mit folgendem Befehl erstellt werden:

find wp-content -type f -name '*.php' -newermt '2026-09-14 00:00:00' ! -newermt '2026-09-15 00:00:00' -ls

Eine an diesem Datum geänderte Datei ist nicht automatisch schädlich. Reguläre Plugin- und Theme-Updates können ähnliche Zeitstempel erzeugen.

Vergleichen Sie verdächtige Änderungen deshalb mit bekannten Updates, Deployments und zuverlässigen Backups.

WordPress-Accesslogs überprüfen

Sansec empfiehlt, die Accesslogs vom 14. September insbesondere auf einen Plugin-Upload zu prüfen:

POST /wp-admin/update.php?action=upload-plugin

und anschließend auf eine Plugin-Aktivierung:

GET /wp-admin/plugins.php?action=activate

Wenn solche Requests während des Angriffszeitraums vorhanden sind, sollten Zeitstempel, Quell-IP, Administrator-Sitzung und die zu diesem Zeitpunkt erstellten Dateien genauer untersucht werden.

Administrator-Konten kontrollieren

Eine persistente WordPress-Backdoor kann auch nach dem ursprünglichen Supply-Chain-Angriff für weitere Änderungen verwendet werden.

Kontrollieren Sie deshalb alle Administrator-Konten:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Untersuchen Sie insbesondere:

• unbekannte Administrator-Konten;
• kürzlich angelegte Administratoren;
• unbekannte E-Mail-Adressen;
• unerwartete Änderungen an bestehenden Benutzerkonten.

Bekannte schädliche Hostnamen

Sansec identifizierte mehrere Hostnamen, die während der Kampagne zur Auslieferung des schädlichen JavaScripts verwendet wurden:

cdn.sendibt1.com
cdn2.sendibt1.com
cdn3.sendibt1.com
cdn4.sendibt1.com
cdn9.sendibt1.com
cdn10.sendibt1.com
cdn11.sendibt1.com

Diese schädlichen Hosts lösten nach dem Vorfall nicht mehr auf.

Blockieren Sie nicht pauschal die gesamte Domain sendibt1.com. Die Hauptdomain wird auch für legitime Brevo-Funktionen verwendet. Eine vollständige Sperre kann deshalb reguläre Brevo-Dienste beeinträchtigen.

Bekannte Hashes der manipulierten JavaScript-Dateien

Sansec veröffentlichte unter anderem folgende SHA-256-Hashes der während des Angriffs manipulierten Assets:

58a5c601c9df7ca2120435588fc39f97712d9b878795f6ee500590099a432308
f67d572d2d30407b3f470904326411450763108980cdad89550fbb221fb06782
9b62c12bc5c7feb9802f58e6cf75a368690df3c754e37cc64483a92acacf87a5

Diese Hashes können bei der Untersuchung zwischengespeicherter, protokollierter oder archivierter Kopien der betroffenen externen Scripts hilfreich sein.

ClickFix zielte auf die Computer von Besuchern

Wenn kein WordPress Administrator als Ziel ausgewählt wurde, konnte Besuchern eine gefälschte Cloudflare-Verifizierungsseite angezeigt werden.

Die Besucher wurden aufgefordert, einen Befehl über Windows Run auszuführen.

Diese Angriffstechnik wird als ClickFix bezeichnet.

Eine legitime Cloudflare- oder Browser-Verifizierung fordert Besucher nicht dazu auf, Windows Run zu öffnen und einen Befehl aus der Zwischenablage auszuführen.

Wenn der ClickFix-Befehl ausgeführt wurde

Ein Windows-System, auf dem der schädliche Befehl tatsächlich ausgeführt wurde, sollte als potenziell kompromittiert behandelt werden.

Das System sollte vom Netzwerk getrennt und gründlich auf Malware untersucht werden.

Zugangsdaten, die von diesem Computer verwendet wurden oder dort verfügbar waren, sollten ebenfalls als potenziell offengelegt betrachtet werden. Bei Administratoren können darunter WordPress-, Hosting-, SSH-, SFTP- und andere Verwaltungszugänge fallen.

Brevo liefert inzwischen wieder saubere Dateien aus

Die ursprüngliche schädliche Auslieferung über die Brevo-Infrastruktur ist nicht mehr aktiv.

Der schädliche Cloudflare Worker und die zugehörigen Routen wurden entfernt und die kompromittierten Zugangsdaten widerrufen.

Sansec bestätigte anschließend, dass die schädlichen Hostnamen nicht mehr auflösten und die betroffenen Brevo-Dateien wieder sauber waren.

Das aktuelle Risiko ist Persistence

Die Bereinigung der externen Brevo-Infrastruktur entfernt jedoch kein schädliches Plugin, das während des Vorfalls bereits auf einer WordPress-Website installiert wurde.

Wenn die Installation während einer aktiven Administrator-Sitzung erfolgreich war, kann diese lokale Kompromittierung auch nach Ende des Supply-Chain-Angriffs bestehen bleiben.

Deshalb sollten zuvor exponierte WordPress-Websites überprüft werden.

Bei gefundener Malware WordPress als kompromittiert behandeln

Wenn das schädliche Plugin, ein unbekanntes MU-Plugin oder andere konkrete Hinweise auf eine Kompromittierung gefunden werden, reicht das Entfernen einer einzelnen Datei nicht aus.

Ein Angreifer mit persistentem WordPress-Zugriff kann bereits weitere Änderungen durchgeführt haben.

Kontrollieren Sie mindestens:

• alle WordPress-Benutzer;
• Plugins und MU-Plugins;
• Themes;
• kürzlich geänderte PHP-Dateien;
• WordPress-Cron-Events;
• die Datenbank;
• Webserver- und PHP-Logs;
• unerwartete ausgehende Verbindungen;
• API-Keys und andere Secrets.

Ändern Sie relevante Administrator-Passwörter und andere Zugangsdaten, wenn diese während der Kompromittierung zugänglich gewesen sein könnten.

Auch eine vollständig aktualisierte WordPress-Website konnte betroffen sein

Dieser Vorfall unterscheidet sich von einer klassischen WordPress-Schwachstelle.

Eine WordPress-Installation konnte vollständig aktuell sein und trotzdem schädliches JavaScript ausliefern, weil die Kompromittierung bei einem vertrauenswürdigen externen Anbieter stattfand.

Der Vorfall zeigt, dass WordPress-Sicherheit nicht nur aus Updates für Core, Plugins und Themes besteht.

Externe Scripts, Marketingplattformen, Chat-Widgets, Analytics-Dienste und andere Third-Party-Integrationen gehören ebenfalls zur Angriffsfläche einer Website.

Verantwortung für WordPress- und CMS-Sicherheit

Kunden ohne Managed WordPress/CMS-Wartung oder einen separat vereinbarten Managed-CMS-Service sind selbst dafür verantwortlich, WordPress, WooCommerce, andere CMS-Plattformen, Plugins, Erweiterungen und Themes rechtzeitig zu aktualisieren und externe Integrationen ihrer Website zu verwalten.

Wenn Missbrauch, Malware oder nachweislich überfällige Wartung dazu führen, dass eine Website oder ein Dienst ein Risiko für unsere Infrastruktur, andere Kunden oder Dritte darstellt, kann Vservs die betreffende Website oder den Dienst vorübergehend isolieren oder deaktivieren.

Dies erfolgt ausschließlich als Sicherheits- und Kontinuitätsmaßnahme, um weitere Schäden, Missbrauch oder Beeinträchtigungen der Infrastruktur und Dienstleistungen zu verhindern.

Wiederherstellungsarbeiten an nicht verwalteten Umgebungen außerhalb unserer regulären Geschäftszeiten, an Wochenenden oder Feiertagen hängen von der Schwere des Vorfalls und der verfügbaren Kapazität ab. Wenn kein sofortiges Eingreifen erforderlich ist, können die Arbeiten ab dem nächsten Werktag aufgenommen werden.

Managed WordPress von Vservs

Der Brevo Supply-Chain-Angriff zeigt, dass Sicherheitsvorfälle auch außerhalb von WordPress Core und installierten Plugins entstehen können. Professionelle WordPress-Sicherheit erfordert deshalb neben Patchmanagement auch Monitoring und die Untersuchung ungewöhnlicher Dateien und Aktivitäten.

Mit Vservs Managed WordPress übernehmen wir unter anderem die technische WordPress-Verwaltung, Core-, Plugin- und Theme-Updates, Security Hardening und Monitoring, Malware-Kontrollen, Backups sowie technische Unterstützung bei Sicherheitsvorfällen im Rahmen der vereinbarten Leistungen.

Quellen

• Sansec – Brevo Supply Chain Attack hits 100k+ sites
• BleepingComputer – Brevo Supply-Chain-Angriff und WordPress-Backdoor-Analyse