Polymarket verliert 2,7 Mio. USD nach DebugBear-Skript-Hijack durch DNS-Kompromittierung

Am 29. Oktober 2026 nutzten Hacker eine Schwachstelle in der Lieferkette der Prognosemarkt-Plattform Polymarket aus, um etwa 2,7 Millionen US-Dollar aus Benutzer-Wallets zu stehlen. Der Angriff basierte auf einem kompromittierten Drittanbieter-Skript des Performance-Monitoring-Anbieters DebugBear, das es ermöglichte, schädlichen Code innerhalb der Browser angemeldeter Trader auszuführen. Polymarket hat seitdem mit den Rückerstattungen für betroffene Nutzer begonnen und den Handel pausiert, um seine Infrastruktur abzusichern.

Was passiert ist

Der Vorfall begann, als Angreifer die DNS-Einträge von DebugBear über dessen Domain-Registrar kompromittierten. Dies erlaubte ihnen, Anfragen für eine bestimmte JavaScript-Datei, die von Polymarket verwendet wird, auf einen Server unter ihrer Kontrolle umzuleiten. Anstatt das legitime Real User Monitoring (RUM)-Skript bereitzustellen, das die Seitenladezeiten misst, lieferten die Angreifer eine bösartige Version, die speziell auf die Implementierung von Polymarket zugeschnitten war. Forscher bei Hudson Rock identifizierten die ausgetauschte Datei und stellten fest, dass DebugBear zwar einzigartige Skripte für jeden Kunden bereitstellt, in diesem Fall jedoch nur die Kopie von Polymarket ersetzt wurde.

Sobald das schädliche Skript in den Browsern der Nutzer geladen war, scannte es aktiv nach Kontodetails und Handels-API-Schlüsseln, die in der Sitzung gespeichert waren. Der Code exfiltratierte keine privaten Schlüssel oder Passwörter direkt. Stattdessen manipulierte er die bestehende authentifizierte Sitzung, um nicht autorisierte Trades zu platzieren. Für Nutzer, die über Krypto-Wallets eingeloggt waren, verschob das Skript Positionen direkt an Angreifer-kontrollierte Adressen. Bei E-Mail-basierten Konten verkaufte es Positionen zu zunehmend ungünstigeren Preisen, bevor die daraus resultierenden Gelder abgezogen wurden. Eine Blockchain-Analyse von Ohey zeigte, dass zwischen 17:10 und 18:02 UTC 28,6 Millionen POL-Token im Wert von rund 2,64 Millionen US-Dollar an eine Hacker-Wallet übertragen wurden.

Polymarket erkannte die Anomalie und veröffentlichte um 17:38 UTC ein Status-Update. Bis 18:05 UTC hatte die Plattform in den „Nur-Stornierungs“-Modus gewechselt, alle Relayer-Aktionen pausiert und das schädliche Skript entfernt. Das Unternehmen leerte alle Caches, setzte aktive Login-Sitzungen zurück und meldete den Fall den Strafverfolgungsbehörden. Stand 30. Oktober hatte Polymarket 689 der 726 betroffenen Wallets vollständig entschädigt, während die restlichen 37 noch bearbeitet werden. Das Unternehmen verteilt zudem zusätzliche 1,19 Millionen US-Dollar an etwa 5.500 Wallets, die Verluste während der Handelspause oder aufgrund von Positionsliquidationen erlitten hatten, was die Gesamtentschädigung auf 3,9 Millionen US-Dollar bringt.

Wie es funktioniert

Der Angriff beruhte auf dem Missbrauch des Vertrauensverhältnisses zwischen Browser, Website und dem Wallet-Signer des Nutzers. Das schädliche Skript operierte vollständig im Kontext des offenen Polymarket-Tabs des Opfers. Es griff auf Handels-API-Schlüssel zu, die im Browser-Speicher abgelegt waren, konnte diese aber nicht allein zur Ausführung von Trades nutzen, da Polymarket für jede Order eine kryptografische Signatur vom Wallet des Nutzers verlangt.

Um dies zu umgehen, interagierte das Skript mit den Polymarket-Oberflächenelementen, die für die Auftragsplatzierung zuständig sind, sowie mit dem Signer-Objekt, das Transaktionen genehmigt. Es automatisierte effektiv den Signaturprozess, indem es Anfragen auslöste, die der Wallet-Anbieter dem Nutzer möglicherweise präsentieren würde. Die Geschwindigkeit und Automatisierung deuten jedoch darauf hin, dass einige Signaturen ohne explizites Bewusstsein des Nutzers genehmigt wurden oder dass die Sitzungsregeln des Wallet-Anbieters gebündelte Anfragen zuließen. Das Skript übergab diese signierten Anfragen dann an den Relayer von Polymarket, der sie an die Blockchain sendete. Diese Methode ermöglichte es den Angreifern, Gelder zu bewegen, ohne jemals im Besitz des privaten Schlüssels oder der Seed-Phrase des Nutzers zu sein.

