Blockchain records show crypto worth about $2.64 million reached the hackers' wallet in under an hour, after malicious code slipped into a third‑party page‑speed script loaded by prediction market Polymarket on October 29.
How the DebugBear script was replaced
Polymarket's site loaded a Real User Monitoring (RUM) script from DebugBear; that copy of the file was swapped on October 29, researchers and the companies involved say. Hudson Rock downloaded the malicious file from the address Polymarket used to load the DebugBear script the same day, and also found a change in Polymarket's site code that removed the original DebugBear script.
DebugBear reported on X that its DNS records were compromised through its domain registrar and said early findings indicate the attack targeted one customer's website. Researchers at Ohey observed a different server answering DebugBear web addresses at 18:13 UTC while the malicious file remained online; earlier that day the genuine script had been served from Google Cloud Storage. The address that served the malicious file, cdn.debugbear[.]com, had no DNS record when The Hacker News checked on November 1.
How the injected code moved funds
Hudson Rock's review of the malicious file — performed without executing it — found the code leveraged the access an already signed‑in trader had in an open Polymarket page. It read account details Polymarket keeps in the browser, including a set of trading API keys.
The researchers note the API keys alone cannot place orders because Polymarket requires a wallet signature. The malicious script instead searched the page for the order‑placement logic and the account's signer, then pursued one of two paths. For accounts that sign in with a personal crypto wallet, the code moved positions directly to the wallet hardcoded by the attackers. For accounts signed in via email, the script sold positions at progressively worse prices before moving the proceeds out.
In both cases, the code asked the account's own signer to sign requests and handed those signed requests to Polymarket's relayer for submission. Hudson Rock cautioned that a signing request alone does not prove a trader signed without seeing a prompt, since the wallet provider could still prompt, refuse, or apply its own session rules.
Ohey's blockchain trace shows the wallet written into the code received its first funds at 17:10 UTC and its last at 18:02 UTC, collecting 28.6 million POL tokens and positions from 33 wallets during that interval. At 18:19 UTC those 28.6 million POL were worth about $2.64 million using DefiLlama's POL price of $0.0922, a figure calculated by DefiPrime. The attacker wallet moved all 28.6 million POL on to three other addresses between 18:28 and 18:38 UTC.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scramblePolymarket's mitigation and refund actions
Polymarket posted its first status update about unauthorized activity at 17:38 UTC and by 18:05 UTC had put the exchange into cancel‑only mode with relayer actions paused. The company said it removed the malicious script "within the hour," cleared caches, reset all active login sessions and paused trading until the site was clean. Polymarket has referred the case to law enforcement.
Polymarket reported it is refunding about $2.7 million to 726 affected wallets. By October 30, 689 of those 726 wallets had been refunded in full, with the remaining 37 being paid as they were checked. The company is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken; in total Polymarket is returning $3.9 million to traders. Traders do not need to file a claim; Polymarket's status page links a form for anyone who believes their amount is wrong or that they should have received a payment.
DebugBear, DNS compromise, and customer guidance
DebugBear has said its DNS records were compromised via its domain registrar and that it has seen no sign of a break‑in to its own systems so far, though it remains investigating. The company has instructed customers who use its RUM product to remove the embed code from their websites. Hudson Rock and Ohey's observations of divergent servers answering DebugBear addresses, and the disappearance of cdn.debugbear[.]com's DNS record by November 1, align with DebugBear's account that the incident involved DNS manipulation tied to the registrar.
What this means for technologists, DebugBear customers, and traders
- For technologists and security teams: Hudson Rock advises keeping unneeded third‑party code off pages where users trade or sign, pinning files where possible using Subresource Integrity (SRI) so the browser can reject changed content, and checking what code on signed‑in pages can ask a signer to do. Polymarket said it will return third‑party scripts with additional safeguards such as a stronger Content Security Policy (CSP), pinned versions, and sandboxing.
- For DebugBear customers: DebugBear has told customers to remove the RUM embed code and the observed DNS anomalies indicate customers should review registrar configurations and the origins serving their embedded files.
- For traders and end users: Hudson Rock's specific advice is to reject any signing request they did not expect; Polymarket has provided refunds to affected wallets and a dispute form for anyone who believes they were missed.
The incident threaded a DNS compromise at a registrar through a swapped third‑party script to active theft in under an hour, triggering rapid takedowns, cache clears and a multi‑million‑dollar refund effort. DebugBear and Polymarket have taken immediate mitigations and law enforcement has been notified; investigators and impacted users now face the technical task of untangling how a single served file was able to convert browser‑held access into signed transactions.
