Brevo-Lieferkettenangriff: ClickFix-Code auf über 100.000 Websites

Wer auf der eigenen Website ein Brevo-Formular, den Brevo-Tracker oder das Brevo-Chat-Widget eingebunden hat, muss die Seite jetzt auf Kompromittierung prüfen. Am 14. September 2026 lieferte Brevo über rund fünfeinhalb Stunden manipulierte JavaScript-Dateien aus. Besucher bekamen eine gefälschte Cloudflare-Verifizierungsseite zu sehen, die sie zum Ausführen eines Befehls auf dem eigenen Rechner verleiten sollte. Auf WordPress-Seiten versuchte derselbe Code, im Namen eines eingeloggten Administrators ein Schadplugin zu installieren.

Nicht betroffen ist, wer kein Brevo-Konto betreibt und keine Skripte von brevo.com oder sibforms.com in seine Seiten einbindet. Ebenfalls unverändert blieben laut Brevo die Anwendung unter app.brevo.com, die API, die Mailzustellung und die Kontodaten der Kunden. Der Schadcode wurde ausschließlich am CDN-Rand eingeschleust, die Dateien auf den Ursprungsservern blieben unangetastet. Genau das macht die Prüfung nötig: Ein Abgleich der eigenen eingebundenen Skripte gegen die Originaldateien hätte den Angriff nicht gezeigt.

Was ist passiert?

Der Vorfall besteht aus zwei Teilen. Am 10. September 2026 nutzte ein Angreifer eine Schwachstelle in der Art, wie Brevo SAML-basiertes Single Sign-on verarbeitet. Laut Brevos eigenem Write-up legte er ein Brevo-Konto an, aktivierte dort SSO und lud bestehende Brevo-Nutzer in diese SSO-Konfiguration ein. Über den eigenen Identity Provider konnte er sich anschließend als diese Nutzer anmelden. Der Zugriff war falsch begrenzt: Statt nur auf die eine Organisation mit der SSO-Konfiguration reichte er auf alle Organisationen, auf die die eingeladenen Nutzer Zugriff hatten. Betroffen waren 138 Konten, darunter eines des Krypto-Wallet-Anbieters Trezor. Aus sechs Konten wurden Phishing-Mails an die dort gespeicherten Kontakte verschickt, aus 43 Konten wurden Kontaktdaten exportiert. Brevo schloss den Zugang am selben Tag um 8:30 Uhr UTC und meldete alle Sitzungen ab. Eine CVE-Nummer für diese Schwachstelle ist bislang nicht veröffentlicht.

Der zweite, deutlich größere Teil folgte am 14. September. Die Angreifer verfügten über einen langlebigen Cloudflare-API-Schlüssel mit vollen Kontorechten, der im Quelltext einer Anwendung fest hinterlegt war. Damit ließen sich Cloudflare Worker, Routen und DNS-Einträge in Brevos Zonen anlegen, ohne dass eine Warnung auslöste. Der eingeschleuste Worker schrieb die Antworten direkt am CDN-Rand um und entfernte dabei Sicherheitsheader wie die Content-Security-Policy. Betroffen waren Seiten auf brevo.com, sendinblue.com, sibforms.com sowie Login-, Konto- und Onboarding-Pfade. Zusätzlich manipulierte der Worker drei JavaScript-Dateien, die Kunden selbst in ihre Websites einbetten: das Formular-Skript, das Conversations-Widget und den SDK-Loader.

Brevo beziffert das Zeitfenster der Auslieferung auf 16:07 bis 20:30 Uhr UTC und damit auf etwa fünfeinhalb Stunden. Danach entfernte das Unternehmen den Worker samt Routen, widerrief den kompromittierten Schlüssel und alle damit erzeugten Zugangsdaten, löschte die vom Angreifer angelegten Hostnamen, entfernte die fest hinterlegte Zugangsinformation aus dem Quelltext und leerte die Edge-Caches. Nach eigenen Angaben wurde der Schlüssel erstmals Ende August 2026 missbraucht, eine Einschleusung in kundenseitige Seiten habe es vor dem 14. September aber nicht gegeben.

Wer ist betroffen?

Betroffen sind drei Gruppen, die man sauber auseinanderhalten sollte, weil die Maßnahmen unterschiedlich ausfallen.

