Polymarket: Manipuliertes Monitoring-Skript eines Dienstleisters leerte Wallets, 3,9 Millionen Dollar erstattet

Am 29. Oktober 2026 wurde ein Skript zur Leistungsmessung, das ein Dienstleister bereitstellte und das auf polymarket.com geladen wurde, durch Schadcode ersetzt. Es nutzte offene Sitzungen von Nutzern, um deren Positionen zu verkaufen und Guthaben abzuziehen. Polymarket erstattet insgesamt 3,9 Millionen Dollar und kontrolliert Drittanbieter-Skripte nun strenger.

Was geschah

In einem am 30. Oktober 2026 veröffentlichten Post-Mortem erklärt der Prognosemarkt Polymarket, er habe am 29. Oktober um 17:38 UTC unbefugte Aktivitäten auf Nutzer-Wallets festgestellt. Ursache war nicht der eigene Code: Ein Dienstleister, dessen Skript zur Leistungsmessung auf polymarket.com geladen wurde, war kompromittiert, und der Angreifer ersetzte das Skript durch eine Version, die sich gezielt gegen Polymarket-Nutzer richtete. Bei einem Teil der Personen, die die Seite in einem kurzen Zeitfenster an jenem Nachmittag geöffnet hatten, nutzte das Skript die aktive Sitzung, um Positionen zu verkaufen und Guthaben aus ihren Wallets zu überweisen.

Polymarket erstattet insgesamt 3,9 Millionen Dollar: 2,7 Millionen für den Diebstahl und 1,2 Millionen für Verluste durch die Handelspause. Zum Zeitpunkt der Veröffentlichung waren 95 % der betroffenen Wallets vollständig entschädigt. Wie viele Nutzer betroffen sind, sagt das Unternehmen nicht; es hat die Strafverfolgungsbehörden eingeschaltet.

Wie die Angreifer vorgingen

Die Website vertraute der Domain des Dienstleisters, also führten die Browser alles aus, was sie auslieferte. Laut einer Analyse von Hudson Rock erlaubte die Content Security Policy der Seite diesen Host; das manipulierte Skript las im Browser gespeicherte Anmeldedaten, fand den Handels-Client in der Seite, forderte Signaturen an und reichte Überweisungen an eine vom Angreifer kontrollierte Adresse ein. Laut The Record deuten die ersten Erkenntnisse des Dienstleisters auf eine Kompromittierung über seinen Domain-Registrar hin.

Was jetzt zu tun ist

1. Externe Skripte erfassen, etwa mit curl -s https://www.example.com/ | grep -oE 'src=[^ >]+', und nicht benötigte entfernen, zuerst auf Login-, Zahlungs- und Kundenkontoseiten.
2. Den Rest fixieren und prüfen: eine feste Version selbst hosten oder bei unveränderlichen Dateien Subresource Integrity setzen (Hash mit openssl dgst -sha384 -binary datei.js | openssl base64 -A), damit eine veränderte Datei abgelehnt wird.
3. Content Security Policy verschärfen: genaue Listen für script-src und connect-src, mit aktivierter Meldung von Verstößen. Einen Host zu erlauben, prüft nicht, was er ausliefert.
4. Änderungen überwachen: Hashes von Drittanbieter-Dateien regelmäßig berechnen und bei jeder Änderung alarmieren.
5. Reaktion vorbereiten: ein Skript binnen Minuten entfernen und alle Sitzungen zurücksetzen können, wie es Polymarket tat.
6. Eigene Domains schützen: Mehrfaktor-Authentifizierung und Registrar Lock bei den Registrar-Konten.

Unsere Einschätzung

Ein von einer fremden Domain geladenes Skript läuft mit denselben Rechten wie der eigene Code, in den Sitzungen Ihrer Kunden. Ein Analyse- oder Monitoring-Tag gilt selten als kritisch, hier reichte es, um Konten zu leeren. Weniger Drittanbieter-Skripte, fixierte Versionen und Integritätsprüfungen kosten wenig im Vergleich zu Erstattungen in Millionenhöhe.

Quellen

• Polymarket Status — Post-mortem of the 29 October 2026 incident
• The Record — Polymarket pledges to give $3.9 million back to victims after site compromise
• The Record — Polymarket confirms cyberattack involving third party
• Hudson Rock (Infostealers) — Polymarket breach alert: wallet-draining code found in a third-party script

Wie wir unsere Analysen auswählen, prüfen und schreiben →