Ein Schlüssel, vier Stunden, 100.000 Websites
Am 14. September 2026 wurden über 100.000 Websites zu Malware-Schleudern. Keine einzige davon wurde gehackt.
Das ist kein Widerspruch. Das ist der Punkt.
Die Betreiber hatten starke Passwörter. Aktuelle Updates. Saubere Server. Und trotzdem lieferte ihre Website vier Stunden lang Schadcode an ihre eigenen Besucher aus — weil sie ein einziges fremdes Skript eingebunden hatten.
Wir haben uns den Vorfall genau angesehen, weil er exakt die Frage beantwortet, die uns Kunden am häufigsten stellen: Was genau macht eine Website eigentlich sicher?
Die Antwort ist unbequemer, als die meisten erwarten. Und sie hat fast nichts mit Passwörtern zu tun.
Was passiert ist
Betroffen war Brevo (früher Sendinblue), ein großer französischer Anbieter für E-Mail-Marketing und Website-Chat. Ein Dienst, den zehntausende Unternehmen einbinden — für Newsletter-Formulare, Kontakt-Widgets, Besucher-Tracking.
Der Ablauf, rekonstruiert von der Security-Firma Sansec:
- Angreifer kamen an einen langlebigen Cloudflare-API-Schlüssel von Brevo.
- Mit diesem Schlüssel deployten sie einen eigenen Cloudflare Worker in Brevos Infrastruktur — also ein Stück Code, das jede Auslieferung abfangen und verändern kann.
- Der Worker schrieb die Antworten von Brevos CDN um. Betroffen waren unter anderem
sdk-loader.jsundbrevo-conversations.js— genau die Dateien, die auf Kundenseiten eingebunden sind. - Die eigentliche Malware kam über Brevos eigene Domain
sendibt1.com. Für jeden Filter, jeden Virenscanner und jede Firewall sah das aus wie vertrauenswürdiger Traffic vom legitimen Anbieter.
Das Zeitfenster der aktiven Auslieferung: 14. September 2026, 16:05:18 bis 20:12:53 UTC. Rund vier Stunden. Brevo selbst spricht von etwa fünfeinhalb Stunden bis Worker und Schlüssel neutralisiert waren.
Der bittere Teil kam danach. Brevos eigene Untersuchung ergab: "Our investigation indicates the key was first misused in late August 2026." Der Schlüssel war seit Ende August in fremder Hand. Drei Wochen. Unbemerkt.
Und es war nicht der erste Vorfall in dieser Woche. Am 10. September war Brevo bereits über eine SAML-SSO-Schwachstelle kompromittiert worden: 138 betroffene Kundenkonten, aus 6 wurden Phishing-Mails verschickt, aus 43 Kontaktlisten exportiert. Unter den Betroffenen: der Krypto-Wallet-Hersteller Trezor.
Zweimal in sieben Tagen. Beim selben Anbieter.
Was die Besucher traf
Die ausgelieferte Schadsoftware hatte zwei Stufen — und die zweite ist der eigentliche Skandal.
Stufe 1 — ClickFix. Besucher sahen ein bildschirmfüllendes Overlay: "Cloudflare, verify you are human." Sieht aus wie die Sicherheitsprüfung, die jeder kennt und gedankenlos wegklickt. Tatsächlich schob das Skript dem Nutzer einen Befehl in die Zwischenablage und forderte ihn auf, diesen lokal auszuführen. Der Nutzer installiert die Malware selbst — vorbei an jedem Download-Schutz, jeder Browser-Warnung, jedem Virenscanner. Es gibt keine technische Lücke zu schließen, wenn der Mensch die Tür von innen öffnet.
Stufe 2 — die Hintertür. Das Skript prüfte, ob der Besucher gerade als WordPress-Administrator eingeloggt war. Sansec beschreibt es wörtlich:
"Is the site visitor logged in on Wordpress? Then secretly install a Wordpress plugin from
https://cdn10.sendibt1.com/p/wm.zip."
Wenn der Seitenbetreiber selbst im Admin-Bereich angemeldet war und seine eigene Website besuchte, installierte und aktivierte das Skript im Hintergrund ein Plugin über seine laufende Session. Eine dauerhafte Hintertür — gelegt mit den Rechten des Eigentümers, ohne ein einziges geknacktes Passwort.
Der Angriff endete nach vier Stunden. Die Hintertüren blieben.
Warum das kein Brevo-Problem ist
Es wäre bequem, jetzt auf Brevo zu zeigen. Das wäre auch falsch.
Brevo ist ein etablierter Anbieter mit Sicherheitsteam, Zertifizierungen und ernsthaften Prozessen. Genau das ist die Lektion: Wenn es die trifft, trifft es jeden. Der nächste Vorfall wird einen anderen Namen tragen — einen Analytics-Dienst, ein Chat-Widget, ein Cookie-Banner, ein Schriftarten-Netzwerk.
Die entscheidende Einsicht liegt eine Ebene tiefer:
Jedes fremde Skript auf Ihrer Website ist ein Schlüssel zu Ihrem Haus, den jemand anderes verwahrt.
Ein <script src="https://irgendwer.com/..."> im Code Ihrer Seite ist keine Verlinkung. Es ist eine Vollmacht. Der Code, der unter dieser Adresse liegt, wird im Browser Ihres Besuchers ausgeführt — mit allen Rechten Ihrer Domain. Er kann Formulare mitlesen, Inhalte austauschen, Overlays einblenden, Eingaben abgreifen.
Und Sie sehen es nicht. Denn ausgeliefert wird der Code nicht von Ihrem Server, sondern von einem fremden. Was gestern harmlos war, kann heute Malware sein — ohne dass sich an Ihrer Website ein einziges Byte geändert hat.
Das ist der Grund, warum 100.000 Betreiber ahnungslos waren. Es gab auf ihrer Seite nichts zu bemerken.
Die zwei Einfallstore — und wie man sie schließt
Der gesamte Angriff brauchte exakt zwei Voraussetzungen. Fehlt eine, läuft er ins Leere.
Einfallstor 1: Fremde Skripte im Auslieferungspfad
Das Prinzip: Was zur Laufzeit von fremden Servern nachgeladen wird, ist unkontrollierbar.
Unser Standard: Keine Drittanbieter-Skripte im Rendering-Pfad. Was gebraucht wird, wird beim Build fest in die Seite kompiliert — versioniert, überprüfbar, unveränderlich. Was nur dekorativ wäre, fliegt raus.
Das ist nachprüfbar, nicht behauptet. Öffnen Sie diese Seite, drücken Sie F12, gehen Sie auf "Netzwerk" und filtern Sie nach JS. Sie werden kein einziges Skript von einer fremden Domain finden. Die Angriffskette, die 100.000 Websites getroffen hat, hat hier schlicht keinen Anknüpfungspunkt — nicht weil wir sie abgewehrt hätten, sondern weil es nichts gibt, das sie übernehmen könnte.
Wenn ein Tracking- oder Chat-Dienst zwingend nötig ist, gilt bei uns: bewusste Entscheidung, dokumentiert, isoliert — und nicht "wird schon passen".
Einfallstor 2: Ein Admin-Bereich, der Plugins installieren darf
Das Prinzip: Ein System, das sich zur Laufzeit selbst verändern kann, kann auch von anderen verändert werden.
Der zweite Teil des Angriffs funktionierte ausschließlich gegen WordPress — weil WordPress genau das vorsieht: eine eingeloggte Admin-Session, die berechtigt ist, fremden Code als Plugin zu installieren und sofort auszuführen.
Wir bauen anders. Unsere Projekte entstehen mit Next.js und werden statisch gebaut. Konkret bedeutet das:
- Kein Admin-Panel, über das Code nachinstalliert werden kann. Der Befehl aus dem Brevo-Angriff hätte nichts, womit er sprechen könnte.
- Kein Plugin-Ökosystem. Kein Dutzend Fremdautoren mit Schreibrechten auf Ihrer Seite.
- Ausgeliefert werden fertige Dateien, kein Code, der bei jedem Aufruf neu zusammengesetzt wird.
- Jede Änderung ist ein Deploy — versioniert, nachvollziehbar, in Sekunden auf den Stand von gestern zurückrollbar.
Dazu kommen die Schutzmaßnahmen auf Auslieferungsebene, die bei uns gesetzt sind: erzwungenes HTTPS über HSTS mit zwei Jahren Laufzeit, X-Frame-Options: DENY gegen Clickjacking, X-Content-Type-Options: nosniff, eine restriktive Referrer-Policy und eine Permissions-Policy, die Kamera, Mikrofon und Standort pauschal abschaltet.
Was wir nicht versprechen
Hier trennen wir uns von den üblichen Agentur-Broschüren.
"100 % sicher" gibt es nicht. Wer Ihnen das verspricht, hat entweder nicht verstanden, wovon er redet, oder hofft, dass Sie es nicht verstehen.
Was es gibt, ist Angriffsfläche — und die ist eine architektonische Entscheidung, keine Frage des Fleißes. Dieser eine Angriff, mit dieser konkreten Kette, hätte gegen eine so gebaute Seite nicht funktioniert. Das ist eine präzise Aussage, keine Garantie für alle Zukunft.
Was wir stattdessen zusagen: Wir wissen zu jedem Zeitpunkt, welcher Code auf Ihrer Seite läuft und woher er kommt. Bei 100.000 Betreibern war diese Frage am 14. September nicht beantwortbar. Das ist der eigentliche Unterschied.
Ihre Checkliste: 5 Minuten, kein Techniker nötig
Prüfen Sie Ihre eigene Website. Jetzt.
- Rechtsklick → "Seitenquelltext anzeigen". Suchen Sie mit Strg+F nach
<script src="https://. Jeder Treffer mit einer fremden Domain ist eine Vollmacht, die Sie vergeben haben. - Zählen Sie. Unter 3 ist bewusst. Über 10 ist unkontrolliert.
- Fragen Sie zu jedem Treffer: Was passiert, wenn dieser Anbieter morgen kompromittiert wird? Wenn Sie es nicht wissen, wissen Sie zu wenig.
- WordPress im Einsatz? Dann prüfen Sie die Plugin-Liste auf Einträge, die Sie nicht selbst installiert haben — und melden Sie sich zwischen Arbeitssitzungen im Admin-Bereich ab. Eine offene Admin-Session ist eine offene Tür.
- Klären Sie die Update-Frage. Wer installiert Sicherheitsupdates, in welchem Rhythmus, und wer merkt es, wenn es niemand tut?
Punkt 5 entscheidet am Ende mehr als jede Technologiewahl. Die meisten kompromittierten Websites fallen nicht spektakulären Angriffen zum Opfer, sondern einem Update, das seit acht Monaten aussteht.
Fazit
Vier Stunden. Ein Schlüssel. 100.000 Websites, deren Betreiber alles richtig gemacht hatten — und trotzdem Schadcode auslieferten.
Website-Sicherheit ist 2026 keine Frage von Passwortlänge und Virenscanner. Sie ist eine Frage der Architektur: Wie viel fremder Code darf zur Laufzeit in Ihrem Namen sprechen?
Jede Abhängigkeit, die Sie nicht eingehen, ist ein Risiko, das Sie nicht verwalten müssen. Deshalb bauen wir Websites, die wenig brauchen und viel können — nicht aus Purismus, sondern weil das der einzige Schutz ist, der auch dann noch hält, wenn ein Anbieter irgendwo in Europa seinen Cloudflare-Schlüssel verliert.
Wenn Sie wissen wollen, wie viele fremde Skripte gerade auf Ihrer Website laufen und was davon wirklich nötig ist: Sprechen wir darüber. Wir schauen es uns an — unverbindlich, in Klartext, ohne Panikverkauf.
Quellen und weiterführende Berichterstattung:
- Golem.de — API-Key geleakt: Plötzlich Malware über 100.000 Websites verbreitet
- Sansec — Technische Analyse des Angriffs
- SecurityWeek — Brevo Supply Chain Attack
Weiterführend: Webdesign vs. Digital Empire · Premium B2B Website Kosten 2026