Binnen de client-side supply-chain-aanval van $3M op Polymarket

Kort samengevat: Polymarket 1.893 ETH approval-phishing-drainer

• De contracts waren prima: De smart contracts van Polymarket waren prima. De blockchain deed precies wat het moest doen. De diefstal gebeurde in het browsertabblad, via een vendor-script dat het platform al maanden vertrouwde.
• De diefstal in de browser: Een gecompromitteerde externe leverancier injecteerde een wallet-drainer die ongeveer 3 miljoen dollar wegsluisde uit minder dan 15 wallets, witgewassen als circa 1.893 ETH via consolidatiewallet 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD. cside houdt scriptgedrag in de gaten en blokkeert een vertrouwd script dat plotseling om token-goedkeuringen vraagt.
• Trek goedkeuringen in: Als je dApp of checkout externe JS laadt, voeg dan dit kwartaal runtime-scriptmonitoring toe. Kan dat niet, trek dan minstens vandaag ongebruikte wallet-goedkeuringen in. Dat is wat elke onderzoeker Polymarket-gebruikers aanraadde te doen.

Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.

Op 2026-06-25 bevestigde voorspellingsmarktplatform Polymarket dat aanvallers ongeveer 3 miljoen dollar hadden gestolen van een klein aantal gebruikers. On-chain onderzoeker Specter, die de diefstal als eerste signaleerde, traceerde ongeveer 2,94 miljoen dollar die uit minstens 11 wallets werd weggehaald; blockchain-analysebedrijf Bubblemaps schatte het totaal op minder dan 15 accounts en publiceerde de betrokken adressen. Polymarket beperkte het incident snel, verwijderde de verantwoordelijke dependency en zegde toe elke getroffen gebruiker volledig te vergoeden.

Voor iedereen die een website beheert waar geld of gevoelige data doorheen stroomt, is het detail dat ertoe doet wáár de aanval plaatsvond. De smart contracts van Polymarket zijn nooit gecompromitteerd. De blockchain werkte precies zoals ontworpen. De diefstal vond plaats in de browser, via een extern script dat het platform vertrouwde. Dit is een schoolvoorbeeld van een client-side supply-chain-aanval, dezelfde klasse aanval die elke week e-commerce-betaalpagina's, fintech-inlogpagina's en SaaS-dashboards treft.

De mechaniek doet ertoe, want die verklaart waarom zoveel teams aan hetzelfde risico blootstaan.

Wat er gebeurde

In zijn eigen verklaring zei Polymarket dat het had "ontdekt dat een externe leverancier was gecompromitteerd, waardoor een kwaadaardig script in onze frontend werd geïnjecteerd voor sommige gebruikers", en dat het het incident had beperkt en de getroffen dependency had verwijderd. Op het moment van publicatie hebben noch Polymarket noch onafhankelijke berichtgeving de gecompromitteerde leverancier of dependency genoemd.

Het doelwit was pUSD, de door USDC gedekte stablecoin van Polymarket en het belangrijkste handelsonderpand van het platform. Toen getroffen gebruikers hun wallets verbonden, verleidde de geïnjecteerde code hen om transacties te ondertekenen of goed te keuren die stilletjes geld naar de aanvaller doorsluisden. Beveiligingsbedrijf PeckShield meldde dat de gestolen pUSD van Polygon naar Ethereum werd gebridged en omgewisseld naar ongeveer 1.893 ETH, die onderzoekers herleidden tot één consolidatieadres. Meerdere bedrijven classificeerden de gebeurtenis als een supply-chain-compromittering gecombineerd met een phishingcampagne die via de eigen interface van het platform liep.

De mechaniek is eenvoudig en geldt voor vrijwel elke moderne website:

• De aanvaller hoefde nooit in te breken in de servers of de smart contracts van Polymarket.
• Hij compromitteerde een vertrouwde leverancier wiens code al toestemming had om op de site te draaien.
• Zodra die code in de live frontend draaide, zag hij er voor de mensen die de site gebruikten identiek uit aan legitieme code.

Een gebruiker die naar de normale interface keek, had geen praktische manier om te weten dat het script dat zijn transactie afhandelde, was veranderd. Dat is het kenmerk dat deze klasse aanval definieert, en daarom is hij zo moeilijk van buitenaf te detecteren.

Indicators of compromise (on-chain)

On-chain onderzoekers herleidden de gestolen fondsen tot één consolidatiewallet, gevoed door zes tussenwallets. De bedragen hieronder tellen op tot 1.892,92 ETH, het volledige geconsolideerde saldo. Deze adressen zijn in handen van de aanvaller en worden vermeld als referentie voor verdedigers; het zijn geen wallets van slachtoffers.

