Polymarket: Kompromittiertes Monitoring-Skript räumt Nutzerkonten leer
Über ein gekapertes Performance-Skript von DebugBear lief bei Polymarket Schadcode, der eingeloggte Sitzungen missbrauchte. Schaden: rund 2,2 bis 2,7 Mio. USD. Polymarket will alle Betroffenen entschädigen.
Schon wieder ein Lieferkettenangriff, diesmal über ein Skript eines Drittanbieters. Ein Lieferkettenangriff (Supply-Chain-Angriff) richtet sich nicht direkt gegen das Ziel. Die Angreifer kompromittieren einen Zulieferer, dem das Ziel vertraut, und kommen so hinein. Bei Polymarket, der Plattform für Wetten auf Ereignisse („Prediction Markets“), hat das am 29. Oktober 2026 Geld gekostet, und zwar das Geld der Nutzer.
Was passiert ist
Am Donnerstagnachmittag (US-Ostküstenzeit) meldeten Nutzer Abbuchungen, die sie nicht selbst ausgelöst hatten. Polymarket schaltete die internationale Börse erst in den Modus „cancel-only“: Man konnte nur noch offene Orders stornieren, aber nicht mehr handeln. Außerdem wurden die sogenannten Relayer-Aktionen pausiert, also der Dienst, der Transaktionen im Namen der Nutzer an die Blockchain weiterreicht. Nach etwa einer Stunde lief der Handel wieder. Laut BleepingComputer galt der Vorfall um 15:05 Uhr Ostküstenzeit als behoben. Die US-Plattform von Polymarket war nach SecurityWeek offenbar nicht betroffen.
Polymarket selbst nennt den Zulieferer bis heute nicht. Das Unternehmen schreibt nur, einer seiner Drittanbieter sei kompromittiert worden, und es habe die Sache an die Strafverfolgung übergeben. Sicherheitsforschende von Hudson Rock und GoPlus haben die Spur aber zu DebugBear zurückverfolgt, einem britischen Anbieter für Website-Performance-Monitoring. Der Schadcode kam über dessen RUM-Skript. RUM steht für Real User Monitoring: Ein kleines JavaScript misst im Browser echter Besucher, wie schnell eine Seite lädt. DebugBear hat einen „laufenden Sicherheitsvorfall“ bestätigt, externe Incident Responder hinzugezogen und Kunden aufgefordert, das RUM-Snippet von ihren Seiten zu entfernen. Hudson Rock fand einen Produktions-Build von Polymarket mit dem Zeitstempel 17:59 UTC, dessen Änderungsnotiz das Entfernen des DebugBear-Skripts vermerkt.
Wie der Schadcode vorging
Bemerkenswert ist, was das Skript nicht getan hat. Hudson Rock fand keinen Code, der Passwörter, Seed-Phrasen oder private Schlüssel abgreift. Das Skript prüfte stattdessen, ob jemand bei Polymarket eingeloggt war, und nutzte dann die bestehende Sitzung. Je nach Kontotyp verkaufte es die Positionen des Nutzers und leitete den Erlös weiter oder schickte die Positions-Token direkt an eine Adresse der Angreifer. Anweisungen holte es sich von DebugBear-Infrastruktur und meldete auch Kontodaten dorthin zurück. Wer eingeloggt war, für den sah das aus Sicht der Plattform wie eigenes Handeln aus.
Wie groß der Schaden ist
Die Zahlen gehen je nach Quelle auseinander, und Polymarket hat keine eigenen veröffentlicht:
- Hudson Rock sah auf der Angreifer-Wallet rund 2,19 Mio. USD, bezeichnet das aber ausdrücklich als nicht verifiziert.
- BleepingComputer hat verfolgt, dass von dieser Wallet etwa 28,6 Mio. POL (rund 2,57 Mio. USD) an drei weitere Wallets gingen.
- GoPlus schätzt rund 2,71 Mio. USD über 710 Einzahlungs-Wallets und 731 Adressen, betont aber, dass die Zahl der Adressen nicht der Zahl der Opfer entspricht.
Was sich seit meinem Post geändert hat: Dort stand noch allgemein „ein Website-Monitoring-Tool“. Inzwischen ist der Anbieter durch die Forschenden benannt, der Handel läuft wieder, und Polymarket hat zugesagt, alle Betroffenen vollständig zu entschädigen. Wie diese Entschädigung abläuft, ist noch offen. Unklar ist auch, wie die Angreifer das DebugBear-Skript manipulieren konnten und ob andere DebugBear-Kunden gezielt angegriffen wurden. Hudson Rock sieht dafür bisher keine Hinweise. Für Polymarket ist das außerdem nicht der erste Fall: Schon im Juni hatte die Plattform einen anderen Drittanbieter-Vorfall mit eingeschleustem Frontend-Skript gemeldet, damals mit rund 3 Mio. USD Schaden.
Warum das wichtig ist
Jedes fremde Skript, das du auf deiner Seite einbindest, läuft mit denselben Rechten wie dein eigener Code. Ein Performance-Tracker sieht dieselbe Sitzung, dieselben Buttons und dieselben API-Aufrufe wie die eigentliche Anwendung. Bei einer Seite, auf der Nutzer mit einem Klick Geld bewegen, ist das ein Generalschlüssel. Da das Skript keine Zugangsdaten stahl, sondern die laufende Sitzung missbrauchte, hätten auch starke Passwörter und Zwei-Faktor-Anmeldung hier nichts genützt.
Was du tun solltest
Als Polymarket-Nutzer:
- Prüfe deinen Kontoverlauf auf Verkäufe und Transfers vom 29. Oktober, die du nicht selbst ausgelöst hast, und melde sie Polymarket für die angekündigte Entschädigung.
- Schau dir Wallet-Freigaben an und widerrufe, was du nicht brauchst. Laut den Analysen lief der Angriff zwar über die Sitzung und nicht über Freigaben, aufräumen schadet aber nie.
- Logge dich nach dem Handeln aus, statt Sitzungen dauerhaft offen zu lassen.
Als Website-Betreiber:
- Wer DebugBear RUM einsetzt: Snippet entfernen, wie der Anbieter selbst empfiehlt.
- Zähle, welche fremden Skripte bei dir laufen, und streiche alles, was du nicht wirklich brauchst. Monitoring und Analyse gehören nicht auf Seiten, auf denen Geld bewegt wird, oder nur in stark eingeschränkter Form.
- Setze eine Content Security Policy (CSP), also eine Regel im HTTP-Header, die festlegt, von welchen Quellen Skripte laden und wohin sie Daten senden dürfen. Das begrenzt den Schaden, verhindert ihn aber nicht, wenn die erlaubte Quelle selbst kompromittiert ist.
- Wo möglich, fremde Skripte selbst hosten und mit Subresource Integrity (SRI) einbinden: Der Browser prüft dann eine Prüfsumme und führt veränderten Code nicht aus.
Deine Website ist nur so sicher wie die Skripte, die sie lädt.