Hijacked DebugBear script drained $2.7M from Polymarket traders after DNS compromise

A DNS compromise at the web performance company DebugBear put attacker-controlled JavaScript on Polymarket's website on October 29, and the malicious code used signed-in traders' existing access to drain roughly $2.7 million. According to a RedEye Threat Intelligence report republished on dev.to, Polymarket is refunding 726 affected wallets, and on-chain records show about $2.64 million in POL reaching the attackers' wallet in under an hour.

How the script was swapped

DebugBear said on X that its DNS records were compromised through its domain registrar. Its preliminary findings point to an attack aimed at one customer's site, and it has found no evidence of a breach of its own internal systems, though that investigation continues. If the finding holds, the attackers never needed access to the vendor's servers — control over where the domain pointed was enough to place their code on the customer's page.

Researchers at Ohey observed a different server responding for DebugBear's web addresses at 18:13 UTC, with the malicious file still being served. Earlier that day, the genuine script had come from Google Cloud Storage. Each DebugBear customer loads its own copy of the script, and the file that was replaced was Polymarket's.

What the code did

Hudson Rock examined the file without running it and found nothing that exfiltrates API keys, passwords, seed phrases or private keys. Instead, the script worked from inside a trusted page. It read the account data Polymarket stores in the browser, including a set of trading API keys — which on their own cannot place orders, since orders also require a wallet signature. The code then located the page component that places orders and the signer that approves the account's transactions, and followed one of two paths: for accounts signed in with their own crypto wallet, it moved positions directly to the attackers' address; for email-based accounts, it sold positions at increasingly bad prices before moving the proceeds out.

Every request was signed by the account's own signer and handed to Polymarket's relayer, so downstream systems saw traffic that looked like any legitimate order. Hudson Rock cautions that a signing request alone does not prove a trader approved anything silently — the wallet provider may still have prompted the user, refused, or applied its own session rules, and the available reporting cannot establish how many signatures, if any, were completed without a prompt.

The on-chain timeline

Ohey's blockchain trace and Polymarket's status updates give a tight sequence, all in UTC. The attackers' wallet received its first funds at 17:10; Polymarket posted about unauthorized wallet activity at 17:38; the last inflow arrived at 18:02; the exchange moved to cancel-only mode with relayer actions paused at 18:05; and by 18:19 the wallet held 28.6 million POL, worth about $2.64 million at DefiLlama's $0.0922 price according to DefiPrime's calculation. Between 18:28 and 18:38, the funds were forwarded to three other addresses.

The numbers do not fully line up. Ohey's trace shows the wallet collecting POL and positions from 33 wallets, while Polymarket counts 726 affected wallets, and the reporting does not reconcile the two counts. The $2.64 million figure also covers only the POL tokens, not the positions the wallet gathered. Notably, the last inflow arrived three minutes before the relayer pause was announced, so the pause cannot be credited with ending the theft on timing alone.

Response and refunds

Polymarket said it removed the script within the hour, cleared caches, reset all active sessions and paused trading until the site was clean, and has referred the case to law enforcement. By October 30, 689 of the 726 wallets — about 95 percent — had been refunded in full, with the remaining 37 paid out as they were checked. A further $1.19 million is going to roughly 5,500 wallets that lost money during the trading pause or had positions taken, bringing the total being returned to $3.9 million. Traders do not need to file a claim.

DebugBear has told customers of its real user monitoring product to remove its embed code from their sites, and The Hacker News found that cdn.debugbear.com, the address that served the malicious file, had no DNS record as of November 1. Polymarket is reintroducing third-party scripts with a stricter Content Security Policy, pinned versions and sandboxing — mitigations that Hudson Rock's analysis makes concrete: a CSP that allows a trusted CDN does not check what that CDN serves, and Subresource Integrity only helps where a file can be pinned.

Why it matters

This is a third-party script supply-chain incident that never touched the victim's codebase. The trust path ran through a registrar and a DNS record, neither of which sits inside Polymarket's infrastructure, and the payload needed no stolen credentials because it ran on the same page as a live trading session, within reach of the signer. Any site that loads outside code on authenticated pages — especially pages where users sign transactions or approve payments — carries the same exposure. The practical lessons are to minimize third-party scripts on transaction pages, pin what can be pinned, and treat any unexpected signing prompt as a red flag. Questions also remain open: DebugBear's single-customer finding is preliminary, and neither company has publicly identified the attackers.