Polymarket heeft op 29 oktober de handel op zijn internationale platform stilgezet nadat gebruikers melding maakten van ongeautoriseerde opnames. Korte tijd later ging de beurs weer aan—maar het incident laat vooral zien hoe snel een supply chain aanval via ogenschijnlijk onschuldige webcomponenten kan doorwerken tot in geldstromen.
In dit artikel zetten we de feiten op een rij: wat Polymarket deed, welke rol een derde partij speelde, en welke concrete technieken onderzoekers aanwijzen in het schadelijke JavaScript.
Wat er gebeurde op Polymarket
Volgens de statuspagina van Polymarket is de internationale site eerst omgezet naar een cancel-only modus. Tegelijkertijd werden relayer-acties opgeschort. Dat zijn onderdelen in de keten die transacties kunnen afhandelen namens gebruikers.
Polymarket meldde vervolgens dat het een issue had gevonden op Polymarket.com, waarbij een derde partij gecompromitteerd was. Het bedrijf gaf aan dat betrokken gebruikers worden gecompenseerd, maar noemde de leverancier niet en deelde geen nauwkeurige totalen van het verlies.
Handel weer live, maar het onderzoek ging door
Na ongeveer een uur werd de handel hervat. Polymarket beloofde alle getroffen traders terug te betalen. Toch is het voor security-teams vooral relevant dat het bedrijf een compromittering van een externe partij bevestigde—dat is precies het soort scenario dat zich leent voor een supply chain aanval.
Daarna volgden analyses vanuit de securitywereld die de link legden tussen het incident en kwaadaardige code die via een DebugBear-domein werd geserveerd.
De link met DebugBear en het RUM-script
Onderzoekers koppelen de diefstal aan malicious code die zou zijn geleverd via DebugBear, een Britse firma die performance monitoring aanbiedt. DebugBear reageerde door te bevestigen dat het platform “impacted” was door een lopend security-incident.
Het bedrijf adviseerde gebruikers van zijn Real User Monitoring (RUM)-product om hun snippet tijdelijk offline te halen. Ook gaf DebugBear aan dat ze specialistische incident responders hebben ingezet.
Wat doet het schadelijke JavaScript volgens onderzoekers?
Een securitybedrijf (Hudson Rock) stelde een kopie van de kwaadaardige JavaScript-code veilig vanaf een DebugBear-adres dat in verband werd gebracht met het Polymarket-incident. De code richtte zich op gegevens en functies die al in de geauthenticeerde webapp beschikbaar zijn.
De onderzoekers beschrijven een aanpak die zoekt naar de trading tools en portfolio-informatie van een ingelogde gebruiker. Vervolgens probeerde de code—afhankelijk van het accounttype—bijvoorbeeld om:
- posities te verkopen en de opbrengst naar een aanval-adres te verplaatsen, of
- positie-tokens direct naar een door de aanvaller ingestelde bestemming te sturen.
Belangrijk detail: Hudson Rock stelt dat de code wel materiaal lijkt te “lezen” dat verband houdt met inlogautorisatie, maar dat ze geen routine zagen die direct een wachtwoord, seed phrase of private key naar een externe endpoint stuurt. Hun conclusie is dat de kern draait om misbruik van autoriteit die al in de ingelogde applicatie aanwezig is.
Wijziging in productie: verwijdering van het script
Hudson Rock identificeerde ook een productiebuild van Polymarket met een tijdstempel van 17:59 UTC. In de wijzigingsnotitie zou zijn opgenomen dat het DebugBear-script werd verwijderd. Dat ondersteunt het idee dat Polymarket en/of de leverancier snel na ontdekking actie ondernam.
Tegelijkertijd toont het incident aan dat één verkeerde (of gecompromitteerde) webintegratie voldoende kan zijn om gebruikers tijdens het venster van misbruik te raken.
Hoe groot waren de verliezen?
De precieze schade blijft onduidelijk. Hudson Rock meldt dat een screenshot ongeveer $2,19 miljoen liet zien op een hard-coded fallback-adres van de code, maar benadrukt dat dit niet als een geverifieerde eindtelling geldt.
Een andere partij, GoPlus, rapporteert een lager of hoger bedrag afhankelijk van de meetmethode. Zij plaatsen de losses rond $2,71 miljoen op basis van on-chain analyse. Hun route-analyse zou hebben gelopen via 710 deposit wallets en 731 adressen—waarbij het niet één-op-één betekent dat het aantal adressen gelijk is aan het aantal slachtoffers.
Arkham-gegevens tonen daarnaast een vermoedelijke aanvaller-wallet met ongeveer $2,65 miljoen. Dat bedrag komt overeen met het adres dat als fallback in het script hardcoded stond.
Of een iemands transactie daadwerkelijk is uitgevoerd, hangt dus af van meerdere factoren, waaronder accounttype en beschikbare autorisaties in de webapp op het moment van het incident.
Waarom juist deze aanval zo effectief is
Dit incident past in een breder patroon: aanvallers richten zich niet alleen op kwetsbaarheden in software, maar ook op de keten eromheen. Denk aan monitoring- of analysetools die via scripts in de front-end worden geladen.
Een supply chain aanval kan daardoor:
- gebruikers bereiken zonder dat de primaire applicatie zelf een bug hoeft te hebben,
- autoriteit benutten die al aanwezig is in de ingelogde sessie, en
- zich beperken tot een specifiek platformgedeelte (in dit geval zou de Amerikaanse variant naar verluidt minder of niet geraakt zijn).
Opvallend is bovendien dat Polymarket eerder al een derde-party compromittering had gemeld waarbij een kwaadwillend script in de frontend zou zijn geïnjecteerd. Dat maakt de zaak extra urgent: securityteams moeten niet alleen patchen, maar ook leveranciersstromen strakker beheren.
Vervolg: eerder vergelijkbaar nieuws in de crypto-wereld
Op dezelfde dag dat Polymarket dit incident meldde, werd ook Binance getroffen door een aanzienlijk hack-incident. Daarvoor koppelden blockchain intelligence-partijen de aanval aan een staat-gerelateerde dreigingsactor. Los daarvan is de les in beide gevallen vergelijkbaar: wanneer scripts en transactiestromen worden beïnvloed, kan impact snel oplopen.
Voor organisaties die webapplicaties en wallets combineren, is het daarom zinvol om ook te kijken naar de bredere aanpak van supply chain risico’s in tooling en integraties. Op deze site vind je bijvoorbeeld achtergrond over hoe supply chain-prikkels en kwetsbaarheden zich vertalen naar echte schade, zoals in de Drupal Commerce Core case met actief misbruik.
Wat kun je nu doen als je RUM- of monitoring-scripts inzet?
Hoewel dit specifieke incident rond DebugBear draait, kun je uit het patroon praktische maatregelen halen. Richt je niet alleen op detectie, maar vooral op beperking van schade.
Concreet:
- Beperk welk script toegang krijgt: gebruik waar mogelijk least privilege voor webintegraties en interne APIs.
- Hanteer een snelle rollback-route: als een leverancier meldt dat een snippet gecompromitteerd kan zijn, moet het verwijderen/uitschakelen in minuten kunnen.
- Monitor ongebruikelijke acties in de front-end: verkoop- of transferpatronen die afwijken van normale gebruikersflows moeten alarms genereren.
- Voer supply chain checks uit op derde-partij assets: denk aan integriteitscontrole, versiebeheer en het bijhouden van vendor security advisories.
Deze stap is extra belangrijk omdat het misbruik in dit geval niet draait om het stelen van wachtwoorden of keys via een aparte exfiltratie, maar om het inzetten van autoriteit die al aanwezig is in een draaiende, ingelogde applicatie.
Conclusie
Polymarket zette tijdelijk de handel stil nadat gebruikers ongeautoriseerde opnames rapporteerden. De oorzaak ligt volgens onderzoekers in een supply chain aanval via een gecompromitteerd DebugBear RUM-script dat gericht was op trading-tools en portfolio-informatie van ingelogde gebruikers. De schadebedragen variëren per bron, maar de kern is helder: één derde-partij integratie kan direct leiden tot geldimpact.
Voor teams die monitoring, analytics of performance tooling in hun webfront-end laden, is dit een duidelijke oproep om supply chain risico’s als productrisico te behandelen: met snelle uitrol van fixes, strikte controle op scripts en een incidentplan dat werkt zodra een leverancier “compromised” meldt.
Wil je meer weten over hoe aanvallers misbruik maken van ketens en autorisaties? Lees dan ook de impact van een TeamViewer-kwetsbaarheid als voorbeeld van hoe snel toegang kan worden overgenomen zodra de beveiliging faalt.
Bron: https://www.securityweek.com/2-million-drained-from-polymarket-traders-in-new-supply-chain-attack/
