Op prediction market Polymarket is circa $2,7 miljoen aan crypto verplaatst via een kwaadaardig script dat zich voordeed als een normale performance- en monitoringcomponent. Het incident illustreert hoe kwetsbaar websites kunnen zijn wanneer externe scripts op pagina’s worden geladen, juist op momenten dat gebruikers zijn ingelogd en transacties kunnen worden gesigneerd.
In de kern ging het om een ingreep in een pagina-speed script dat Polymarket laadde vanaf een derde partij. Onderzoekers koppelden de aanval aan een compromis van DebugBear, een aanbieder van real user monitoring (RUM) die laadtijd meet van pagina’s voor echte bezoekers.
Wat er bij Polymarket gebeurde
Volgens Polymarket en de betrokken onderzoekers is op 29 oktober kwaadaardige code geplaatst op de site. Die code verving een script voor page speed dat normaal werd ingeladen van een externe partij.
Door die vervanging konden aanvallers ingelogde traders beïnvloeden: hun posities werden verkocht en vervolgens werd het geld doorgestuurd naar de aanvallers. Blockchain-gegevens laten zien dat er binnen minder dan een uur ongeveer $2,64 miljoen aan crypto bij de hackers terechtkwam.
Waarom een “page-speed script” gevaarlijk kan zijn
Een belangrijk inzicht uit het onderzoek is dat de schadelijke code niet zomaar “globale” toegang kreeg. In plaats daarvan maakte de code gebruik van wat er al beschikbaar was in de browser van een ingelogde gebruiker.
De onderzoekers van Hudson Rock stelden vast dat de code de bestaande functionaliteit op de Polymarket-pagina hergebruikte: het zocht in de geladen site naar de onderdelen die normaal gesproken orders plaatsen en een transactie laten goedkeuren.
Daarmee kon de code requests laten ondertekenen door de eigen signer van de gebruiker. Cruciaal daarbij is dat het script zelf geen privésleutels, seeds of wachtwoorden naar een server stuurde. Orders zijn bovendien niet “blind” uit te voeren met alleen API-gegevens; er is altijd een handtekening nodig om transacties goed te keuren.
Van API-keys naar transacties: hoe de code omzeilt
Polymarket gebruikt accountdata in de browser, waaronder een reeks trading API keys. Hudson Rock vond dat de schadelijke code wel accountdetails las, maar niet het soort geheimen dat doorgaans nodig is om zelf transacties te orkestreren zonder toestemming.
In plaats daarvan werd gezocht naar de interface die transacties kan laten ondertekenen. Vervolgens koos het script een route afhankelijk van het type inlog:
- Inloggen via eigen crypto wallet: het script kon de posities direct overhevelen naar de wallet van de aanvallers.
- Inloggen via e-mail: het script verkocht de posities geleidelijk tegen steeds slechtere prijzen en zette daarna het geld om richting de aanvaller(s).
Volgens Hudson Rock bewijst een signing request niet automatisch dat de gebruiker echt zonder context tekende. Walletproviders kunnen nog steeds om goedkeuring vragen, weigeren of eigen regels toepassen voor die sessie.
Wat onderzoekers vonden over de timing
De blockchain-trace die door Ohey is geanalyseerd, laat zien dat de wallet die werd gebruikt voor de ontvangen POL-tokens eerste funds zag op 17:10 UTC en de laatste ontvangst had op 18:02 UTC.
In die periode werden tokens en posities van 33 wallets samengebracht. In totaal ging het om 28,6 miljoen POL. Rond 18:19 UTC was die hoeveelheid ongeveer $2,64 miljoen waard op basis van DefiLlama’s prijs van $0,0922. Dit bedrag betrof alleen POL en dus niet de volledige waarde van de posities.
Daarna werden de ontvangen POL-tokens tussen 18:28 en 18:38 UTC doorgestuurd naar drie andere adressen, zoals zichtbaar is in de transactiegeschiedenis.
Hoe DebugBear mogelijk werd gecompromitteerd
Het incident lijkt niet begonnen met een directe inbraak in de eigen systemen van DebugBear, maar met het compromis van DNS-gerelateerde gegevens via de domeinregistrar. DebugBear meldde dat de DNS-records waren aangetast.
Onderzoekers zagen daarnaast dat er op een bepaald moment een andere server antwoordde op DebugBear-webadressen, terwijl de schadelijke versie nog online stond. Ook werd vastgesteld dat de normale scriptvariant die dag eerder werd geserveerd vanuit een omgeving op basis van Google Cloud Storage.
Waarom het “per klant” anders kan zijn
Een extra detail dat het incident complex maakt: elke DebugBear-klant laadt een eigen kopie van het script. Daardoor was het script dat uiteindelijk werd vervangen precies dat van Polymarket. Dat verklaart waarom de impact lijkt geconcentreerd bij één specifieke klant.
Polymarket: moduswijziging, opschonen en refunds
Polymarket zette snel stappen nadat de ongeautoriseerde activiteit zichtbaar werd. Hun eerste statusupdate over activiteit in gebruikerswallets verscheen op 17:38 UTC. Later, om 18:05 UTC, meldde het platform dat de exchange overschakelde naar cancel-only en dat relayer-activiteiten werden gepauzeerd.
Polymarket stelt dat het het script binnen het uur heeft verwijderd. Daarnaast zouden caches zijn gewist, actieve login-sessies zijn gereset en werd trading gepauzeerd tot de site weer “schoon” was.
Het bedrijf gaf ook aan de zaak te hebben doorverwezen naar wetshandhaving.
Wie krijgt geld terug en hoe werkt dat?
Tot 30 oktober waren 689 van de 726 getroffen wallets volledig terugbetaald. Voor de overige 37 wallets liep de uitbetaling nog, terwijl de bedragen werden gecontroleerd.
Naast de directe refund meldde Polymarket ook aanvullende compensatie: $1,19 miljoen voor ongeveer 5.500 wallets die geld verloren tijdens de trading-pauze of waarvan posities werden ingenomen. In totaal keert het platform volgens de updates $3,9 miljoen uit aan traders.
Volgens Polymarket hoeven gebruikers geen claim in te dienen. Wel is er op de statuspagina een formulier gekoppeld voor mensen die denken dat hun bedrag onjuist is of dat ze geen compensatie ontvingen.
Wat sites en traders nu kunnen doen
Het incident bevat concrete lessen voor zowel website-eigenaren als gebruikers van webapplicaties met ondertekening.
Advies voor websites met externe scripts
- Beperk derde partij code op pagina’s waar gebruikers handelen of transacties kunnen goedkeuren. Als het niet nodig is, laat het weg.
- Gebruik Subresource Integrity (SRI) wanneer een script kan worden “gepinnd” aan een specifieke inhoud. Een beleid dat alleen op een vertrouwde CDN vertrouwt, controleert niet of de server daadwerkelijk dezelfde file levert.
- Controleer wat er kan worden gevraagd aan de signer op ingelogde pagina’s. Denk daarbij aan welke functies een script kan aanroepen en of een signing request voldoende context bevat.
Advies voor traders
- Weiger een signing request die je niet verwacht. Ook als een request afkomstig lijkt van de interface, is het verstandig om de prompt en context te verifiëren voordat je tekent.
Waarom dit incident breder relevant is
Dit geval laat zien dat “traditionele” webkwetsbaarheden niet altijd nodig zijn voor financieel verlies. De combinatie van (1) externe scripts, (2) ingelogde accounts, en (3) acties die via ondertekening kunnen worden afgehandeld, kan een keten vormen waarin kwaadwillenden relatief snel impact maken.
Voor organisaties is het daarom zinvol om niet alleen naar server-side veiligheid te kijken, maar ook naar de hele keten van wat er in de browser draait. Eén vervangbaar script kan genoeg zijn om gebruikersstromen te beïnvloeden—en dat betekent dat beveiliging rond content delivery, integriteitschecks en least privilege op de klantzijde net zo belangrijk wordt.
Wil je ook meer lezen over hoe aanvallen op netwerk- of infrastructuurlagen kunnen escaleren? Bekijk dan Network-layer DDoS stijgt sterk en de gevolgen daarvan voor bereikbaarheid.
Conclusie
Bij Polymarket leidde een gecompromitteerd script—vervangen op basis van een externe RUM-leverancier—tot ongeautoriseerde verplaatsing van crypto ter waarde van ongeveer $2,7 miljoen. Polymarket reageerde met het verwijderen van de code, het pauzeren van relayer-acties en het terugbetalen van getroffen gebruikers.
De belangrijkste les is helder: bescherm ingelogde en handelsrelevante pagina’s tegen wijzigingen in derde partij scripts, implementeer integriteitscontroles zoals SRI en zorg dat signing requests alleen gebeuren in een context die gebruikers begrijpen en kunnen beoordelen.
Bron: https://thehackernews.com/2026/11/hackers-steal-about-27-million-from.html
