← BACK TO FEED
Polymarketsupply chain attackcrypto securityDNS hijackingweb3

Polymarket Traders Lose $2.7M After Hackers Swap a Page-Speed Script

Hackers compromised DebugBear's DNS records to replace a page-speed script loaded by prediction market Polymarket with malicious code, which exploited signed-in traders' existing account access to steal approximately $2.7 million from 726 wallets in under an hour on October 29. The malicious script used each account's own signing mechanisms to move positions and funds directly to the hackers' wallet, without needing to steal passwords or private keys. Polymarket responded by pausing trading, removing the script, and is refunding around $3.9 million in total to affected traders and those impacted by the trading pause.

On October 29, someone quietly replaced a performance monitoring script on Polymarket's website with malicious code. Within an hour, roughly $2.64 million in crypto had drained from 726 trader accounts into a hacker-controlled wallet. Polymarket has since committed to refunding around $3.9 million in total, covering both direct losses and knock-on damage from the trading pause.

The compromised script belonged to DebugBear, a real user monitoring tool that site owners embed to track page load times for actual visitors. Each customer loads their own copy. The attacker didn't breach DebugBear's infrastructure directly — they went after its DNS records via the domain registrar, redirecting Polymarket's copy of the script to a malicious version hosted elsewhere. Researchers at Ohey spotted a different server answering for DebugBear's domains at 18:13 UTC. Earlier that day, the legitimate file had been serving from Google Cloud Storage.

Hudson Rock obtained and analysed the malicious file without executing it. The code didn't phish for passwords or seed phrases. It was more surgical than that.

Polymarket, like many crypto-adjacent platforms, stores trading API keys in the browser for signed-in users. The injected code read those keys directly from the page. But API keys alone can't authorise trades — Polymarket orders also require a wallet signature. So the script went looking for the signing component already present on the page.

For users signed in via a crypto wallet, it simply transferred their positions straight to the attacker's address. For email-based accounts, it sold positions into progressively worse prices, then swept the proceeds out. In both cases, the account's own signer was used to authorise the requests, which were then passed to Polymarket's relayer for execution. Hudson Rock noted this doesn't definitively prove traders saw no prompt — wallet providers can still surface a confirmation or apply session-level rules — but the speed and scale of the drain suggests most didn't.

The receiving wallet logged its first transaction at 17:10 UTC and its last at 18:02 UTC. In that window, it accumulated 28.6 million POL tokens and positions from 33 wallets. At 18:19 UTC, those POL tokens were worth approximately $2.64 million. By 18:38 UTC, the funds had been dispersed to three separate addresses.

Polymarket flagged unauthorised activity at 17:38 UTC and switched to cancel-only mode by 18:05 UTC. The script was removed within the hour, caches were cleared, all active sessions were invalidated, and trading was halted. Law enforcement has been notified.

By October 30, 689 of the 726 affected wallets had been refunded. The remaining 37 were being processed. On top of direct losses, Polymarket is also compensating around 5,500 wallets that suffered losses during the trading pause or had positions affected — bringing the total payout to $3.9 million. No claims process is needed; affected users are being paid automatically, with a form available for anyone who thinks their amount is wrong.

DebugBear has advised all customers using its RUM embed to remove it from their sites. The CDN subdomain that served the malicious file appeared to have no DNS record as of November 1.

Polymarket says it's reinstating third-party scripts with tighter controls: stricter Content Security Policies, pinned script versions, and sandboxing.

Hudson Rock's practical takeaways for site operators are worth paying attention to. Strip unnecessary third-party scripts from any page where users transact or sign. Where possible, use Subresource Integrity — SRI lets the browser reject a file if its contents don't match a known hash, meaning a compromised CDN can't silently swap the file. Simply allowlisting a trusted CDN domain in your CSP doesn't verify what that CDN actually serves. And audit what your signing components can be instructed to do by other code on the same page.

For traders: if a signing request appears that you didn't initiate, reject it. That's the whole advice, and it's not complicated.

READ NEXT
Polymarket Loses Up to $2.7 Million After Third-Party Script Goes RogueDrainer-as-a-Service: How Crypto Wallet Theft Became a Subscription BusinessNetamLoader: Sophisticated Malware Quietly Targets Asian Government Windows Builds