• Websitebetreiber mit eingebundenem Brevo-Code: Wer den Brevo-Tracker, das Chat-Widget oder ein Anmeldeformular auf der eigenen Seite lädt, hat am 14. September potenziell Schadcode an die eigenen Besucher ausgeliefert. Die Sicherheitsfirma Sansec schätzt die Zahl betroffener Websites auf über 100.000. Diese Zahl ist eine Schätzung von Sansec, keine Angabe von Brevo.
• WordPress-Seiten mit Brevo-Widget: Hier kommt ein zweites Risiko dazu. Das Skript prüfte, ob der Besucher als Administrator angemeldet war, und versuchte in diesem Fall, ein Plugin hochzuladen und auszuführen. BleepingComputer hat ein Archiv aus VirusTotal analysiert, das sich als Plugin mit dem Namen Web Media Optimizer ausgibt und als dauerhafte Hintertür arbeitet.
• Empfänger von Brevo-Kampagnenmails: Wer in diesem Zeitfenster einen Abmelde- oder Formularlink aus einer über Brevo versendeten Mail angeklickt hat, konnte ebenfalls auf der gefälschten Verifizierungsseite landen, ohne die betroffene Website überhaupt zu besuchen.

Nicht betroffen ist, wer weder Brevo-Konten betreibt noch Brevo-Skripte einbindet. Wer nur transaktionale Mails über die Brevo-API verschickt und keine Skripte einbettet, ist nach den Angaben von Brevo ebenfalls außen vor, sollte aber die eigene Kontoaktivität seit dem 10. September trotzdem einmal durchsehen.

Wie kritisch ist das?

Es handelt sich nicht um eine Remote Code Execution auf Serverseite. Der Angriffspfad ist eine Kombination aus Lieferkettenmanipulation und Social Engineering: Fremder Code wurde an vertrauenswürdiger Stelle in bestehende Seiten eingeschleust, die eigentliche Ausführung von Schadcode auf dem Besucherrechner erforderte jedoch eine bewusste Handlung. Bei ClickFix wird ein Befehl in die Zwischenablage gelegt und der Nutzer aufgefordert, ihn selbst einzufügen und auszuführen, in diesem Fall unter Windows. Wer das nicht getan hat, hat sich durch den bloßen Seitenaufruf keine Schadsoftware eingefangen.

Deutlich schwerer wiegt der WordPress-Teil. Dort war keine Nutzerinteraktion nötig, es genügte, dass ein angemeldeter Administrator die eigene Website im Frontend aufrief. Das Plugin wurde dann mit der Sitzung des Administrators installiert. Eine solche Hintertür überlebt das Ende des Vorfalls und bleibt aktiv, bis sie gefunden und entfernt wird. Für WordPress-Betreiber mit Brevo-Widget ist das daher ein Fall für eine sofortige Prüfung, nicht für das nächste Wartungsfenster.

Erschwerend kommt hinzu, dass gängige Integritätsprüfungen versagt haben. Weil der Worker erst am CDN-Rand eingriff, blieben die Originaldateien korrekt und die üblichen Kontrollen schlugen nicht an. Zusätzlich entfernte der Worker Sicherheitsheader, sodass auch eine vorhandene Content-Security-Policy auf den Brevo-eigenen Seiten nicht griff. Auf der eigenen Website greift eine selbst gesetzte Policy dagegen weiterhin, weil sie vom eigenen Server kommt.

Was sollten Admins jetzt tun?

