Gekapertes Messskript bei DebugBear: So prüfst und sicherst du fremde Skripte auf deiner Website

01 / Was passiert ist

Was beim DebugBear-Vorfall belegt ist.

DebugBear ist ein Werkzeug, mit dem viele SEO-Teams die Ladezeit ihrer Seiten messen. Das Produkt „Real User Monitoring“ (RUM) bindet dafür ein kleines JavaScript in die Website ein, das bei echten Besuchern Messwerte wie die Core Web Vitals erfasst [1][2]. Eingebunden wird es über eine Adresse nach dem Muster cdn.debugbear.com/<ID>.js, die ID unterscheidet sich je Website [1].

Am 29. Oktober fand die Sicherheitsfirma Hudson Rock an genau so einer Skript-Adresse, die die Handelsplattform Polymarket nutzte, schädliches JavaScript [1][2]. Noch am selben Tag schrieb DebugBear auf X, man sei von einem laufenden Sicherheitsvorfall betroffen; wer das RUM-Produkt nutze, solle den Einbindungscode von seiner Website entfernen [2][4].

In einem späteren Update nannte DebugBear die Ursache: Die DNS-Einträge seien über den Domain-Registrar kompromittiert worden. Nach der ersten Untersuchung habe der Angriff die Website eines bestimmten Kunden zum Ziel gehabt, Hinweise auf eine Kompromittierung der eigenen internen Systeme gebe es nicht. E-Mails an die eigene Domain könne man derzeit nicht empfangen [1][3]. Wie die Angreifer an den Registrar-Zugang kamen, hat DebugBear nicht erklärt, die Untersuchung läuft [3].

Bei Polymarket suchte der Schadcode nach eingeloggten Nutzern, verkaufte Positionen und verschob Guthaben aus deren Wallets. Ein Passwort brauchte er dafür nicht, er nutzte die Rechte der bereits angemeldeten Sitzung [1][2]. Polymarket stoppte den Handel für etwa eine Stunde [2] und nannte am 30. Oktober 726 betroffene Wallets; insgesamt will die Plattform 3,9 Millionen Dollar erstatten [3].

Offen ist laut Search Engine Journal, ob auch andere DebugBear-Kunden Schadcode ausgeliefert bekamen [1]. Wer das RUM-Skript eingebunden hat, sollte es entfernen, Sitzungen und Passwörter zurücksetzen, betroffene API-Zugänge widerrufen und Benutzerkonten, Tag-Manager-Verlauf, Templates und Plugins auf unerwartete Änderungen prüfen [1]. Wichtig dabei: Das Entfernen verhindert nur neue Ladevorgänge. Was in der Zwischenzeit passiert ist, macht es nicht rückgängig [1].

02 / Das eigentliche Risiko

Warum dich das betrifft, auch ohne DebugBear.

Das Muster ist nicht auf ein Messwerkzeug beschränkt. Deine Seite lädt eine Datei von einer fremden Domain, und der Browser führt sie aus, als wäre es dein eigener Code. Wer die Kontrolle über diese Domain bekommt, kann die Datei austauschen. Die Adresse in deinem Quelltext bleibt dabei gleich, nur antwortet ein anderer Server. Genau das bedeutet eine DNS-Übernahme (Einschätzung auf Basis der DebugBear-Angaben [1][3]).

Die Mozilla-Entwicklerdokumentation beschreibt das Risiko allgemein: Bekommt ein Angreifer die Kontrolle über den fremden Host, kann er beliebigen Schadcode in dessen Dateien einschleusen oder sie komplett ersetzen. Das nennt man Supply-Chain-Angriff [6].

Bei einem Firmenblog ohne Login klingt das harmlos. Ich sehe aber zwei Stellen, an denen es auch für kleinere Websites ernst wird (Einschätzung):

• Eingeloggte Admins: Wer in WordPress angemeldet ist und das Frontend aufruft, lädt dort dieselben Skripte wie jeder Besucher, nur mit Admin-Sitzung im Browser. Ein manipuliertes Skript könnte im Namen dieser Person handeln, so wie es bei Polymarket mit den Handelsrechten geschah [1].
• Formulare und Checkout: Wo Kundinnen Adressen, Kontaktdaten oder Zahlungsinformationen eingeben, kann ein fremdes Skript mitlesen, wenn es im selben Seitenkontext läuft.

Das ist dieselbe Lektion wie beim manipulierten Plugin-Update, das ich in Rank Math PRO mit Schadcode ausgeliefert beschrieben habe: Du vertraust nicht nur dem Anbieter, sondern auch seiner Infrastruktur, bis hin zum Registrar.

03 / Inventur

Wie du alle fremden Skripte findest.

Bevor du irgendetwas absicherst, brauchst du eine Liste. In meinen Projekten finde ich fremde Skripte meist an diesen Stellen (Einschätzung aus der Praxis):

