Polymarket und das Skript eines Dienstleisters: was Cyber-Risikoträger daraus lernen

Thema der Woche vom 24. bis 31. Oktober 2026 · von cybercoverinsurance

Am 29. Oktober 2026 lud die Website von Polymarket rund eine Stunde lang ein Skript eines Dienstleisters in die Sitzungen ihrer Nutzer, das nicht mehr das ursprüngliche war. Das Skript diente dazu, die Ladeleistung der Seiten zu messen. Der ausgetauschte Code nutzte den Trading-Client der Website selbst, um Guthaben von Hunderten Konten auf eine einzige Wallet zu verschieben. Unabhängige Schätzungen sprechen von rund 2,7 Millionen Dollar.

Die Summe ist klein im Vergleich zu anderen Ereignissen derselben Woche. Der Fall zählt aus einem anderen Grund. Der Einstiegspunkt war weder ein System des Versicherten noch ein kritischer Dienstleister, sondern ein Monitoring-Werkzeug, das kaum ein Underwriting-Fragebogen aufführt. Für Cyber-Risikoträger lautet die Frage, wie viele Dienstleister Code in den sensibelsten Seiten ihrer Versicherten ausführen, und wer sie kontrolliert.

Was bekannt ist

Der Vorfall. Polymarket teilte mit, ein Drittanbieter sei «kompromittiert» worden, der Fall sei den Strafverfolgungsbehörden gemeldet und betroffene Nutzer würden entschädigt. Polymarket nannte weder den Anbieter noch den entwendeten Betrag (The Record). Das Threat-Intelligence-Unternehmen Hudson Rock identifizierte den Anbieter als DebugBear, ein britisches Unternehmen für Web-Performance-Monitoring, dessen Real-User-Monitoring-Skript auf polymarket.com eingebunden war. DebugBear bestätigte, von einem «laufenden Sicherheitsvorfall» betroffen zu sein, und forderte seine Kunden auf, den eigenen Code von ihren Websites zu entfernen (ICOBench).

Der Ablauf. Nach der Rekonstruktion von Ohey wurde das bösartige Skript ab etwa 16:54 UTC am 29. Oktober in angemeldeten Sitzungen ausgeliefert. Die ersten Mittel erreichten die Ziel-Wallet um 17:10 UTC. Polymarket veröffentlichte um 17:59 UTC eine Version der Website ohne das Skript. DebugBear meldete den Vorfall um 18:00 UTC (Ohey). Polymarket schaltete die Plattform um 18:05 UTC in einen Modus, in dem nur noch Orders storniert werden konnten, und nahm den Handel um 19:00 UTC wieder auf (ICOBench). Betroffen ist die internationale Plattform (The Record).

Wie der Code arbeitete. Hudson Rock hat das Skript analysiert. Der Code las Kontodaten aus dem Browser, fand den bereits in der Seite geladenen Trading-Client, prüfte die Salden und übertrug oberhalb einer Mindestschwelle die Positionen oder verkaufte sie, um anschließend den Erlös zu übertragen. Die Signaturen wurden über das bereits in der Sitzung aktive Signiersystem angefordert und an den Relay-Dienst von Polymarket gesendet. Die Autoren fanden keine Routinen, die private Schlüssel oder Wiederherstellungsphrasen exportierten (Hudson Rock). Ohey weist darauf hin, dass alle vom Skript angesprochenen Adressen außer denen von DebugBear bereits von der Content Security Policy von Polymarket erlaubt waren.

Die Zahlen. Es handelt sich um Schätzungen Dritter, nicht um Angaben des Unternehmens. Bitquery nennt rund 2,73 Millionen Dollar aus 737 Konten zwischen 17:10 und 18:10 UTC. GoPlus nennt rund 2,71 Millionen aus 731 Adressen. Der mittlere Verlust (Median) pro Opfer liegt bei 171 Dollar (ICOBench). Polymarket hat keine Gesamtsumme veröffentlicht.

Was nicht bekannt ist. Wie die Angreifer die Auslieferungsinfrastruktur von DebugBear erreicht haben, ist nicht geklärt (Safestate). Wie viele andere Websites dasselbe Skript luden, ist nicht bekannt. Hudson Rock fand keine Belege für eine breitere Kompromittierung, die andere DebugBear-Kunden betroffen hätte (The Record). Niemand hat den Angriff zugeordnet.

