Na een verstoring op zijn internationale handelsplatform heeft Polymarket bekendgemaakt dat het 3,9 miljoen dollar terugkeert aan getroffen traders. De aanleiding wordt in verband gebracht met een supply chain-aanval waarbij een malafide script via een derde partij in de webomgeving terechtkwam. Tegelijkertijd deelt beveiligingsmonitor DebugBear nieuwe details: volgens hen zijn DNS-gegevens gecompromitteerd via hun domeinregistrar.
Voor gebruikers betekent dit vooral dat er niet alleen sprake was van een “websiteprobleem”. De code richtte zich op ingelogde sessies en kon posities beïnvloeden of assets verplaatsen. Hieronder leggen we de kern van wat er gebeurde uit, wat Polymarket en DebugBear al hebben gedaan, en welke lessen organisaties kunnen meenemen.
Wat er gebeurde bij Polymarket
Op 29 oktober stopte Polymarket de handel op zijn internationale platform nadat gebruikers melding maakten van ongeautoriseerde opnames. Onderzoekers van Hudson Rock legden uit dat de aanval te linken was aan malafide JavaScript dat vanaf een DebugBear-adres werd aangeboden en door de Polymarket-site werd geladen.
Het script richtte zich specifiek op traders die ingelogd waren. Vervolgens controleerde de code de portfolio-informatie van de bezoeker en voerde daarna acties uit die passen bij het verplaatsen van waarde. Daarbij werd volgens de waarnemingen gebruikgemaakt van de bestaande handelsrechten van de open sessie.
Belangrijk detail: Hudson Rock zag geen aanwijzingen dat gevoelige geheimen zoals wachtwoorden, seed phrases of private keys werden meegestuurd. De aanval leek dus minder op het “stelen van credentials” en meer op het misbruiken van wat al geautoriseerd was in de browser.
Hoeveel terugbetaling Polymarket uitkeert
Polymarket publiceerde op 30 oktober een update over de impact. In totaal zouden 726 wallets zijn geraakt. Op dat moment waren bijna alle getroffen partijen al gecompenseerd; een kleine groep moest nog worden uitbetaald op basis van aanvullende verificatie van de details.
Naast het herstellen van individuele accounts compenseert Polymarket ook schade door de handelsstilstand. Volgens de laatste cijfers gaat het om 1,19 miljoen dollar verspreid over ongeveer 5.500 wallets, bovenop het bedrag dat direct was gestolen. Door die optelsom komt de totale uitbetaling uit op 3,9 miljoen dollar.
De rol van DNS bij de supply chain-aanval
In parallel met de Polymarket-updates bracht DebugBear zelf informatie naar buiten over de technische oorzaak. Het bedrijf, dat met real user monitoring (RUM) webpagina’s en laadtijden meet, stelt dat zijn DNS-records waren aangepast.
Volgens DebugBear kwam die wijziging tot stand via de domeinregistrar. Het bedrijf geeft aan dat het daardoor op dat moment geen e-mails kon ontvangen die naar het domein werden gestuurd. Ook zegt DebugBear dat de aanval zich leek te richten op één klantwebsite, maar benadrukt dat het een voorlopige bevinding is.
Wat is “DNS hijack Polymarket” in dit dossier?
De term die in dit incident centraal staat, is dat DNS-gegevens van een derde partij (DebugBear) werden gemanipuleerd, waarna het verkeer vanaf die bron in de keten terechtkwam. Wanneer een domein via DNS anders wordt omgezet, kan een websitebezoeker uiteindelijk code ophalen van een adres dat niet overeenkomt met wat men verwacht.
In dit geval werd de malafide JavaScript dus gehost via infrastructuur die gekoppeld was aan de gecompromitteerde bron. Polymarket koppelt de aanval aan een gecompromitteerde derde partij en gaf aan de betreffende provider binnen een uur te hebben verwijderd.
DebugBear heeft nog niet openbaar gemaakt hoe de aanvallers toegang kregen op registrar-niveau. Het bedrijf geeft ook aan dat er geen indicaties waren dat zijn interne systemen waren overgenomen. Het onderzoek loopt dus nog.
Polymarket: provider verwijderd, verder onderzoek met opsporingsinstanties
Polymarket laat weten dat het de gecompromitteerde derde partij heeft uitgezet zodra het incident werd opgemerkt. Daarna startte het platform een onderzoek in samenwerking met externe partijen en wetshandhaving.
Daarnaast kondigt Polymarket aan dat het later een postmortem wil delen. Daarmee kunnen betrokkenen hopelijk beter begrijpen waar in de supply chain de fout is ontstaan, welke controles ontbraken of tekortschoten, en welke verbeteringen direct zijn doorgevoerd.
Waarom dit zo schadelijk is: sessierechten in de browser
Een opvallend aspect is dat de aanvallers niet per se hoefden te “inloggen” of wachtwoorden te stelen. Doordat het script op ingelogde sessies werkte, kon het gebruikmaken van bestaande autorisaties in de open browsercontext.
Dat is een risico dat vaak onderschat wordt bij webgebaseerde toepassingen: zelfs als gebruikers “niets invullen” of geen verdachte downloads doen, kan een script dat draait in de juiste context wel acties triggeren die normaal alleen via de interface mogelijk zijn.
Dit maakt monitoring en beperking van derde-partij scripts extra belangrijk. Ook helpt het als er sterke checks bestaan rond transacties (bijvoorbeeld strengere validatie, frictie bij risicovolle acties of beperkingen op wat scripts mogen doen).
Lessen voor organisaties met third-party scripts
Los van dit concrete geval zijn er meerdere praktische aandachtspunten die dit incident onderstreept.
- Beperk en verifieer third-party integraties: weet precies welke scripts geladen worden, van waar, en welke versie of bron daarbij hoort.
- Monitor op afwijkende uitvoer: let niet alleen op beschikbaarheid, maar ook op gedrag (bijv. ongebruikelijke netwerkrequests of transactiepaden).
- Hardening van DNS en registrar accounts: MFA, strikte toegang, en snelle detectie van wijzigingen kunnen DNS-manipulatie beperken.
- Incident response die snel uitschakelt: Polymarket geeft aan snel te hebben verwijderd; hoe sneller ketens worden onderbroken, hoe kleiner de schade.
- Transactie- en sessiebeperkingen: voorkom dat scripts in één stap gevoelige acties kunnen uitvoeren zonder adequate bescherming.
Als je bredere context wilt over vergelijkbare verstoringen en aanvallen op netwerk- of applicatielaag, dan kan dit helpen: bekijk bijvoorbeeld ook hoe je signalen van Network-layer DDoS herkent. Dat staat los van DNS, maar gaat wel over het tijdig herkennen van afwijkingen voordat de schade maximaal wordt.
Vergelijkbare incidenten: vaker supply chain, vaker scripts
Dit dossier past in een patroon waarbij aanvallers niet direct in de “kern” hoeven te zitten. Eerdere berichten binnen de industrie wijzen al op incidenten waarbij een derde partij of provider een script toevoegde dat vervolgens op de frontend misbruik mogelijk maakte.
Voor teams die afhankelijk zijn van externe monitoring, analytics, advertenties of performance tooling is het daarom essentieel om supply chain-risico’s te behandelen als een structurele cyberuitdaging, niet als een eenmalige checklist. DebugBear geeft bovendien aan dat het incident via registrar-niveau is verlopen, wat nogmaals laat zien dat niet alleen de applicatie, maar ook infrastructuur rondom domeinen aandacht vraagt.
Wil je ook een voorbeeld van hoe supply chain-aanvallen financiële impact kunnen hebben, dan is een eerder Polymarket-supply chain-incident een nuttige referentie om te zien hoe dit soort mechanismen zich kan herhalen.
Conclusie: DNS hijack Polymarket toont ketenrisico
De terugbetaling van 3,9 miljoen dollar door Polymarket maakt zichtbaar dat dit geen “kleine storing” was. De kern lijkt te liggen in een supply chain-aanval waarbij DNS hijack Polymarket indirect leidde tot het laden van schadelijke JavaScript via een derde partij.
DebugBear stelt dat zijn DNS-records via de domeinregistrar werden gecompromitteerd. Polymarket reageerde snel door de provider te verwijderen en werkt daarnaast aan onderzoek en verdere transparantie. Voor organisaties is dit een duidelijke waarschuwing: zet supply chain-controles, DNS-beveiliging en gedragssurveillance hoog op de prioriteitenlijst, zeker wanneer third-party code in browsers draait.