Consolidatiewallet: 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD

De technische invalshoek: een wallet-drainer geleverd via de supply chain

De meeste berichtgeving stopt bij "supply-chain-aanval". Het mechanisme is specifieker, en dat is wat dit incident de moeite van het bestuderen waard maakt.

De hele aanval speelde zich af in de runtime-laag van de browser. De blockchain- en smart-contractlaag werd nooit geschonden: die werkte precies zoals ontworpen, omdat de ondertekening in de browser werd geautoriseerd:

1. Gecompromitteerde externe leverancier. Een afhankelijkheid werd vergiftigd en, in de woorden van Polymarket, geleverd "voor sommige gebruikers".
2. Kwaadaardig script geïnjecteerd in de frontend van polymarket.com.
3. Echte Polymarket-interface. Het script liftte mee op de echte UI: de gebruiker klikte op "Wallet verbinden", waarna het script een kwaadaardig ERC-20-goedkeurings- / ondertekeningsverzoek presenteerde.
4. De aanvaller veegt de pUSD van het slachtoffer weg zodra de goedkeuring was ondertekend.
5. Overgebrugd van Polygon naar Ethereum, omgewisseld naar ongeveer 1.893 ETH en witgewassen via de consolidatiewallet 0xe65b…E1eD.

Een klassieke Magecart-skimmer is passief. Hij leest wat een slachtoffer in een betaalformulier typt en kopieert het naar de server van de aanvaller. Deze aanval had geen formulier om te skimmen, dus werd het geïnjecteerde script actief en richtte het zich op de ondertekening zelf.

Op basis van de on-chain analyse presenteerde het script, toen een getroffen gebruiker zijn wallet verbond, een kwaadaardig goedkeurings- of ondertekeningsverzoek via de echte Polymarket-interface. Het goedkeuren ervan gaf de aanvaller de mogelijkheid om de pUSD van het slachtoffer te verplaatsen. Dit is dezelfde approval-phishingtechniek waar wallet-drainers op leunen: de houder een ERC-20-goedkeuring of token-permit laten ondertekenen en vervolgens het saldo wegvegen naar een door de aanvaller beheerd adres. Het duidelijkste teken is de remediatie die alle onderzoekers gaven, namelijk token-goedkeuringen intrekken. Je trekt alleen goedkeuringen in wanneer goedkeuringen het wapen waren.

Dit is wat anders is aan dit geval. Wallet-drainers bereiken slachtoffers meestal via valse airdrop-sites, kwaadaardige advertenties, getyposquatte domeinen of gekaapte sociale links. Die zijn allemaal afhankelijk van het lokken naar een valse plek, dus het gebruikelijke advies werkt: controleer de URL, gebruik de officiële site, zoek naar het slotje. Niets daarvan hielp hier. De drainer draaide op de echte polymarket.com, in een sessie waarin de gebruiker zijn wallet al had verbonden en alle reden had om de volgende prompt te vertrouwen. Supply-chain-injectie maakte van de legitieme frontend de phishingpagina.

Dit patroon heeft een duidelijk, benoembaar precedent. In december 2023 phishten aanvallers het npm-account van een voormalige Ledger-medewerker en publiceerden kwaadaardige versies van @ledgerhq/connect-kit, de open-source bibliotheek die veel dApps gebruiken om Ledger-hardwarewallets te verbinden. De vergiftigde versies injecteerden een wallet-drainer in de frontend van elke site die de bibliotheek laadde, waaronder SushiSwap, Zapper en Revoke.cash, en haalden in enkele uren ongeveer 600.000 dollar buit. Eén gekaapte open-source dependency haalde tegelijk gebruikers van veel sites leeg, zonder enige nep-URL. De gecompromitteerde dependency van Polymarket is niet genoemd, maar het stramien is hetzelfde.

De eigen bewoording van Polymarket bevat het detail dat voor verdedigers het meest telt: het script werd geïnjecteerd "voor sommige gebruikers". De payload was voorwaardelijk. Dat is dezelfde eigenschap waardoor deze aanvallen langs een scanner glippen die vanuit een datacenter rondkijkt, en het is waarom een controle die alleen de bron van een script controleert niet kan helpen zodra de bron vertrouwd is.

Waar deze aanval echt plaatsvond

Dit wegzetten als "weer een crypto-hack" verbergt het deel waar elk webteam om zou moeten geven. De blockchainlaag gedroeg zich correct. De smart contracts werden niet misbruikt. Er was geen reentrancy-bug, geen flash loan, geen oracle-manipulatie. De aanval leefde volledig in de browser-runtime, de laag tussen je server en het scherm van je gebruiker, waar externe JavaScript draait met dezelfde rechten als je eigen code.

