Varia

... von Ihren Experten für eigentlich eh fast alles.

 25. 06. 2026   Ingo Lantschner   Lesezeit ca. 5 Minuten

Ein gekaperter Baustein: der Polyfill-Vorfall auf diesem Blog

Ein aufmerksamer Leser dieses Blogs wurde von einem Login-Dialog überrascht. Dahinter steckte eine fremde Bibliothek, die feindlich übernommen worden war.

Heute früh hat mir ein Leser geschrieben, dass beim Öffnen dieses Blogs plötzlich ein Login-Fenster aufgepoppt sei – ein Kasten, der nach Benutzername und Passwort fragt. Sein Gefühl, dass da was nicht stimmen kann, war goldrichtig. Denn dieses Fenster gehörte nicht zu meinem Blog. Es war der sichtbare Teil eines Angriffs, bei dem nicht der eigene Server gehackt wird, sondern ein zugekaufter Baustein von außen feindlich übernommen wurde.

Phishing-Dialogfeld – so sah das Fenster aus, mit dem versucht worden war, Login-Daten abzugreifen. Dieser Blog verlangt natürlich keine Anmeldung, daher ist so etwas höchst verdächtig.

Ich erzähle über den Vorfall hier in zwei Teilen: zuerst eine Erklärung für alle, die einfach nur wissen wollen, was los war und ob sie etwas tun müssen. Danach der ausführliche Teil für jene, die selbst Websites betreiben.

Teil A: Für alle Leser

Was war da los?

Eine Website besteht selten nur aus Text und Bildern. Im Hintergrund lädt sie kleine Hilfsprogramme – etwa solche, die ältere Browser unterstützen sollten. Mein Blog lud so ein Hilfsprogramm von einem fremden Server nach, den Dienst »polyfill.io«.

Das Problem: Dieser Dienst war vor einiger Zeit von Kriminellen übernommen worden. Aus dem Hilfsprogramm wurde eine Falle. In der jüngsten Variante öffnet die feindliche Seite ein Login-Fenster und versucht, das eingetippte Passwort abzugreifen – das nennt man Phishing. Genau dieses Fenster hat mein Leser gesehen.

Wichtig zur Entwarnung: Mein Server wurde nicht eingebrochen. Es lag nichts Schädliches auf meiner Seite. Vergiftet war ein fremder Baustein, der von meinem Blog »nur« nachgeladen wurde.

Musst du jetzt etwas tun?

In den allermeisten Fällen: nein. Der Fehler ist behoben, und beim normalen Lesen ist nichts passiert. Zwei Dinge solltest du trotzdem mitnehmen:

  • Auf diesem Blog gibt es keinen Login. Es gab nie einen Grund, dich hier anzumelden. Ein Login-Fenster auf dieser Seite war also immer eine Falle. Wenn so etwas auftaucht: nichts eintippen, Fenster schließen.
  • Falls du – hier oder anderswo – schon einmal in ein unerwartet aufgetauchtes Login-Fenster Zugangsdaten eingegeben hast: ändere dieses Passwort sofort!

Was ich getan habe, damit das nicht wiederkommt

Ich habe den fremden Baustein entfernt. Alles, was der Blog zum Anzeigen braucht, bringt er jetzt selbst mit, statt es von fremden Servern zu holen. Zusätzlich habe ich dem Browser eine Regel mitgegeben: Er weist fremde Programme jetzt von vornherein ab, selbst wenn sich versehentlich wieder eines einschleichen sollte.

Teil B: Für alle, die selbst hosten

Hier wird es technisch. Wenn du einen Blog oder eine Website betreibst – besonders mit einem fertigen Theme, das du nicht Zeile für Zeile kennst –, ist dieser Fall lehrreich.

Was konkret eingebunden war

Im <head> meiner Seiten stand ein Script-Tag, der https://polyfill.io/v3/polyfill.min.js nachlud. Solche Polyfill-Einbindungen waren in älteren Themes verbreitet, um fehlende Browser-Funktionen nachzurüsten. Heute braucht ein statischer Blog das praktisch nie – die JavaScript-Features sind längst überall vorhanden.

Was im konkreten Vorfall hätte passieren können, hing von der Welle ab:

  • Credential-Phishing: Die übernommene Domain beantwortet den Script-Request mit einem HTTP-401. Das löst den Basic-Auth-Dialog des Browsers aus – das Login-Fenster, das mein Leser sah. Firefox warnte ihn, dass die Eingabe an eine fremde Herkunft gehen würde.
  • Schadcode und Umleitungen: Frühere Wellen schleusten auf Mobilgeräten Schadcode ein und leiteten Besucher auf Betrugs- und Wettseiten um.

Hintergrund: ein Supply-Chain-Angriff