Der Dienstleister, den niemand aufführt

Ein Monitoring-Skript hat dieselben Befugnisse wie der Code der Website. Ein Browser unterscheidet nicht zwischen Code, den der Versicherte geschrieben hat, und Code, der von einem Dienstleister geladen wird. Einmal in der Seite, liest das Drittanbieter-Skript, was die Website liest, und kann anfordern, was die Website anfordern kann. Im Fall Polymarket mussten keine Zugangsdaten gestohlen werden: Das Skript nutzte die Sitzung, die der Nutzer bereits geöffnet hatte.

Fragebögen schauen woanders hin. Fragen zur Supply Chain konzentrieren sich meist auf IT-, Cloud- und Managed-Software-Anbieter. Analyse-Tools, Tag-Manager, Chat, Bewertungs-Widgets und Performance-Monitoring bleiben außen vor, weil sie als Marketing oder Nebenwerkzeuge gelten. Gerade diese Kategorie hat die wenigsten Kontrollen und den meisten Zugriff auf Login-, Zahlungs- und Bestätigungsseiten.

Es gibt bereits einen Standard, aus dem sich Fragen ableiten lassen. Für Kartenzahlungsseiten verlangt PCI DSS 4.0 ein Inventar aller Skripte mit einer Begründung für jedes, ein Verfahren zu ihrer Autorisierung und eines zur Sicherung ihrer Integrität (Anforderung 6.4.3). Außerdem verlangt er einen Mechanismus, der unautorisierte Änderungen an der Seite, wie sie beim Browser ankommt, mindestens alle sieben Tage meldet (Anforderung 11.6.1). Beide sind seit dem 31. März 2025 verpflichtend (PageCrawl). Polymarket verarbeitet keine Karten, doch die Logik gilt für jede Seite, auf der ein Nutzer eine Wertübertragung autorisiert.

Welche Police greift

Der Schaden liegt bei den Kunden, die Erstattung ist eine Entscheidung des Versicherten. Die entwendeten Mittel gehörten den Nutzern. Polymarket hat zugesagt, sie zu erstatten. Für Risikoträger ist die Unterscheidung wichtig. Cyber-Policen decken in der Regel eine festgestellte Haftung gegenüber Dritten oder Schadenersatzansprüche, nicht freiwillige Zahlungen vor jedem Anspruch und ohne Zustimmung des Versicherers. Eine spontane Erstattung, auch wenn sie für den Ruf sinnvoll ist, kann beim Versicherten verbleiben, wenn die Police keine eigene Deckung dafür vorsieht.

Die Vertrauensschadendeckung hängt davon ab, wer die Mittel verwahrte. Deckungen für Computerbetrug in Vertrauensschadenpolicen setzen meist einen Verlust von Geld oder Vermögenswerten des Versicherten voraus, oder von Werten, die er für Dritte hält. Hier lagen die Mittel in Wallets der Nutzer, und die Signaturen wurden in deren eigener Sitzung angefordert. Viele Vertrauensschadenpolicen schließen zudem Kryptowährungen aus oder decken sie nur über eigene Erweiterungen. Der Schadenregulierer muss klären, ob Polymarket diese Mittel verwahrte, und in welcher Form.

Der Dienstleister haftet, der Vertrag begrenzt die Haftung. DebugBear kann von Kunden in Anspruch genommen werden. Die maßgebliche Deckung ist die IT-Berufshaftpflicht (Tech E&O) des Dienstleisters, sofern vorhanden. SaaS-Verträge dieser Art begrenzen die Haftung jedoch häufig auf die Jahresgebühren. Ein Regress des Versicherers von Polymarket dürfte wenig einbringen.

Die Unterbrechung war kurz. Der Handel war rund eine Stunde ausgesetzt. Die zeitlichen Selbstbehalte von Betriebsunterbrechungsdeckungen liegen meist bei mehreren Stunden. Die eigentlichen Kosten entstehen hier durch Incident Response, Forensik, Kommunikation mit den Nutzern und Erstattungen, nicht durch den Stillstand.