Die laag is een van de minst gemonitorde oppervlakken in moderne webapplicaties. Teams herhalen de regel "vertrouw de client-side nooit" en laden vervolgens routinematig tientallen externe fetches in die client-side: analytics, tagmanagers, chatwidgets, marketingpixels en SDK's. Elk daarvan is een dependency, en elke dependency is een mogelijk toegangspunt. De aanvaller van Polymarket gebruikte een leveranciersrelatie die al vertrouwd was, omdat de leverancier aan de andere kant gecompromitteerd was.

We hebben dit patroon eerder gedocumenteerd. De AppsFlyer Web SDK-compromittering volgde hetzelfde stramien: aanvallers kaapten een vertrouwde marketing-SDK en serveerden een kwaadaardige payload aan duizenden sites waarvan de eigenaren geen idee hadden dat hun scripts waren veranderd. We hebben ook kwaadaardige browserextensies gevolgd die Microsoft Clarity nabootsten om referral-tokens te overschrijven en omzet om te leiden. Andere payloads, dezelfde grondoorzaak: vertrouwde externe code die vijandig wordt, in de browser draait en onzichtbaar blijft voor traditionele verdedigingen.

Waarom standaardverdedigingen deze klasse niet vangen

Als je je afvraagt waarom de gangbare beveiligingscontroles dit niet tegenhouden, is het antwoord structureel. Het merendeel van de tooling waar teams op vertrouwen, kan deze aanval simpelweg niet zien.

• Beveiliging aan de serverkant en op netwerkniveau monitort je eigen infrastructuur. De kwaadaardige code raakte die nooit. De leverancier werd stroomopwaarts gecompromitteerd en de payload draaide op het apparaat van de gebruiker.
• Content Security Policy (CSP) zet op een allowlist welke domeinen scripts mogen serveren, maar valideert de bron, niet het gedrag. Als een vertrouwde, toegestane leverancier kwaadaardige code begint te serveren, laat CSP die door. Het heeft geen idee of het script een formulierveld leest of de wallet om een token-goedkeuring vraagt. Voor een dieper beeld, zie waarom CSP alleen client-side aanvallen niet tegenhoudt.
• Statische scanners doorzoeken je site op bekende kwaadaardige scripts. Geavanceerdere aanvallers detecteren de scanner en serveren die een schone versie, terwijl ze de echte payload aan echte gebruikers leveren. Het script van Polymarket draaide "voor sommige gebruikers", wat precies dat soort voorwaardelijke levering is, en een scanner is het makkelijkst uit te sluiten.

Het gedrag dat had moeten opvallen is specifiek: een extern script dat nooit de wallet-provider had geraakt en er plotseling mee interacteerde en gebruikers vroeg om token-overdrachten goed te keuren. Dat is waarneembaar in de JavaScript-runtime, waar het script daadwerkelijk wordt uitgevoerd. Het is onzichtbaar voor een controle die alleen controleert waar het script vandaan kwam.

Een patroon op het hele web

Neem afstand en de trend is duidelijk. DefiLlama registreerde het tweede kwartaal van 2026 als het slechtste kwartaal aan crypto-beveiligingsincidenten dat het ooit heeft vastgelegd, met ongeveer 74,9 miljoen dollar verloren over 29 exploits in juni alleen. Het verhaal dat de webbeveiliging in 2026 definieert, is niet langer het buggy smart contract of de ongepatchte server. Het is de vertrouwde dependency die misgaat, en de browser-runtime waar dat falen zich afspeelt.

Aanvallers diversifiëren omdat de oudere toegangspunten steeds moeilijker te openen zijn. Naarmate de verdedigingen op protocol- en serverniveau volwassen worden, blijft de client-side het zachtere doelwit. Het is makkelijk te bereiken en wordt zelden in realtime gemonitord. De polyfill[.]io supply-chain-aanval, die honderdduizenden sites bereikte via één enkele vertrouwde dependency, is hetzelfde verhaal op veel grotere schaal.

Hoe een client-side supply-chain-aanval te voorkomen

Het Polymarket-incident laat een herhaalbaar patroon zien. Elke webapplicatie die externe JavaScript laadt, heeft dezelfde blootstelling. Deze vier controles verminderen het risico in elke stack.

Houd een actuele scriptinventaris bij. Ken elke dependency die in de browsers van je gebruikers draait: wie is de eigenaar, welke data kan het script bereiken en waarom staat het er. Dit is geen eenmalige audit. Scripts veranderen. Leveranciers voegen sub-dependencies toe. Code die een jaar geleden werd beoordeeld en goedgekeurd, kan vandaag heel ander gedrag laden. PCI DSS 4.0.1 §6.4.3 vereist een realtime inventaris voor betaalpagina's, precies omdat een onbekend script een onbewaakt script is. Begin met betaalflows en authenticatiepagina's.

