Sicherheitshinweis September 2026

Brevo hat zwei separate Sicherheitsvorfälle im September 2026 offengelegt, die seine Kundenplattform und Infrastruktur betrafen.

Der erste betraf unbefugten Zugriff auf 138 Brevo-Kundenkonten, wobei mehrere Konten anschließend verwendet wurden, um Phishing-E-Mails über die legitime Brevo-Infrastruktur zu verteilen.

Tage später führte eine separate Kompromittierung der Cloudflare-Umgebung von Brevo dazu, dass schädliches JavaScript über von Brevo kontrollierte Websites und von Kunden eingebettete Assets ausgeliefert wurde.

Unabhängige Sicherheitsforscher schätzen, dass der zweite Vorfall potenziell mehr als 100.000 Websites erreichen konnte, die Brevo-Komponenten verwenden.

Zusammen verdeutlichen die Vorfälle eine zunehmend wichtige Realität für Organisationen, die auf E-Mail- und Marketing-Plattformen Dritter angewiesen sind:

Vertrauenswürdige Infrastruktur kann dennoch zu einem Angriffskanal werden, wenn die sie steuernden Systeme oder Konten kompromittiert werden.

Sie werfen auch eine wichtige Frage für Organisationen auf, deren Domains weiterhin mit DMARC auf p=none konfiguriert sind:

Setzt Ihre Domain tatsächlich Schutz gegen unbefugte Nutzung durch, oder überwacht sie diese nur?

I. Was ist bei Brevo passiert?

Brevo hat zwei getrennte Sicherheitsvorfälle im September 2026 offengelegt.

Vorfall 1: SAML-SSO-Kontokompromittierung

Am 10. September 2026 identifizierte Brevo ein Sicherheitsproblem bei seiner Implementierung von SAML Single Sign-On.

Laut dem offiziellen Vorfallbericht von Brevo nutzte ein Angreifer ein Autorisierungsgrenzenproblem aus, um Zugriff zu erhalten auf:

138 Brevo-Kundenkonten

Brevo berichtete, dass:

• 6 Konten zum Versenden von Phishing-E-Mails verwendet wurden.
• Kontakte aus 43 Konten exportiert wurden.
• 93 Konten keine nennenswerte Angreiferaktivität aufwiesen.

Brevo identifizierte das Problem um etwa 06:30 UTC am 10. September und erklärte, dass der Zugriffsweg bis etwa 08:30 UTC geschlossen worden sei.

Das Unternehmen meldete außerdem jeden aktiven Benutzer auf seiner gesamten Plattform ab.

Laut Brevo erstellte der Angreifer ein Brevo-Konto, konfigurierte SSO und lud legitime Brevo-Benutzer in diese Umgebung ein.

Das Problem trat auf, weil die Authentifizierung über die SSO-Konfiguration einer Organisation nicht ordnungsgemäß auf diese Organisation beschränkt war.

Stattdessen konnte der Angreifer Zugriff auf andere Organisationen erlangen, auf die diese eingeladenen Benutzer zugreifen konnten.

Brevo beschrieb die Grundursache als eine Autorisierungsgrenze, die nicht korrekt durchgesetzt worden war.

II. Phishing wurde über legitime Brevo-Infrastruktur versendet

Einer der wichtigsten Aspekte der Offenlegung von Brevo ist, dass die Phishing-Nachrichten nicht einfach gefälschte Nachrichten waren, die von einer unabhängigen Infrastruktur gesendet wurden.

Sie wurden über legitime Brevo-Infrastruktur gesendet.

Brevo erklärte ausdrücklich, dass:

Die Nachrichten normale E-Mail-Authentifizierungsprüfungen bestanden, weil sie von legitimer Infrastruktur stammten.

Diese Unterscheidung ist entscheidend.

SPF, DKIM und DMARC können feststellen, ob eine E-Mail technisch authentifiziert ist.

Sie beantworten Fragen wie:

• War dieser Server zum Senden berechtigt?
• Wurde die Nachricht kryptografisch signiert?
• Stimmt die authentifizierte Absenderdomain mit der sichtbaren From-Domain überein?

Sie können jedoch nicht beantworten:

Wurde das autorisierte Konto selbst von einem Angreifer kontrolliert?