1. Theme und Header-Felder: In WordPress im Theme-Code, in den Theme-Optionen oder in Plugins, die Code in Kopf- oder Fußzeile einfügen. In Shopify in theme.liquid und in App-Einbettungen.
2. Plugins und Apps: Chat-Widgets, Bewertungs-Tools, Cookie-Banner, Heatmaps und Monitoring laden ihre Skripte oft selbst nach.
3. Google Tag Manager: Jedes benutzerdefinierte HTML-Tag kann weitere Skripte laden. Prüf im Container, welche Tags es gibt und wer zuletzt etwas veröffentlicht hat. Wie du Tags testest, steht in GA4 und Tag Manager mit Tag Assistant testen.
4. Shopify-Pixel: App-Pixel und Custom Pixels im Bereich Kundenereignisse.

Am schnellsten bekommst du die tatsächliche Liste im Browser: Entwicklertools öffnen, Reiter „Netzwerk“, Filter auf „JS“, Seite neu laden und alle Domains notieren, die nicht deine eigene sind. Mach das einmal ausgeloggt und einmal eingeloggt, auf Startseite, Produktseite, Kontaktformular und im Checkout. Zu jedem Eintrag gehören drei Fragen: Wer braucht das noch, wer ist verantwortlich, und muss das Skript auf dieser Seite laufen? (Einschätzung)

Bei Shopify hast du einen eingebauten Vorteil. App-Pixel und Custom Pixels laufen in einer Sandbox, also einer abgeschotteten Umgebung, die laut Shopify verhindert, dass ein Pixel Daten außerhalb seines erklärten Zwecks sammelt [7]. Custom Pixels laufen in einer „lax“ genannten Sandbox: einem iframe mit den Rechten allow-scripts und allow-forms, das nicht auf das Hauptfenster zugreifen kann [8]. Auch Tags, die der Google Tag Manager als Custom Pixel lädt, bleiben in dieser Sandbox [7]. Skripte, die direkt im Theme-Code stehen, laufen dagegen nicht in der Pixel-Sandbox (Einschätzung). Warum Shopify ältere Einbindungswege ohnehin abschaltet, habe ich in Shopify schaltet Script-Tags ab erklärt.

04 / Absichern

Content Security Policy, SRI und Self-Hosting: Was wirklich schützt.

Für fremde Skripte gibt es drei Werkzeuge. Keines löst alles, zusammen verkleinern sie das Risiko deutlich.

Content Security Policy

Eine Content Security Policy (CSP) ist eine Anweisung deiner Website an den Browser, welche Ressourcen, vor allem welche JavaScript-Dateien, eine Seite laden darf. Sie wird als HTTP-Header Content-Security-Policy ausgeliefert [5]. Lädt eine Seite dann ein Skript von einer Domain, die nicht erlaubt ist, blockiert der Browser es.

Die Grenze zeigt der DebugBear-Fall: Eine Liste erlaubter Domains prüft nur, woher ein Skript kommt, nicht was darin steht. Steht die Domain des Anbieters auf der Liste, läuft auch die ausgetauschte Datei (Einschätzung). MDN rät deshalb zu einer „strikten“ CSP mit Nonces oder Hashes und hält reine Domain-Listen für schwer richtig hinzubekommen; als Beispiel nennt MDN einen Bericht, nach dem allein für Google Analytics 187 Google-Domains freizugeben waren [5].

Mein Rat für den Einstieg: Starte mit dem Header Content-Security-Policy-Report-Only. Dann setzt der Browser nichts durch, meldet aber Verstöße an eine von dir angegebene Adresse [5]. So siehst du nach ein, zwei Wochen, welche Skripte wirklich geladen werden, ohne dass Formulare oder Tracking ausfallen. In WordPress setzt du den Header über den Server, ein Sicherheits-Plugin oder den Hoster (Einschätzung).

Subresource Integrity

Subresource Integrity (SRI) prüft den Inhalt. Du hängst an das <script>-Tag ein integrity-Attribut mit einem kryptografischen Hash der Datei. Passt die geladene Datei nicht zum Hash, verweigert der Browser das Laden [6]. Bei Skripten von fremden Domains braucht es zusätzlich das Attribut crossorigin, und der Anbieter muss CORS unterstützen [6].

Der Haken: Ein Hash funktioniert nur, wenn sich die Datei hinter der Adresse nicht ständig ändert. Viele Tracking- und Monitoring-Skripte werden vom Anbieter laufend aktualisiert, dann bricht SRI bei jedem Update (Einschätzung). Frag deine Anbieter, ob sie versionierte Dateien mit festem Hash anbieten. Für Bibliotheken von öffentlichen CDNs ist SRI dagegen der Normalfall.

Self-Hosting und weniger Skripte