Monitor wat scripts daadwerkelijk doen, niet alleen waar ze vandaan komen. CSP valideert de bron. Zodra een vertrouwde leverancier is gecompromitteerd, heeft CSP geen manier om te detecteren dat hun analytics-tag nu om wallet-goedkeuringen vraagt. Een vertrouwd domein is niet hetzelfde als vertrouwd gedrag. Monitoring in de JavaScript-runtime-laag, waar scripts daadwerkelijk worden uitgevoerd, detecteert wat elk brongebaseerd controlemechanisme mist: een script dat gisteren analytics deed en vandaag interageert met de wallet-provider.

Waarschuw bij gedragsdrift voordat een handtekening wordt gepubliceerd. Dreigingsinformatie is per definitie reactief. Een leverancier die vanmorgen is gecompromitteerd, verschijnt op geen enkele feed totdat de schade al is aangericht. Detectie die reageert op gedragsdrift, een script dat nieuwe externe domeinen contacteert, nieuwe browser-API-toegang krijgt of datastructuren leest die het eerder negeerde, sluit dat venster.

Oefen het verwijderingsproces voordat je het nodig hebt. Het team van Polymarket identificeerde de gecompromitteerde dependency, verwijderde die en zegde toe de getroffen gebruikers volledig te vergoeden. De meeste teams hebben deze volgorde niet geoefend. Weten welke scripts te verwijderen en hoe snel een schone build gedeployed kan worden, maakt een supply-chain-compromittering van een meerdaagse crisis in een beheersbaar incident.

Hoe cside deze klasse aanval detecteert

cside is precies gebouwd voor het oppervlak dat deze aanval gebruikte. Zo zou het eruitzien door onze detectie-engine.

Gedrag boven bron. We kijken naar wat een script doet in de runtime: DOM-manipulatie, event listeners, welke data het benadert en waar het die data naartoe stuurt. Het script van een vertrouwde leverancier dat plotseling naar de wallet-provider grijpt, om een token-goedkeuring vraagt of een vers geregistreerd domein contacteert, is precies het soort anomalie dat we aan het licht brengen.

Drift-detectie. Scripts blijven niet statisch. Een dependency die vorige week analytics deed en deze week wallet-API's en een nieuw domein begint te raken, activeert een waarschuwing. Onze AI genereert een uitleg in gewone taal van wat er veranderde en waarom het ertoe doet, zodat je geen onderzoeker nodig hebt om een hash-diff te lezen.

Script Method. cside werkt in twee modi, Script Method en Scan Method. In Script Method volgen we het gedrag van elk script in de live sessie van de gebruiker en analyseren we het script server-side op onze eigen infrastructuur, waarna we het blokkeren op het moment dat het gedrag als kwaadaardig is bevestigd, zonder dat er een proxy nodig is. Doordat we observeren wat er daadwerkelijk in de sessie wordt uitgevoerd, helpt de truc "serveer de scanner een schone versie" niet, en vangen we payloads die alleen voor specifieke gebruikers, geografieën of sessies afgaan, dezelfde "voor sommige gebruikers"-targeting die hier te zien was.

Realtime blokkeren. Scanners rapporteren. CSP blokkeert op beperkte data. cside kan een script blokkeren op basis van het waargenomen gedrag voordat het een wallet leeghaalt of een kaart skimt. Een tool die je pas over een inbreuk vertelt nadat die heeft plaatsgevonden, laat je reagerend achter.

De reactie van Polymarket, het incident beperken, de dependency verwijderen en getroffen gebruikers volledig vergoeden, is hoe een sterke reactie eruitziet na een aanval. De kans voor elk ander platform is om ervoor te zorgen dat er nooit een "daarna" is. Realtime monitoring van de frontend-integriteit is nog geen standaard op het web, en incidenten als dit zijn de reden waarom het dat zou moeten zijn.

Polymarket werd getroffen aan de client-side, waar aanvallen het makkelijkst te verbergen en het moeilijkst te detecteren zijn. Als er externe JavaScript op je site draait, en dat doet het, dan is dat oppervlak blootgesteld, of je het nu in de gaten houdt of niet.

De cijfers en attributie hierboven weerspiegelen de eerste berichtgeving van Specter, PeckShield en Bubblemaps en zijn correct per 2026-06-26.

Wil je zien wat er echt draait in de browsers van je gebruikers? Begin gratis of boek een demo om met ons team te praten.