Wenn ein Angreifer ein legitimes Konto auf einer autorisierten Plattform kompromittiert und Nachrichten über korrekt konfigurierte Infrastruktur sendet, können die resultierenden Nachrichten SPF, DKIM und DMARC erfolgreich bestehen.

Deshalb sollte E-Mail-Authentifizierung als eine Schicht einer umfassenderen E-Mail-Sicherheitsarchitektur betrachtet werden.

III. Ein zweiter Brevo-Vorfall folgte vier Tage später

Am 14. September 2026 erlebte Brevo einen zweiten und technisch anderen Sicherheitsvorfall.

Brevo bestätigte, dass ein Angreifer einen langlebigen Cloudflare-API-Schlüssel mit vollständigen Kontoberechtigungen erlangte.

Laut Brevo war diese Berechtigung im Anwendungsquellcode gespeichert worden.

Der Angreifer nutzte den kompromittierten API-Schlüssel, um einen bösartigen Cloudflare Worker in Brevos Umgebung einzusetzen.

Dieser Worker konnte den über Brevos CDN-Infrastruktur laufenden Datenverkehr modifizieren.

Für etwa fünfeinhalb Stunden wurde schädliches JavaScript eingefügt in:

• brevo.com
• sendinblue.com
• Brevo-Login-, Konto- und Onboarding-Seiten
• sibforms.com
• Brevo-Formulare
• Brevo-Conversations-Widgets
• Brevo-SDK-Loader
• JavaScript-Dateien, die von Brevo-Kunden auf ihren eigenen Websites eingebettet wurden

Brevo berichtete, dass das primäre Auswirkungsfenster etwa von:

15:01 UTC bis 20:30 UTC am 14. September dauerte.

IV. Der ClickFix-Angriff

Besucher, die vom schädlichen JavaScript betroffen waren, konnten eine gefälschte Cloudflare-Verifizierungsseite sehen.

Die Seite wies Windows-Benutzer an, Aktionen durchzuführen, die Folgendes umfassten:

1. Drücken von Win + R
2. Einfügen eines Befehls
3. Ausführen dieses Befehls

Das Befolgen dieser Schritte führte dazu, dass Malware auf den Computer des Opfers heruntergeladen wurde.

Diese Technik wird häufig als ClickFix bezeichnet.

Brevo berichtete außerdem, dass auf WordPress-Websites, die betroffene Brevo-Komponenten einbetteten, das schädliche Skript versuchte, ein Plugin zu installieren und zu aktivieren, wenn ein angemeldeter WordPress-Administrator die Website besuchte.

Brevo entfernte den bösartigen Cloudflare Worker, widerrief die kompromittierten Anmeldedaten, löschte vom Angreifer kontrollierte Hostnamen und bereinigte die betroffenen Edge-Caches.

Das Unternehmen erklärte, dass die kompromittierten Skripte jetzt sicher verwendet werden können.

V. Mehr als 100.000 Websites potenziell exponiert

Brevo hat keine genaue Anzahl von Kunden-Websites veröffentlicht, die das betroffene JavaScript geladen haben.

Unabhängige Sicherheitsforschung von Sansec schätzte jedoch, dass Brevos eingebettete Komponenten auf mehr als 100.000 Websites vorhanden waren.

Das bedeutet nicht, dass 100.000 Websites zwangsläufig kompromittiert wurden oder dass jeder Besucher Malware erhielt.

Der schädliche Inhalt wurde selektiv ausgeliefert.

Der potenzielle Verbreitungsumfang zeigt jedoch den Verstärkungseffekt, der entsteht, wenn vertrauenswürdige JavaScript-Infrastruktur Dritter kompromittiert wird.

Dies ist ein klassisches Supply-Chain-Risiko.

Anstatt einzelne Organisationen nacheinander zu kompromittieren, kann ein Angreifer Infrastruktur kompromittieren, der Tausende von Organisationen bereits vertrauen.

VI. Zwei Vorfälle, zwei verschiedene Sicherheitsprobleme

Es ist wichtig, die beiden Vorfälle technisch nicht zu vermischen.

Sie betrafen unterschiedliche Angriffspfade.

10. September

Angriffsvektor: SAML-SSO-Autorisierungsfehler

