Adform-Hack: Wer haftet für fremde Website-Skripte?

Adform kompromittiert: Ein manipuliertes Tracking-Skript ersetzte Krypto-Adressen

Michael Dobler

Autor Dr. Web

4. August 2026

2 Min. Lesezeit

Adform hat am 27. Juli 2026 Schadcode im eigenen Tracking-Skript entdeckt, das rund 14.000 Unternehmen in ihre Websites einbinden. Der Code ersetzte im Browser der Besucher kopierte Bitcoin- und Ethereum-Adressen durch die der Angreifer. Website-Betreiber haften nach EuGH-Recht für jedes fremde Skript im eigenen Quelltext.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Der Kopenhagener Anbieter Adform lieferte eine manipulierte Fassung seiner Datei trackpoint-async.js aus, die auf jeder Kundenseite mitläuft. Der Sicherheitsforscher Kevin Beaumont fand darin einen Beacon auf einen fremden Server.

Das Wichtigste in Kürze

Adform lieferte am 27. Juli 2026 eine manipulierte Fassung des Tracking-Skripts trackpoint-async.js aus.
Der Code las die Zwischenablage nicht aus, sondern klinkte sich in den Kopiervorgang ein. Dafür fragt kein Browser um Erlaubnis.
Subresource Integrity schützt hier nicht, weil der Prüfwert bei jedem regulären Update des Anbieters bricht.
Ab dem 11. September 2026 gilt die Meldepflicht des Cyber Resilience Act.

Was lief auf den Kundenseiten?

Klemmbrett mit Zugangsschlüsseln, Notiz, orangefarbenem Klebezettel und Schild — Malware-Code ersetzte Bitcoin-, Ethereum- und Tron-Adressen in der Zwischenablage durch Angreifer-Adressen. Browser-Cache leeren und Adressen vor Überweisungen vergleichen

Der eingeschleuste Code prüfte laufend, ob im Zwischenspeicher eine gültige Bitcoin-, Ethereum- oder Tron-Adresse lag. An ihre Stelle setzte das Skript eine Adresse der Angreifer. Adform bestätigt diesen Ablauf. Betroffene sollen den Browser-Cache leeren und jede kopierte Wallet-Adresse vor einer Überweisung vergleichen.^[1]

Adform erklärt, kein Hinweis deute darauf hin, dass der Schadcode IP-Adressen oder besuchte Seiten an Dritte übermittelt habe.^[1] Beaumont dokumentierte dagegen Aufrufe an den Server 84.32.102.230, die Hostnamen und Pfad der besuchten Seite trugen.^[2] Diesen Widerspruch hat bislang niemand aufgelöst.

Warum warnt der Browser nicht?

Das Auslesen der Zwischenablage über navigator.clipboard verlangt eine ausdrückliche Freigabe im Browser. Ein Skript, das sich in das Kopier-Ereignis der Seite einklinkt, braucht keine. In diesem Handler darf Seitencode den Inhalt synchron überschreiben, weil der Browser den Kopierbefehl bereits als Zustimmung wertet.^[3] Genau diese Asymmetrie im Berechtigungsmodell macht den Angriff lautlos.

Gegen manipulierte Fremddateien existiert ein Standard, Subresource Integrity: Der Betreiber hinterlegt eine Prüfsumme im Script-Tag. Abweichende Dateien verweigert der Browser dann. Ein Tracking-Skript aktualisiert der Anbieter allerdings laufend, sodass die Prüfsumme bei jedem legitimen Update bricht. Auch die Wartezeit vor automatischen Updates, mit der GitHub seine Paketaktualisierungen entschärft hat, greift bei einer Datei nicht, die der Anbieter live austauscht.

Im Juni 2024 wies der Sicherheitsanbieter Sansec nach, dass der neue Eigentümer der Bibliothek Polyfill.io Schadcode über mehr als 100.000 Websites verteilte.^[4] Derselbe Hebel wirkt beim laufenden Angriff auf die npm-Pakete rund um Keyv. Ein einziger Baustein erreicht tausende Seiten.

27.07.2026

Tag, an dem Adform den Schadcode entdeckte und entfernte

14.000

Unternehmen binden das Skript nach Beaumonts Analyse ein

3 Sekunden

Takt, in dem der Code die kopierte Wallet-Adresse erneut ersetzte

100.000+

Websites traf 2024 der Polyfill.io-Angriff nach demselben Muster

11.09.2026

Ab diesem Tag gilt die Meldepflicht des Cyber Resilience Act

Was ein fremdes Skript im Frontend absichert

Greift hier nicht

Subresource Integrity prüft eine feste Prüfsumme. Ein Anbieter-Skript ändert sich laufend, deshalb bricht der Wert bei jedem regulären Update.

Greift ebenfalls nicht

Eine Content Security Policy erlaubt die Anbieter-Domain ausdrücklich. Manipulierter Code von genau dieser Domain passiert die Regel unbehelligt.

Verkleinert die Fläche

Server-Side Tagging holt die Daten über die eigene Domain. Jedes Skript, das dadurch aus dem Frontend verschwindet, kann dort auch nichts mehr überschreiben.

Adform hat den Code entfernt, die Haftung bleibt trotzdem bei jedem Betreiber, der die Datei eingebunden hat. Ein fremdes Skript im eigenen Quelltext übergibt die Kontrolle über den Browser des Besuchers an einen Dritten.
— Markus Seyfferth, Chefredakteur Dr. Web

Wer haftet für ein fremdes Skript?

Der Europäische Gerichtshof hat 2019 im Verfahren Fashion ID entschieden, dass ein Website-Betreiber für ein eingebettetes Drittanbieter-Plugin gemeinsam verantwortlich ist.^[5] Der Datenabfluss beim Besucher ist damit auch der Vorfall des Shops, der das Skript ausgeliefert hat. Dass eingebettete Marketing-Pixel den Betreiber vor die Aufsicht bringen, zeigt der Fall Hims & Hers. Die Meldefrist von 72 Stunden nach Artikel 33 DSGVO läuft ab Kenntnis, nicht ab Bestätigung durch den Anbieter.

Ab dem 11. September 2026 kommt der Cyber Resilience Act dazu: Hersteller digitaler Produkte melden aktiv ausgenutzte Schwachstellen binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als Bericht an ENISA sowie das zuständige CSIRT.^[6] Für die eigene Website heißt das zunächst, das Skript-Inventar des Frontends zu erfassen. Verzichtbare Fremdskripte lassen sich danach auf Server-Side Tagging umstellen, ohne die Messwerte aus dem First-Party-Tracking nach dem Cookie-Aus zu verlieren. Warum diese Inventur auf den Vorstandstisch gehört und nicht in die IT-Warteschlange, begründet unser Beitrag zur Cybersecurity als Chefsache.