Polymarket refunds traders after compromised DebugBear script
Prediction market Polymarket is refunding about $2.7 million to 726 affected wallets after malicious code replaced a DebugBear real-user monitoring script loaded by its website on October 29. Blockchain analysis found that crypto worth about $2.64 million reached an attacker-controlled wallet in less than an hour.
The incident turned a third-party page-performance dependency into a route for actions inside signed-in trading sessions. Polymarket said it removed the script within the hour, put the exchange into cancel-only mode, paused relayer actions, cleared caches, reset active login sessions and paused trading while the site was cleaned.
A compromised delivery path
DebugBear said its DNS records were compromised through its domain registrar. Its early findings indicated that the attack targeted one customer website and that there was no evidence of an intrusion into DebugBear’s own systems, although the investigation remained under way.
Researchers at Hudson Rock retrieved the malicious file from the address Polymarket used for the DebugBear script on October 29 and identified a later change removing the dependency from Polymarket’s code. Ohey observed a different server responding for DebugBear web addresses at 18:13 UTC while the malicious script was still available. Earlier that day, the normal file had been served from Google Cloud Storage.
DebugBear’s real-user monitoring product measures loading performance for visitors. Each customer loads its own copy of the script, and the swapped file was Polymarket’s. DebugBear told RUM customers to remove its embed code; the address serving the malicious file had no DNS record when it was checked on November 1.
How signed-in sessions were abused
Hudson Rock’s static review found code that reused access already available in an open, authenticated Polymarket page. It read browser-held account information, including trading API keys, but the researchers found no code exfiltrating those keys, passwords, seed phrases or private keys.
API keys alone could not submit an order because Polymarket also requires a wallet signature. The injected code instead searched the page for order-placement functions and the signer that approves transactions, then used the account’s own signer and Polymarket’s relayer to submit requests.
For users who authenticated with their own crypto wallet, the code moved positions directly to the attacker wallet. For email-based accounts, it sold positions at increasingly unfavourable prices before moving the proceeds. Hudson Rock cautioned that a signing request does not by itself establish that a trader signed without seeing a prompt: a wallet provider may prompt, block or apply session rules.
Ohey traced the attacker wallet receiving its first funds at 17:10 UTC and its last at 18:02 UTC. It collected 28.6 million POL tokens and positions from 33 wallets. At 18:19 UTC, DefiPrime valued the POL at about $2.64 million using DefiLlama’s $0.0922 price; that figure excluded the positions. The wallet sent all 28.6 million POL to three other addresses between 18:28 and 18:38 UTC.
Refunds and controls for high-risk pages
By October 30, Polymarket said 689 of the 726 affected wallets had been refunded in full, with the remaining 37 being paid after review. It also said it would pay $1.19 million to roughly 5,500 wallets that lost money during the trading pause or had positions taken, bringing total returns to $3.9 million. The company has referred the incident to law enforcement and says traders do not need to submit a claim.
Polymarket plans to restore third-party scripts with additional checks, including a stronger Content Security Policy, pinned versions and sandboxing. For organisations operating pages where users trade or sign transactions, the practical implication is to remove unnecessary external code, pin files with Subresource Integrity where possible, assess what authorised page code can ask a signer to approve, and require users to reject unexpected signing requests.