Wichtige Details

• Angriffsvektor: Kompromittierte DNS-Einträge beim Domain-Registrar von DebugBear leiteten ein spezifisches Kundenscript auf einen bösartigen Server um.
• Finanzielle Auswirkung: Etwa 2,64 Millionen US-Dollar in POL-Token wurden in weniger als einer Stunde aus 33 Wallets gestohlen; die Gesamtrückerstattung beläuft sich auf 3,9 Millionen US-Dollar.
• Zielumfang: Erste Erkenntnisse deuten darauf hin, dass der Angriff nur das spezifische DebugBear-Skript von Polymarket betraf, nicht die gesamte DebugBear-Kundenbasis.
• Technische Methode: Das Skript nutzte vorhandene Sitzungs-API-Schlüssel und löste Wallet-Signaturen für nicht autorisierte Trades aus, anstatt Zugangsdaten zu stehlen.
• Reaktionszeit: Polymarket identifizierte das Problem und pausierte den Handel innerhalb von etwa 30 Minuten nach den ersten nicht autorisierten Überweisungen.
• Aktueller Status: DebugBear hat Kunden geraten, seinen Embed-Code zu entfernen, und seine CDN-Adresse hatte am 1. November keinen DNS-Eintrag mehr.

Warum das wichtig ist

Dieser Vorfall verdeutlicht das kritische Risiko, das darin besteht, Drittanbieter-JavaScript auf Seiten zu laden, die sensible Finanzoperationen durchführen. Selbst seriöse Anbieter wie DebugBear können zu Einfallstoren werden, wenn ihre Infrastruktur, wie z. B. DNS-Einträge, kompromittiert wird. Für Entwickler, die Fintech- oder Krypto-Anwendungen erstellen, reicht es nicht aus, sich allein auf den Ruf eines Anbieters zu verlassen. Der Angriff zeigt, dass eine Kompromittierung der Lieferkette traditionelle Perimetersicherheit umgehen kann, da der schädliche Code mit denselben Berechtigungen wie die Anwendung selbst ausgeführt wird.

Darüber hinaus zeigt der Mechanismus des Missbrauchs, dass der Schutz privater Schlüssel nicht ausreicht. Wenn ein Angreifer die Frontend-Logik so manipulieren kann, dass gültige Signaturen vom Wallet des Nutzers ausgelöst werden, kann er Gelder abziehen, ohne jemals auf das Schlüsselmaterial zuzugreifen. Dies verschiebt den Sicherheitsfokus von reinem Schutz der Zugangsdaten hin zu strengen Integritätsprüfungen für allen Client-Side-Code. Es unterstreicht die Notwendigkeit defensiver Programmierpraktiken, die einschränken, worauf Drittanbieter-Skripte innerhalb einer authentifizierten Sitzung zugreifen und was sie tun dürfen.

Was Sie tun können

• Implementieren Sie Subresource Integrity (SRI)-Hashes für alle Drittanbieter-Skripte, um sicherzustellen, dass der Browser Dateien ablehnt, wenn sich ihr Inhalt unerwartet ändert.
• Erzwingen Sie eine strenge Content Security Policy (CSP), die einschränkt, welche Domains Skripte ausführen dürfen, und die Ausführung von Inline-Code verbietet.
• Entfernen Sie unnötige Drittanbieter-Skripte von Seiten, auf denen Nutzer sensible Aktionen wie Trading, Signieren oder die Eingabe von Zahlungsdaten durchführen.
• Überwachen Sie DNS-Einträge Ihrer Drittanbieter und erwägen Sie die Verwendung gepinnter Skriptversionen anstelle dynamischer Endpunkte.
• Schulen Sie Nutzer darin, jede Wallet-Signaturanfrage abzulehnen, die sie nicht explizit initiiert haben, insbesondere wenn sie in rascher Abfolge erscheinen.
• Isolieren Sie Drittanbieter-Code nach Möglichkeit in einer Sandbox, um den Zugriff auf das DOM der Hauptseite und sensible API-Objekte einzuschränken.