• Inventar zuerst: Im Quelltext der eigenen Seiten, im Tag-Manager und in der Plugin-Liste prüfen, ob Skripte von brevo.com, cdn.brevo.com, sibforms.com oder sendinblue.com geladen werden. Ohne diesen Befund ist jede weitere Maßnahme unnötig.
• Zeitfenster abgleichen: Im Webserver-Log oder in der Webanalyse prüfen, ob zwischen dem 14. September 16:00 Uhr UTC und dem 15. September Besucher bedient wurden. Bei einer Seite mit nennenswertem Traffic ist davon auszugehen.
• WordPress auf fremde Plugins prüfen: Das Verzeichnis wp-content/plugins mit der erwarteten Liste vergleichen, zusätzlich wp plugin list ausführen. Ein Eintrag mit dem Namen Web Media Optimizer ist ein direkter Treffer, jedes andere unbekannte Plugin ebenso verdächtig. Auf Änderungszeitstempel ab dem 14. September achten.
• Benutzerkonten kontrollieren: Die Liste der WordPress-Administratoren auf neu angelegte oder hochgestufte Konten durchsehen und Rollenänderungen im Protokoll prüfen.
• Sitzungen und Passwörter zurücksetzen: Alle Sitzungs-Cookies invalidieren und die Passwörter aller Administratorkonten ändern, wenn ein Administrator die Seite im Zeitfenster im Frontend geöffnet hatte.
• Brevo-Konto durchsehen: Kontaktexporte, versendete Kampagnen und SSO-Konfigurationen seit dem 10. September prüfen. Bei ungewöhnlichen Exporten greifen die Meldepflichten nach Artikel 33 DSGVO, weil es um personenbezogene Kontaktdaten geht.
• Besucher informieren: Wer die gefälschte Verifizierungsseite gesehen und den angebotenen Befehl ausgeführt hat, sollte den Rechner prüfen lassen. Sansec empfiehlt ausdrücklich, Besucher darauf hinzuweisen.
• Erst danach härten: Drittanbieter-Skripte inventarisieren, Subresource Integrity setzen, wo die Datei stabil ist, und eine Content-Security-Policy mit klarer Quellenliste ausrollen.
• Backups prüfen: Einen Stand von vor dem 14. September bereithalten, aber nicht blind zurückspielen. Erst den Befund sichern, sonst verschwinden die Spuren.

Einordnung für Unternehmen

Der Vorfall zeigt zwei Muster, die für kleine und mittlere Unternehmen unmittelbar übertragbar sind. Erstens: Ein einziger langlebiger API-Schlüssel mit vollen Rechten, fest im Quelltext hinterlegt, reichte aus, um die Auslieferung für mehr als hunderttausend fremde Websites zu verändern. Wer selbst Schlüssel für Cloudflare, Hosting, Mailversand oder Zahlungsdienste vergibt, sollte diese auf die tatsächlich nötigen Rechte begrenzen, mit Ablaufdatum versehen und regelmäßig rotieren. Ein Schlüssel ohne Ablaufdatum ist ein dauerhaft offener Zugang.

Zweitens: Jedes fremde Skript auf der eigenen Website ist eine Vertrauensbeziehung, die man im Ernstfall nicht kontrolliert. Eine schlichte Liste aller eingebundenen Drittanbieter, mit Zweck, Verantwortlichem im Haus und Kontaktweg beim Anbieter, verkürzt die Reaktionszeit bei genau solchen Meldungen erheblich. Ohne diese Liste beginnt jede Prüfung mit der Frage, was überhaupt eingebunden ist.

Dazu kommt die Aufklärung im Team. ClickFix funktioniert nur, weil Menschen einen kopierten Befehl in den Ausführen-Dialog von Windows oder in ein Terminal einfügen. Die Regel dagegen ist kurz und lässt sich einmal im Jahr auffrischen: Eine echte Verifizierungsseite fordert niemals dazu auf, einen Befehl auf dem eigenen Rechner auszuführen. Wer diese Aufforderung sieht, schließt die Seite und meldet sie.

Passende Anleitungen auf S-EDV

• ClickFix umgeht die Terminal-Warnung in macOS Tahoe: erklärt die Masche im Detail und zeigt, wie sich das Muster plattformübergreifend wiederholt.
• OptinMonster: Supply-Chain-Angriff über kompromittiertes CDN: ein sehr ähnlicher Fall bei einem anderen WordPress-Dienstleister, hilfreich für den Vergleich der Prüfschritte.
• WordPress-Plugins: Risiken und ein belastbarer Prüfprozess: liefert das Vorgehen, mit dem sich unbekannte Plugins im Bestand systematisch auffallen lassen.

Quellen

• Brevo Status: Attacker gained access to client accounts, Write-up
• Brevo Status: Security Incident ClickFix
• Sansec: Brevo supply chain attack hits 100k+ sites, 16.09.2026
• BleepingComputer: Brevo supply-chain attack injected ClickFix scripts, 17.09.2026
• SecurityWeek: Brevo Supply Chain Attack Injects Malware Into 100,000 Websites, 18.09.2026