Kumul: ein Skript, viele Websites

Dieselbe Datei kann Tausende Seiten erreichen. Ein Skript, das über das Content-Netz eines Dienstleisters ausgeliefert wird, wird von allen Websites geladen, die es einbinden. Im Fall DebugBear fanden die Forscher den bösartigen Code nicht bei anderen Kunden, und der Code war auf Polymarket zugeschnitten. Dieselbe Position hätte mit generischem Code jedoch alle Kunden des Dienstleisters gleichzeitig treffen können.

Es ist ein Schadenszenario, das kartiert werden muss. Für ein Portfolio lautet die Frage nicht nur, welche Cloud-Anbieter sich die Versicherten teilen. Sondern auch, welche Drittanbieter-Skripte gleichzeitig auf den Login- und Zahlungsseiten vieler Versicherter auftauchen. Tag-Manager, Analyse-Tools und Consent-Plattformen sind auf sehr vielen Websites verbreitet. Ein Ereignis bei einem dieser Anbieter würde korrelierte Schäden aus Betrug, Verletzung personenbezogener Daten und Haftung gegenüber Kunden auslösen.

Die Daten lassen sich von außen beobachten. Anders als viele interne Abhängigkeiten sind die Skripte, die eine öffentliche Seite lädt, für jeden sichtbar, der sie öffnet. Ein externer Scan der Login- und Zahlungsseiten der Antragsteller kann zeigen, welche Anbieter im Portfolio wiederkehren, noch vor dem Fragebogen.

Kontrollen und Reaktionszeit

Die Content Security Policy reicht allein nicht aus. Polymarket hatte eine Policy, doch das Skript nutzte bereits erlaubte Adressen, nämlich die der Website selbst (Ohey). Eine Policy begrenzt, wohin Code Daten senden darf, nicht, was er innerhalb der Seite tun kann.

Die Integrität der Dateien ist die direkteste Kontrolle. Subresource Integrity blockiert ein Skript, wenn sein Inhalt nicht mehr dem erwarteten Hash entspricht. Hudson Rock nennt sie unter den Maßnahmen, zusammen mit dem Entfernen unnötiger Drittanbieter-Skripte von Trading- und Signierseiten. Die Grenze ist praktisch: Dienstleister aktualisieren ihre Skripte oft, und der Hash muss über einen kontrollierten Prozess nachgezogen werden.

Eine Stunde hat gereicht. Zwischen dem Eingang der ersten Mittel und der Entfernung des Skripts vergingen rund 50 Minuten (Ohey). Die Reaktion kam in weniger als einer Stunde und verhinderte den Verlust dennoch nicht. Bei automatischen und unumkehrbaren Transaktionen zählen Kontrollen, die vor der Signatur greifen: Limits pro Sitzung, zusätzliche Bestätigungen für ungewöhnliche Vorgänge, Sperren für Übertragungen an neue Empfänger.

Was in die Vertragsverlängerung gehört

Die Fragen gelten für jeden Versicherten mit Login-, Zahlungs- oder Freigabeseiten für Übertragungen.

Auswirkung für VersichererMittel

Der Einzelschaden blieb begrenzt, doch derselbe Angriffsweg bei einem weit verbreiteten Dienstleister würde korrelierte Schäden in vielen Portfolios auslösen.

Auf Portfolioebene ist eine Karte der wiederkehrenden Skript-Anbieter auf den sensiblen Seiten der Versicherten die nützliche Arbeit. Tauchen drei oder vier Anbieter in einem Großteil des Portfolios auf, ist das ein Kumul, der wie der großer Cloud-Anbieter zu behandeln ist, mit eigenen Szenarien und Limits.

Quellen

• The Record – Polymarket bestätigt Angriff auf einen Drittanbieter
• ICOBench – Schadensschätzungen, Zahl der Konten und Handelsaussetzung
• Ohey – Ablauf des Angriffs und Rolle der Content Security Policy
• Hudson Rock – Analyse des bösartigen Codes und Empfehlungen
• Safestate – offene Fragen zur Kompromittierung von DebugBear
• PageCrawl – PCI-DSS-4.0-Anforderungen 6.4.3 und 11.6.1 zu Skripten auf Zahlungsseiten