Wenn ein Anbieter es erlaubt, kannst du die Skriptdatei auf deinem eigenen Server ablegen. Dann hängt sie nicht mehr am DNS des Anbieters, dafür musst du Updates selbst einspielen (Einschätzung). Die wirksamste Maßnahme ist oft die einfachste: Skripte, die niemand mehr auswertet, löschen, und Tracking sowie Monitoring für eingeloggte Admins und auf Kontoseiten abschalten, wenn das Werkzeug das anbietet (Einschätzung).

05 / Messen ohne Zusatzskript

Core Web Vitals messen, ohne ein weiteres Skript einzubauen.

Viele binden ein RUM-Skript nur ein, um die Core Web Vitals im Blick zu behalten. Für die meisten kleineren Websites reichen dafür die kostenlosen Daten von Google (Einschätzung).

• Chrome UX Report (CrUX): Ein Datensatz aus echten Chrome-Browsern, der alle Core-Web-Vitals-Messwerte enthält und von der Google-Suche für das Ranking-Signal Seitennutzerfreundlichkeit genutzt wird. Seiten und Domains erscheinen dort nur mit genügend Besuchern [10].
• PageSpeed Insights: Zeigt Felddaten aus CrUX und Labordaten aus Lighthouse. Reichen die Daten für eine Einzelseite nicht, fällt das Tool auf die gesamte Domain zurück [9]. Bestanden ist die Prüfung, wenn das 75. Perzentil von LCP, INP und CLS im grünen Bereich liegt [9].
• Search Console: Der Core-Web-Vitals-Bericht gruppiert indexierte URLs nach „Gut“, „Optimierung erforderlich“ und „Langsam“ auf Basis tatsächlicher Nutzungsdaten [11].

Die Grenzen solltest du kennen: Die Daten stammen nur aus Chrome und fehlen bei wenig Traffic ganz [9][10]. Wer einzelne Interaktionen auf Seitenebene nachverfolgen will, braucht weiterhin ein RUM-Werkzeug. Dann würde ich es nur auf öffentlichen Seiten laden, nicht im Checkout und nicht für eingeloggte Nutzer (Einschätzung).

FAQ

Häufige Fragen zu fremden Skripten.

Ich nutze DebugBear nur für Labortests. Muss ich etwas tun?

DebugBears Aufforderung betrifft das RUM-Produkt, also das eingebundene Skript [2]. Prüf trotzdem im Quelltext und im Tag Manager, ob irgendwo eine Adresse mit cdn.debugbear.com geladen wird [1].

Macht eine Content Security Policy meine Seite langsamer?

Die CSP ist nur ein HTTP-Header, den der Browser auswertet [5]. Das Risiko liegt eher darin, dass eine zu strenge Policy benötigte Skripte blockiert. Deshalb zuerst im Report-Modus testen [5].

Quellen

Quellen

1. Search Engine Journal (Vahan Petrosyan): „Hackers Hijacked DebugBear’s DNS To Serve Malicious JavaScript“, 31. Oktober 2026 – searchenginejournal.com · abgerufen 02.11.2026.
2. BleepingComputer (Lawrence Abrams): „Polymarket halts trading after crypto-draining script breach, $2.5M traced“, 29. Oktober 2026 – bleepingcomputer.com · abgerufen 02.11.2026.
3. SecurityWeek (Eduard Kovacs): „Polymarket Returns $3.9 Million to Traders as DebugBear Cites DNS Hijack“, 2. November 2026 – securityweek.com · abgerufen 02.11.2026.
4. DebugBear auf X: Vorfallsmeldung vom 29. Oktober 2026 (x.com/DebugBear/status/2115866496643535293) und Update mit ersten Erkenntnissen (x.com/DebugBear/status/2116306975403250070), zitiert nach [2] und [3]; debugbear.com war beim Abruf nicht erreichbar · abgerufen 02.11.2026.
5. MDN Web Docs (Mozilla): „Content Security Policy (CSP)“ – developer.mozilla.org · abgerufen 02.11.2026.
6. MDN Web Docs (Mozilla): „Subresource Integrity“ – developer.mozilla.org · abgerufen 02.11.2026.
7. Shopify Help Center: „Pixels overview“ – help.shopify.com · abgerufen 02.11.2026.
8. Shopify Dev Docs: „About web pixels“ (Abschnitt Sandbox environments) – shopify.dev · abgerufen 02.11.2026.
9. Google for Developers: „About PageSpeed Insights“ – developers.google.com · abgerufen 02.11.2026.
10. Chrome for Developers: „Chrome UX Report (CrUX)“ – developer.chrome.com · abgerufen 02.11.2026.
11. Search Console-Hilfe: „Core Web Vitals-Bericht“ – support.google.com · abgerufen 02.11.2026.

Alle Quellen am 2. November 2026 abgerufen. Aussagen ohne belastbare Quelle sind im Text als Einschätzung gekennzeichnet; die Ziffern in eckigen Klammern verweisen auf die Nummern dieser Liste.