Im Februar 2024 wurde der populäre Dienst polyfill.io von der Firma Funnull übernommen, die daraufhin begann, schädliches JavaScript über cdn.polyfill.io auszuliefern. Am 29. Mai 2025 sanktionierte das US-Finanzministerium (OFAC) Funnull und dessen Administrator. Die Empfehlung der Sicherheits­branche ist seit Juni 2024 unverändert: jede Referenz auf polyfill.io entfernen.

Das Tückische am Supply-Chain-Angriff: Ich habe an meiner Seite nichts geändert. Geändert hat sich die Abhängigkeit. Ein Baustein, dem man einmal vertraut hat, wird im Nachhinein feindlich – und die Lücke wandert mit jedem Seitenaufruf zum Besucher. »Supply Chain« meint hier die Lieferkette der Software: alles, was deine Seite an fremdem Code einbindet. Ein einziges Glied dieser Kette reicht, wenn es kippt.

Lessons learned: warum das jetzt nicht mehr passieren kann

Ich habe nicht nur die eine Zeile gelöscht, sondern mehrere Schichten eingezogen, die unabhängig voneinander greifen:

  1. Selbst hosten statt CDN. Sämtliche Frontend-Bibliotheken liegen jetzt lokal unter /vendor/: der Formelsatz (KaTeX als Standard, MathJax bei Bedarf), Schriften, Icons. Kein fremder Server wird mehr beim Seitenaufruf kontaktiert. Was nicht von außen kommt, kann von außen nicht vergiftet werden.
  2. Content-Security-Policy. Der Server schickt einen CSP-Header mit script-src 'self'. Der Browser führt damit nur noch Scripts lokaler Herkunft aus. Selbst wenn sich versehentlich wieder ein Fremd-Script-Tag in ein Template verirrt, wird es geblockt – eine Laufzeit-Absicherung, die im konkreten Fall schon gereicht hätte.
  3. Stückliste und automatische Prüfung. Es gibt jetzt eine maschinenlesbare SBOM (Software Bill of Materials) im CycloneDX-Format: eine Liste jeder eingebundenen Fremd-Bibliothek mit Version und Prüfsumme. Ein Scanner (osv-scanner) gleicht diese Versionen wöchentlich gegen die Schwachstellen-Datenbank OSV.dev ab. Dazu kommen Prüfungen beim Bauen der Seite: ob die ausgelieferten Dateien noch zur Stückliste passen, ob eine neue Bibliothek vergessen wurde – und ein Scan des fertigen HTML auf Ladezugriffe zu fremden Servern. Genau dieser letzte Scan hätte den Polyfill-Tag schon beim Bauen gemeldet, lange bevor er einen Leser erreicht.
  4. Aktuell halten. Der Schwachstellen-Scan meldete beim ersten Lauf vier offene Advisories in der alten KaTeX-Version. Die habe ich auf eine aktuelle Fassung gehoben; der Scanner meldet seither nichts mehr.

Wenn du selbst hostest und/oder Hugo verwendest, ist die Kurzfassung:

  • Durchsuche dein Theme nach fremden Einbindungen: grep -rni "polyfill\|http" layouts/ themes/ --include=*.html. Alles, was per src/href auf eine fremde Domain zeigt, gehört hinterfragt.
  • Setze am Webserver eine Content-Security-Policy – am besten zuerst im Report-Only-Modus, dann scharf.
  • Führe eine SBOM und automatisiere den Abgleich gegen Advisory-Datenbanken. Das ist auch der Gedanke hinter dem Cyber Resilience Act: zu wissen, was man ausliefert.
  • Im Zweifel: lieber selbst hosten als per CDN einbinden. Ein bisschen mehr Wartung, dafür kein fremder Server in der Lieferkette.

Bleibt der Dank an den Leser, der den Login-Dialog gemeldet hat, statt ihn wegzuklicken. Sein Reflex – nichts eingeben aber sofort melden und nachfragen – ist die beste Verteidigung, die es gegen solche Angriffe gibt! Genau deshalb steht er hier noch einmal: Tauchen Login-Fenster unerwartet auf, sind sie immer verdächtig – bis das Gegenteil feststeht.

Weitere Artikel aus der
Kategorie Errata

Radwegsalat Operngasse
Ein sanierter Radweg sorgt für Verwirrung und verschlechtert die Situation für Radfahrende.

Richtigstellungen Sommer 2022
Eine fehlerhafte U-Bahnstudie und eine Fake-News URL justament in der Anleitung zum Faktencheck.


Kategorie: Errata
Schlagworte: Sicherheit Supply-Chain Polyfill CSP SBOM Hugo Selfhosting Phishing KaTeX Webentwicklung