15.579 infizierte Websites: Was Report URI meldet und was unsere drei Seiten dagegen haben

Scott Helme, Gründer von Report URI, schrieb am 6. November 2026, sein Dienst habe 15.579 Websites gefunden, die gerade Schad-JavaScript ausliefern. Zusammen kämen sie nach vorsichtiger Schätzung auf mehr als 135 Millionen Besuche im Monat. Das Problem seien nicht die Funde, sondern die Benachrichtigung: Die meisten Mails an Betreiber blieben unbeantwortet.

Eine Seite mit Schad-JavaScript lädt Code, den der Betreiber nie freigegeben hat. Der Code liest Kartendaten an Zahlungsseiten mit (Magecart), zeigt falsche Abfragen "Beweise, dass du ein Mensch bist", die Schadsoftware installieren (ClickFix), nutzt Lücken in iOS-Versionen oder leitet Besucher um. Der Browser führt ihn mit den Rechten der Seite aus. Dagegen helfen eine Content Security Policy, Subresource Integrity und ein Inventar aller geladenen Skripte.

Was Report URI beschreibt

Report URI nennt vier Wege, wie das Skript auf die Seite kommt:

1. Direkte Kompromittierung, meist über eine Lücke in WordPress oder Ähnlichem, bei der die eigenen JS-Dateien verändert werden.
2. Lieferkette: Eine Drittanbieter-Datei wird infiziert und dann von jeder Seite geladen, die sie einbindet.
3. XSS in der Seite selbst.
4. "DeadTag": Eine Gruppe kauft abgelaufene Domains, von denen Seiten noch Skripte laden, und liefert dort Schadcode aus. Report URI beschreibt die Gruppe in einem eigenen Beitrag zu DeadTag.

Besonders viele Funde stammen laut Helme von regional starken Seiten unter .de, .fr und .es. Die Liste hat er bewusst nicht veröffentlicht. Er begründet das mit dem Schutz der Opfer, der Schwierigkeit, aus Blocklisten wieder herauszukommen, und der Gefahr, Angreifern eine Zielliste zu liefern. Das bedeutet auch: Die Zahl 15.579 ist eine Anbieteraussage, die niemand außerhalb von Report URI nachrechnen kann.

Der Anbieter verkauft Überwachung dieser Art. Helmes Beitrag trägt oben die Kennzeichnung "Sponsored by Report URI" und bietet am Ende Zugang zu den Threat-Intelligence-Daten an. Das ist kein Grund, die Funde zu bezweifeln. Es ist ein Grund, sie als Anbieterangabe zu behandeln.

Was wir an unseren Seiten gemessen haben

Wir haben am 9. November 2026 gegen 10:36 UTC die Startseiten von senn-tech.com, senn-gruppe.com und senn-logistik.com je einmal abgerufen, aus dem Büronetz, und die Antwortköpfe und das HTML ausgewertet. Gezählt sind script-Tags mit absoluter Adresse.

Messträger: curl mit Browser-Kennung, Startseite je Domain, 9.11.2026. Skripte, die erst zur Laufzeit nachgeladen werden, sind in der Zählung nicht enthalten. Bei senn-tech.com und senn-logistik.com kam der CSP-Kopf in der Antwort doppelt an, bei senn-gruppe.com einmal; welche Stufe ihn setzt, haben wir nicht geklärt. Es ist eine einzelne Messung, die Werte sind vorläufig.

Zwei Ergebnisse gelten für die statisch eingebetteten Skript-Tags der Startseiten. Erstens kommen diese Skripte von Adressen, die zu uns gehören; DeadTag trifft vor allem Seiten mit Skripten von fremden, aufgegebenen Domains. Zweitens trägt keiner dieser Tags ein integrity-Attribut. Bei Skripten aus der eigenen CDN-Zone bietet der Hash zusätzlichen Schutz, falls die Zone oder der Ursprung verändert wird. Auf senn-gruppe.com fehlt in der Richtlinie die Begrenzung der Skriptquellen ganz, auf den beiden anderen Seiten lässt 'unsafe-inline' eingeschleusten Inline-Code zu. Laut MDN zur Content Security Policy sollten Entwickler 'unsafe-inline' meiden, weil es einen großen Teil des Zwecks einer CSP aufhebt: Inline-JavaScript ist einer der häufigsten XSS-Wege.

Das sind offene Punkte, keine Vorfälle. Ob und wann wir sie schließen, ist noch offen. Für Next.js-Seiten kommt eine Umstellung auf Nonces in Frage; die Auswirkungen auf unsere Analytik und den Shop haben wir noch nicht gemessen.

Was ein Betreiber sofort tun kann

Skripte inventarisieren und prüfen, ob alle Hosts noch dem erwarteten Anbieter gehören. Eigene Kopien statt Fremdquellen verwenden, wo es geht. Unsere Empfehlung: die Richtlinie zuerst im Report-Only-Modus laufen lassen und die Berichte einige Wochen lesen, bevor sie blockiert (MDN beschreibt den Modus, die Dauer ist unsere Einschätzung). Wo ein fremdes Skript bleiben muss, setzt man den Hash laut MDN zu Subresource Integrity per integrity-Attribut.

Wer das für Shop und Website durchgehen lassen will, findet unser Angebot unter Leistungen. Wie eine Lieferkette wirklich bricht, zeigt der Beitrag npm-Lieferkette und GitLab-Regex; weitere Beiträge sammelt der Hub Security und Datenschutz.

Weiterführende Quellen

• Scott Helme, 6.11.2026: We Know 15,579 Websites Are Infected. How Do We Tell Them?
• Report URI zu DeadTag: blog.report-uri.com
• MDN, Content Security Policy: developer.mozilla.org
• MDN, Subresource Integrity: developer.mozilla.org