Auswirkung: Unbefugter Zugriff auf 138 Kundenkonten

Ergebnis: Phishing-E-Mails, die über legitime Brevo-Kundenkonten gesendet wurden, und Kontaktdaten, die aus einigen Konten exportiert wurden

14. September

Angriffsvektor: Kompromittierte Cloudflare-API-Berechtigung

Auswirkung: Schädliches JavaScript in Brevo-Websites und von Kunden eingebettete Ressourcen eingefügt

Potenzielle Reichweite: Mehr als 100.000 Websites laut unabhängiger Sicherheitsforschung

Ergebnis: ClickFix-Malware-Auslieferung und versuchte WordPress-Persistenz

VII. Was hat das mit DMARC zu tun?

Keiner der Vorfälle wurde durch DMARC verursacht.

Und keiner der Vorfälle sollte als etwas dargestellt werden, das DMARC allein hätte verhindern können.

Die Vorfälle verdeutlichen jedoch, warum Organisationen genau verstehen sollten, wie Dienste Dritter zur Nutzung ihrer Domains autorisiert sind.

Die aktuelle Dokumentation von Brevo stellt Kunden eine DMARC-Konfiguration zur Verfügung, die Folgendes verwendet:

v=DMARC1; p=none; rua=mailto:[email protected]

Eine p=none-DMARC-Richtlinie ist gültig.

Es ist jedoch wichtig zu verstehen, was sie bedeutet.

p=none bedeutet Monitoring

Gemäß dem aktuellen DMARC-Standard arbeitet eine mit:

p=none

konfigurierte Domain im Monitoring-Modus.

Empfangende Mailsysteme können DMARC auswerten und Berichtsdaten generieren, aber der Domain-Inhaber fordert keine restriktive Behandlung speziell aufgrund eines DMARC-Fehlers an.

Das macht p=none während der ersten DMARC-Bereitstellung äußerst nützlich.

Organisationen können herausfinden:

• Welche Systeme E-Mails mit ihrer Domain versenden
• Ob SPF ausgerichtet ist
• Ob DKIM ausgerichtet ist
• Welche Plattformen Dritter autorisiert sind
• Welche unbekannte Infrastruktur möglicherweise die Domain imitiert

Aber p=none ist keine DMARC-Durchsetzung.

VIII. DMARC-Monitoring vs. Durchsetzung

Es gibt drei primäre DMARC-Richtlinienzustände.

p=none

Monitoring

Bietet Einblick in Authentifizierung und Ausrichtung.

Es wird keine restriktive Handhabungspräferenz basierend auf DMARC-Fehler angefordert.

p=quarantine

Durchsetzung

Fordert an, dass Empfänger Nachrichten, die bei DMARC fehlschlagen, restriktiver behandeln.

Je nach empfangendem Anbieter kann dies eine Spam-Platzierung, Quarantäne oder andere Handhabung umfassen.

p=reject

Stärkere Durchsetzung

Drückt die stärkste DMARC-Richtlinienpräferenz für Nachrichten aus, die die DMARC-Validierung nicht bestehen.

Empfangende Anbieter behalten letztendlich die Kontrolle über die endgültige Disposition einer Nachricht.

Der praktische Unterschied ist:

p=none überwacht.

p=quarantine und p=reject setzen eine Richtlinie durch.

Hat p=none die Brevo-Vorfälle verursacht?

Nein.

Dieser Punkt ist wichtig.

Beim Vorfall vom 10. September erlangten Angreifer Zugriff auf legitime Brevo-Konten.

Wenn ein kompromittiertes Brevo-Konto E-Mails über ordnungsgemäß authentifizierte Brevo-Infrastruktur sendet, können diese Nachrichten DMARC erfolgreich bestehen.

Die Änderung einer Domain von:

p=none

zu:

p=reject

würde nicht zwangsläufig eine authentifizierte bösartige Nachricht blockieren, die von einem kompromittierten autorisierten Konto stammt.

DMARC analysiert nicht die Absicht oder den Inhalt einer E-Mail.

DMARC beantwortet eine andere Frage:

Ist diese Nachricht authentifiziert und mit der Domain ausgerichtet, die sie vorgibt zu repräsentieren?

Diese Unterscheidung ist grundlegend.

