Kort samengevat: de scriptaanval op Polymarket in oktober
- Opnieuw een leverancier gecompromitteerd: Op 2026-10-29 gebruikte een vervangen prestatiemonitoringscript actieve Polymarket-sessies om posities te verkopen en geld te verplaatsen.
- Het eerdere incident in juni: Polymarket maakte op 2026-06-25 een vergelijkbare supplychainaanval op de frontend bekend. cside beschreef de gemelde diefstal van ongeveer $3 miljoen.
- Terugbetalingen: Polymarket kondigde $3,9 miljoen aan terugbetalingen voor oktober aan, waaronder $1,2 miljoen voor verliezen door de handelspauze.
Weinig tijd? Bekijk cside client-side beveiliging voor scriptmonitoring en bescherming tijdens uitvoering in de browser.
Een prestatiemonitoringscript werd een toegang tot het geld van gebruikers. Vier maanden na het incident in de frontend in juni heeft Polymarket opnieuw een aanval via externe scripts ondervonden.
Op 2026-10-29 gebruikte een gecompromitteerd leveranciersscript actieve Polymarket-sessies om posities te verkopen en geld uit getroffen wallets te verplaatsen. In de update van 2026-10-30 stelde Polymarket de totale vergoeding vast op $3,9 miljoen, waaronder $1,2 miljoen voor verliezen door de handelspauze. Het incidentrapport van Polymarket beschrijft de reactie en terugbetalingen.
Voor teams die financiële applicaties beheren verdient dit terugkerende probleem aandacht: JavaScript van derden valt binnen je beveiligingsgrens.
Wat er op 2026-10-29 gebeurde
Volgens Polymarket verving een aanvaller het prestatiemonitoringscript van een leverancier door code die op gebruikers was gericht. Het bedrijf verwijderde het script en leegde caches. Het pauzeerde ook de handel en de relayer en stelde vervolgens alle actieve inlogsessies opnieuw in. Het evaluatierapport beschreef extra integriteitscontroles, monitoring, vastgezette versies, sandboxing en een strengere Content Security Policy.
De terugbetalingsbedragen vragen om precisie. De door Polymarket aangekondigde $3,9 miljoen omvat compensatie boven op het buitgemaakte geld. Het volledige bedrag als gestolen geld presenteren zou de gemelde diefstal overdrijven. Bron
Hoe monitoringcode toegang kreeg tot handelsfuncties
Het technische onderzoek van Hudson Rock identificeerde schadelijke JavaScript vanaf een DebugBear-URL die bij de integratie voor monitoring van echte gebruikers van Polymarket hoorde.
De schadelijke code las accountcontext uit browseropslag en doorzocht interne React-structuren om de handelsclient en signer van de applicatie te vinden. De verschillende codepaden probeerden positietokens over te dragen of posities te verkopen en daarna de opbrengst over te maken. De code vroeg om handtekeningen en probeerde transacties via de relayer van Polymarket in te dienen.
Een prestatietool probeerde financiële bevoegdheden binnen de pagina uit te oefenen.
Het onderzoek van Hudson Rock stelde niet vast dat elk ondertekenverzoek ongemerkt slaagde. Walletbevestigingen, sessieregels en de uitvoering van transacties blijven bepalend. De onderzoekers vonden ook geen routine die privésleutels of seed phrases verstuurde. De waargenomen aanpak draaide om hergebruik van bevoegdheden binnen de ingelogde applicatie. Bron
Polymarket had in juni een vergelijkbare aanval
We beschreven de eerdere client-side supplychainaanval op Polymarket na de bekendmaking op 2026-06-25. Bij dat incident injecteerde een gecompromitteerde externe leverancier schadelijke code in de frontend. Er werd ongeveer $3 miljoen aan gestolen geld gemeld.
Onze analyse van juni beschreef phishing via goedkeuringsverzoeken in de echte Polymarket-interface. Het onderzoek van oktober beschrijft schadelijke code die binnen een bestaande sessie naar de handelsclient en signer zoekt.
| Incident | Gemeld mechanisme | Gemelde financiële impact |
|---|---|---|
| 2026-06-25 | Gecompromitteerde leverancier injecteert frontendcode die verband houdt met schadelijke goedkeurings- of ondertekenverzoeken | Ongeveer $3 miljoen gestolen, volgens onze eerdere analyse |
| 2026-10-29 | Vervangen monitoringscript misbruikt actieve sessies; onderzoekers vinden handels- en ondertekenlogica | Polymarket kondigt $3,9 miljoen aan terugbetalingen aan, inclusief compensatie voor de pauze |
Het gedeelde patroon is dat externe scripts toegang krijgen tot een gevoelig financieel proces. Die overeenkomst bewijst niet dat dezelfde aanvaller, leverancier of methode voor de eerste compromittering betrokken was.
Wat applicatieteams moeten veranderen
De praktische vraag bij een beveiligingsreview is of een monitoringintegratie toegang heeft tot mogelijkheden die veel verder gaan dan de bedoelde taak.
Begin met minder uitvoering van externe scripts op ingelogde handels- en ondertekenpagina's. Eis voor elke integratie een duidelijke zakelijke reden, een eigenaar en een verwijderprocedure. Onderzoek de toegangsgrens rond ondertekening en bepaal welke acties om een nieuwe, expliciete bevestiging vragen.
Gebruik Subresource Integrity voor dependencies die je kunt vastzetten. Met SRI vergelijkt de browser een opgehaald bestand met een verwachte cryptografische hash en weigert het bij een afwijking. Implementaties tussen verschillende origins vereisen passende CORS-ondersteuning en een gecontroleerd proces voor goedgekeurde updates.
Bewaar ook de inhoud van scripts die aan gebruikers zijn geleverd. Een incidentonderzoek heeft bewijs nodig van wat er draaide, wanneer het veranderde en welke sessies het konden ontvangen.
Wat cside toevoegt
cside biedt zicht op uitvoering in de browser, een scriptinventaris, een historie van scriptinhoud en detectie van schadelijk scriptgedrag. Die mogelijkheden helpen teams wijzigingen te onderzoeken in code die in klantsessies wordt uitgevoerd. Bekijk cside client-side beveiliging.
De incidenten in juni en oktober maken de prioriteit concreet: controleer welke code naast je gevoeligste processen mag draaien, beperk de bevoegdheden en verifieer doorlopend wat gebruikers ontvangen.
