Polymarket: Drittanbieter-Kompromittierung führt zu 3 Millionen Dollar Schaden
Die Prognose-Plattform Polymarket hat einen Sicherheitsvorfall bestätigt, bei dem Angreifer über einen kompromittierten Drittanbieter bösartigen Code in das Website-Frontend injizierten. Mindestens 2,9 Millionen Dollar wurden aus Nutzer-Wallets gestohlen.

Die Prognose-Plattform Polymarket hat einen Sicherheitsvorfall bestätigt, bei dem Angreifer über einen kompromittierten Drittanbieter bösartigen Code in das Website-Frontend injizierten. Mindestens 2,9 Millionen Dollar wurden aus Nutzer-Wallets gestohlen. Polymarket hat Rückerstattung zugesichert.
Was ist passiert?
Am 26. Juni 2026 kam es zu einem Sicherheitsvorfall bei der Prognose-Plattform Polymarket. Angreifer kompromittierten einen Drittanbieter und injizierten über diesen bösartigen JavaScript-Code in das Frontend der Website. Der Code war darauf ausgelegt, Krypto-Transaktionen von Nutzern abzufangen und an Wallets der Angreifer umzuleiten. Laut Kettenanalyse wurden etwa 2,9 Millionen Dollar aus mindestens 11 Nutzer-Wallets gestohlen. Spätere Berichte korrigierten den Schaden auf 3,1 Millionen Dollar. Weniger als 15 Konten waren betroffen. Polymarket hat den Vorfall eingedämmt und volle Rückerstattung zugesagt.
Wer ist betroffen?
Betroffen sind Nutzer von Polymarket, die zum Zeitpunkt des Angriffs Transaktionen auf der Plattform durchführten. Die injizierte Malware war nur über die kompromittierte Frontend-Version aktiv. Nutzer, die direkt mit Smart Contracts interagierten, waren nicht betroffen. Der Vorfall zeigt ein allgemeines Risiko für Web3-Plattformen, die Drittanbieter-Code einbinden. Der kompromittierte Drittanbieter wurde von Polymarket nicht namentlich benannt.
Wie kritisch ist das?
Der finanzielle Schaden beträgt 3,1 Millionen Dollar. Die Zahl der betroffenen Nutzer ist mit unter 15 Konten zwar klein, der pro-Kopf-Schaden ist jedoch erheblich. Der Angriff zeigt das klassische Supply-Chain-Muster: Nicht die Plattform selbst wurde direkt gehackt, sondern ein Drittanbieter, dessen Code in das Frontend gelangt. Für Nutzer bestand keine sichtbare Warnung, da die Website normal funktionierte und die bösartige Transaktion im Hintergrund umgeleitet wurde.
Was sollten Admins jetzt tun?
- Bei Nutzung von Web3-Plattformen Hardware-Wallets statt Browser-Wallets verwenden
- Drittanbieter-Scripts auf eigenen Websites minimieren und Subresource Integrity (SRI) nutzen
- Transaktionen vor Bestätigung immer auf dem Gerät prüfen, nicht nur im Browser-Frontend
- Lieferanten und Drittanbieter-Codes in der eigenen Web-Infrastruktur auditieren
- Mitarbeiter über Risiken von Web3-Plattformen und Frontend-Injection aufklären
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen ist der Vorfall ein Lehrstück für Supply-Chain-Risiken in Web-Anwendungen. Auch ohne Krypto-Bezug gilt: Wer Drittanbieter-Code in die eigene Website einbindet, vertraut deren Sicherheit. Ein kompromittierter Analytics-Provider, Chat-Widget oder Tag-Manager kann bösartigen Code auf der eigenen Website platzieren. Subresource Integrity und strikte Content-Security-Policies sind grundlegende Schutzmaßnahmen, die viele Unternehmen noch nicht konsequent umsetzen.
Passende Anleitungen auf S-EDV
- WordPress-Supply-Chain-Angriff: OptinMonster-Kompromittierung gefährdet 1,2 Millionen Websites – Ein weiterer Fall, bei dem Drittanbieter-Code zur Einfallspforte wurde.
- WordPress-Supply-Chain-Angriff: ShapePlugin-Pro-Plugins mit Backdoor – Wie Supply-Chain-Angriffe über kompromittierte Drittanbieter funktionieren und was Admins dagegen tun können.