IX. Warum ist DMARC-Durchsetzung dann wichtig?

Betrachten Sie einen anderen Angreifer.

Dieser Angreifer hat Brevo nicht kompromittiert.

Er hat keinen Zugriff auf Microsoft 365.

Er hat keinen Zugriff auf Google Workspace.

Er kontrolliert keine Plattform, die legitim zum Senden von E-Mails im Namen der Organisation autorisiert ist.

Stattdessen versucht der Angreifer einfach zu senden:

From: [email protected]

unter Verwendung von Infrastruktur, die vom Angreifer kontrolliert wird.

Wenn diese Infrastruktur keine SPF- oder DKIM-Authentifizierung bereitstellen kann, die mit unternehmen.com ausgerichtet ist, schlägt die Nachricht bei DMARC fehl.

Mit:

p=none

überwacht der Domain-Inhaber hauptsächlich den Fehler.

Mit einer Durchsetzungsrichtlinie wie:

p=quarantine

oder:

p=reject

drückt die Organisation eine restriktive Handhabungsrichtlinie für diese fehlgeschlagene Nachricht aus.

Das ist eine der wichtigsten Sicherheitsfunktionen von DMARC.

Es reduziert die Fähigkeit eines Angreifers, eine geschützte Domain direkt unter Verwendung nicht autorisierter Infrastruktur zu imitieren.

p=none ist oft der richtige Ausgangspunkt

Organisationen sollten nicht einfach jede Domain sofort auf p=reject umstellen.

Dies ohne Verständnis der Sendeumgebung der Organisation zu tun, kann legitime E-Mails stören.

Moderne Organisationen können E-Mails senden über:

• Microsoft 365
• Google Workspace
• Salesforce
• HubSpot
• Brevo
• Zendesk
• Marketing-Plattformen
• Abrechnungssysteme
• CRM-Systeme
• HR-Plattformen
• Transaktionale E-Mail-Anbieter
• Ticketing-Systeme
• Sicherheitsplattformen
• Interne Anwendungen

Vor der Durchsetzung müssen diese Systeme entdeckt und korrekt authentifiziert werden.

Deshalb ist p=none oft eine angemessene Bereitstellungsphase.

Die Frage ist, ob es die permanente Sicherheitslage bleiben sollte.

X. DMARC bereitgestellt bedeutet nicht immer DMARC durchgesetzt

Diese Unterscheidung wird häufig übersehen.

Eine Domain kann einen gültigen DMARC-Eintrag haben, während sie vollständig im Monitoring-Modus arbeitet.

Zum Beispiel:

v=DMARC1; p=none;

bedeutet, dass DMARC vorhanden ist.

Aber die Domain ist nicht in die Durchsetzung übergegangen.

Deshalb sollten Organisationen unterscheiden zwischen:

DMARC-Bereitstellung

und:

DMARC-Durchsetzung

Sie sind nicht synonym.

XI. Mindest-Compliance ist nicht maximaler Schutz

Große Mailbox-Anbieter verlangen zunehmend Authentifizierung von Massenversendern.

Diese Anforderungen haben die E-Mail-Sicherheit im gesamten Ökosystem erheblich verbessert.

Aber viele Versenderanforderungen akzeptieren:

p=none

als minimale DMARC-Richtlinie.

Das wichtige Wort ist:

minimal

Ein Unternehmen kann daher eine Massensender-Anforderung erfüllen, während seine Domain noch im Monitoring-Modus arbeitet.

Für Unternehmen, Finanzinstitutionen, regulierte Unternehmen und hochwertige Marken sollte regulatorische oder Plattform-Compliance nicht automatisch als dasselbe betrachtet werden wie maximaler Domain-Schutz.

XII. Brevo-Kunden sollten ihre aktuelle DMARC-Konfiguration überprüfen

Brevo stellt Kunden derzeit eine DMARC-Richtlinie zur Verfügung, die Folgendes verwendet:

v=DMARC1; p=none; rua=mailto:[email protected]

Organisationen, die Brevo verwenden, sollten überprüfen, ob dies auch die umfassendere DMARC-Sicherheitsrichtlinie ihrer Organisation ist.

Es sollte nur einen gültigen DMARC-Eintrag pro Domain geben.

