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.
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.
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 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, niet alleen de bron. We controleren niet alleen waar een script vandaan komt. We kijken naar wat het doet in de runtime: DOM-manipulatie, event listeners, welke data het benadert en waar het die naartoe stuurt. Het script van een vertrouwde leverancier dat plotseling naar de wallet-provider grijpt, een token-goedkeuring vraagt of een net geregistreerd domein contacteert, is precies het soort anomalie dat we naar boven halen.
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.
Gatekeeper-modus. Onze edge-engine kan tussen onvertrouwde derden en je gebruikers gaan staan en het script serveren via een conduit die wij beheren, voor de scripts die jij kiest. We bewaren een kopie van wat er daadwerkelijk werd geleverd, wat de truc "serveer de scanner een schone versie" tenietdoet, en het legt payloads vast die alleen voor specifieke gebruikers, geografieën of sessies afgaan, dezelfde "voor sommige gebruikers"-targeting die hier te zien was.
Realtime blokkeren, niet alleen rapporteren. 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.