Organisationen sollten daher vermeiden, konkurrierende DMARC-Einträge zu veröffentlichen, nur weil mehrere E-Mail-Plattformen Authentifizierung anfordern.

Absender Dritter sollten stattdessen in die bestehende Authentifizierungsarchitektur der Organisation integriert werden.

XIII. Sollten Organisationen Brevo entfernen?

Nicht einfach wegen dieser Vorfälle.

Wenn Brevo ein legitimes Geschäftssystem bleibt, das von der Organisation aktiv genutzt wird, kann das abrupte Entfernen von Authentifizierungseinträgen legitime E-Mails stören.

Stattdessen sollten Organisationen die Vertrauensbeziehung neu bewerten.

1. Bestätigen Sie, dass Brevo noch erforderlich ist

Jede externe Plattform, die zur Nutzung einer Unternehmens-Domain autorisiert ist, sollte einen legitimen aktuellen Geschäftszweck haben.

Ungenutzte Plattformen sollten nicht auf unbestimmte Zeit autorisiert bleiben.

2. Überprüfen Sie die Brevo-Kontosicherheit

Organisationen sollten überprüfen:

• Administrator-Konten
• SSO-Konfiguration
• Privilegierte Benutzer
• API-Anmeldedaten
• SMTP-Anmeldedaten
• MFA-Konfiguration
• Kontozugriffsprotokolle

3. Überprüfen Sie Ihre DMARC-Richtlinie

Bestimmen Sie, ob die Domain Ihrer Organisation derzeit auf:

p=none

p=quarantine

oder:

p=reject

arbeitet.

Gehen Sie nicht davon aus, dass die Existenz eines DMARC-Eintrags bedeutet, dass die Domain DMARC durchsetzt.

4. Identifizieren Sie jeden autorisierten Absender

Organisationen sollten jede Plattform verstehen, die derzeit E-Mails mit ihren Domains versendet.

Unbekannte Sende-Infrastruktur sollte untersucht werden.

5. Validieren Sie SPF- und DKIM-Ausrichtung

Legitime Sendedienste sollten DMARC durch korrekt ausgerichtete SPF und/oder DKIM erfüllen.

Dies ermöglicht es legitimer E-Mail fortzufahren, während nicht autorisierte Infrastruktur identifiziert wird.

6. Bewegen Sie sich in Richtung Durchsetzung, wo angemessen

Sobald legitime Absender entdeckt und authentifiziert wurden, sollten Organisationen bewerten, ob das unbegrenzte Verbleiben im Monitoring-Modus ihre gewünschte Sicherheitslage widerspiegelt.

7. Veröffentlichen Sie nicht mehrere DMARC-Einträge

Eine Domain sollte eine kohärente DMARC-Richtlinie haben.

Das Hinzufügen zusätzlicher unabhängiger DMARC-Einträge kann eine ungültige Konfiguration erzeugen.

XIV. Zusätzliche Maßnahmen nach dem Vorfall vom 14. September

Organisationen, die Brevo-Website-Komponenten verwenden, sollten auch Brevos Sanierungsanleitung überprüfen.

Brevo empfiehlt ausdrücklich Maßnahmen, wenn ein Benutzer am 14. September mit dem schädlichen Inhalt interagiert hat.

Wenn der ClickFix-Befehl ausgeführt wurde

Behandeln Sie den betroffenen Computer als potenziell kompromittiert.

Brevo empfiehlt:

• Trennen des Systems
• Durchführen eines vollständigen Sicherheitsscans
• Ändern von Passwörtern, die auf dem Gerät verwendet wurden
• Priorisierung der Brevo-Konto-Anmeldedaten

Wenn ein WordPress-Administrator eine betroffene Website besucht hat

Organisationen, die Brevo-Skripte auf WordPress verwenden, sollten am 14. September installierte oder aktivierte Plugins überprüfen.

Brevo empfiehlt, verdächtige Plugins zu entfernen und Administrator-Anmeldedaten zu ändern.

Wenn sich ein Benutzer am 14. September bei Brevo angemeldet hat

Brevo empfiehlt, das Kontopasswort zu ändern und API-Anmeldedaten vorsorglich zu überprüfen.

XV. Was Skysnag-Kunden tun sollten

Für Skysnag-Kunden, die Brevo verwenden, gibt es keine automatische Anforderung, Brevo als autorisierten Absender zu entfernen.

Brevo kann als legitime Sendeplattform integriert bleiben, während Skysnag weiterhin die umfassendere Domain-Authentifizierung und DMARC-Richtlinie verwaltet.

Ihre bestehende, von Skysnag verwaltete DMARC-Konfiguration sollte nicht durch einen generischen p=none-Eintrag ersetzt werden, nur weil Brevo Domain-Authentifizierung anfordert.

Das Ziel ist nicht, legitime Infrastruktur zu blockieren.

Das Ziel ist sicherzustellen, dass:

• Legitime Dienste authentifiziert bleiben
• Nicht autorisierte Quellen die Domain nicht leicht imitieren können
• Die DMARC-Ausrichtung korrekt bleibt
• Die Durchsetzungsrichtlinie der Domain kontrolliert bleibt
• Änderungen an der Sendeumgebung sichtbar bleiben

XVI. Die größere Sicherheitslektion

Die beiden Brevo-Vorfälle veranschaulichen zwei verschiedene Formen von Drittanbieter-Risiken.

Der erste zeigte, dass:

Ein legitimes E-Mail-Konto zu einem Phishing-Kanal werden kann, wenn die Kontoautorisierung fehlschlägt.

Der zweite zeigte, dass:

Vertrauenswürdige Web-Infrastruktur zu einem Malware-Verteilungskanal werden kann, wenn Infrastruktur-Anmeldedaten kompromittiert werden.

Organisationen sind zunehmend abhängig von miteinander verbundenen Netzwerken von:

• SaaS-Anbietern
• E-Mail-Plattformen
• Marketing-Systemen
• CRMs
• CDN-Infrastruktur
• JavaScript-Bibliotheken
• Cloud-Anbietern
• Transaktionalen E-Mail-Systemen

Jede vertrauenswürdige Integration erweitert die operativen Fähigkeiten der Organisation.

Sie erweitert auch ihre Vertrauensgrenze.

Das bedeutet, dass moderne Domain-Sicherheit mehrschichtig sein muss.

Kontosicherheit schützt den Zugriff auf autorisierte Plattformen.

SPF authentifiziert Sende-Infrastruktur.

DKIM authentifiziert Nachrichten.

DMARC validiert Domain-Ausrichtung.

DMARC-Reporting bietet Transparenz.

DMARC-Durchsetzung verstärkt den Schutz vor nicht autorisierter direkter Domain-Imitation.

Keine einzelne Kontrolle löst jede Angriffsklasse.

Das Ziel ist, diese Kontrollen zusammenarbeiten zu lassen.

XVII. Monitoring sollte zu einer Sicherheitsentscheidung führen

DMARC p=none hat einen wichtigen Zweck.

Es bietet Organisationen die Intelligenz, die erforderlich ist, um ihre Sendeumgebung zu verstehen, bevor Durchsetzung eingeführt wird.

Aber Monitoring ist am wertvollsten, wenn es letztendlich eine Sicherheitsentscheidung informiert.

Sobald autorisierte Absender identifiziert und ordnungsgemäß authentifiziert wurden, sollten Organisationen bestimmen, ob das unbegrenzte Verbleiben bei p=none das Schutzniveau widerspiegelt, das sie tatsächlich benötigen.

Denn es gibt einen wichtigen Unterschied zwischen:

Zu wissen, dass jemand Ihre Domain imitiert

und:

Veröffentlichung einer Richtlinie, die verhindern soll, dass nicht autorisierte Infrastruktur sie erfolgreich imitiert.

Monitoring bietet Transparenz.

Durchsetzung verwandelt diese Transparenz in Richtlinie.

XVIII. Überprüfen Sie Ihre Domain

Wenn Ihre Organisation Brevo verwendet und Sie unsicher sind, ob Ihre Domain derzeit bei p=none, p=quarantine oder p=reject arbeitet, kann Skysnag Ihre aktuelle E-Mail-Authentifizierungslage bewerten, autorisierte Sende-Infrastruktur identifizieren und einen angemessenen Weg zur Durchsetzung bestimmen, ohne legitime E-Mails unnötig zu stören.

Überprüfen Sie Ihre Domain mit Skysnag.