Polymarket breach exposes supply-chain risk

On October 29, malicious code running on Polymarket’s website sold positions held by signed-in traders and moved the proceeds to attackers’ wallets. The injected code had taken the place of a page-speed measurement script that the prediction market loaded from an outside vendor. Polymarket says it is refunding roughly $2.7 million to 726 affected wallets, while blockchain records show about $2.64 million in crypto reaching the attackers’ wallet in under an hour.

A vendor script turned hostile

The swapped file came from DebugBear, a service whose real user monitoring (RUM) tool measures how quickly web pages load for actual visitors. According to researchers at Hudson Rock, they downloaded the malicious file on October 29 from the address Polymarket’s site used to load the DebugBear script. They also found a change in Polymarket’s site code that removed the DebugBear script altogether.

DebugBear said on X that its DNS records were compromised through its domain registrar. Its early findings indicate the attack targeted one customer’s website, and the company said it has seen no sign of a break-in to its own systems, though it is still investigating. Because each DebugBear customer loads its own copy of the script, the file that was swapped was Polymarket’s specific version.

Researchers at Ohey observed a different server answering for DebugBear’s web addresses at 18:13 UTC, at a time when the malicious file was still online. Earlier that day, the normal script had been served from Google Cloud Storage.

Inside the wallet-draining logic

Hudson Rock reviewed the file without executing it and found that the code reuses the access a signed-in trader already holds in an open Polymarket page. It reads account details that Polymarket keeps in the browser, including a set of trading API keys.

Those API keys on their own cannot place an order on Polymarket, because orders also require a wallet signature. Hudson Rock found no part of the code that sends the keys, a password, a seed phrase, or a private key to the server it reports to. Instead, the code searches the page for the portion of Polymarket’s site that places orders and for the signer that approves the account’s transactions.

From there, it takes one of two paths. For accounts that sign in with their own crypto wallet, it moves the trader’s positions straight to the attackers’ wallet. For accounts that sign in via email, it sells positions at progressively worse prices and then moves the money out. In both cases, the code asks the account’s own signer to sign its requests and hands them to Polymarket’s relayer, which submits them.

Hudson Rock noted that a signing request alone does not prove a trader signed without seeing a prompt. The wallet provider may still ask the trader, refuse the request, or apply its own rules for the session.

Blockchain trail and timing

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. During that window, it collected 28.6 million POL tokens and positions from 33 wallets.

At 18:19 UTC, those 28.6 million POL were worth about $2.64 million at DefiLlama’s price of $0.0922, according to a calculation by DefiPrime. That figure covers only the POL, not the positions. Transaction history shows the wallet sent all 28.6 million POL on to three other addresses between 18:28 and 18:38 UTC.

Blockchain records cited in the reporting show crypto worth about $2.64 million reaching the attackers’ wallet in under an hour. Polymarket’s own refund figure is higher, at about $2.7 million, reflecting the value it is returning to affected users.

Polymarket’s response and refunds

Polymarket posted its first status update about unauthorized activity in user wallets at 17:38 UTC. At 18:05 UTC, it said its exchange was in cancel-only mode, with relayer actions paused.

The company said it removed the script “within the hour.” It also cleared every cache, reset all active login sessions, and paused trading until the site was clean. It has referred the case to law enforcement.

By October 30, 689 of the 726 affected wallets had been refunded in full, and the remaining 37 were being paid as they were checked. Polymarket is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken. In all, it 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.

What the numbers show

• $2.7 million — amount Polymarket says it is refunding to affected wallets
• 726 — number of affected wallets
• $2.64 million — crypto value that reached the attackers’ wallet, per blockchain records
• 28.6 million POL — tokens collected by the wallet between 17:10 and 18:02 UTC
• 33 — wallets from which tokens and positions were taken
• $0.0922 — price per POL at 18:19 UTC, according to DefiLlama
• 689 of 726 — wallets refunded in full by October 30
• $1.19 million — additional payment to about 5,500 wallets
• $3.9 million — total amount Polymarket is returning to traders

Advice for site operators

DebugBear has told customers of its RUM product to remove its embed code from their websites. The address that served the malicious file, cdn.debugbear[.]com, had no DNS record when The Hacker News checked on November 1.

Polymarket said it is putting third-party scripts back in place with extra checks, such as a stronger Content Security Policy (CSP), pinned versions, and sandboxing.

Hudson Rock’s advice for sites that load outside scripts includes keeping unneeded third-party code off pages where users trade or sign. Where a file can be pinned, it recommends Subresource Integrity (SRI), which lets the browser reject the file if its contents change. It also notes that a security policy which simply allows a trusted CDN does not check the files that CDN serves. Sites should examine what code on a signed-in page can ask the signer to do.

Advice for traders

For traders, Hudson Rock’s guidance is straightforward: reject any signing request they did not expect. The investigation found that the code relied on the account’s own signer, meaning a user who declines an unexpected prompt could interrupt the flow. Wallet providers may also apply their own session rules or refuse requests, though the researchers stress that a signing request alone does not confirm a trader approved it without seeing a prompt.

Polymarket’s refund process requires no claim for most users, but those who think their amount is incorrect can use the form linked from the status page.

Why this matters beyond Polymarket

The incident highlights a supply-chain risk that extends to any site embedding third-party JavaScript on pages where users transact. A vendor’s DNS compromise can turn a trusted measurement script into a tool for moving funds, even when the site’s own systems remain intact. For businesses, the case suggests that reviewing third-party code and applying integrity checks like SRI could reduce exposure. For traders, it reinforces that unexpected signing requests deserve scrutiny, regardless of the site requesting them. Polymarket’s refund of about $3.9 million addresses immediate losses, but the underlying lesson about script trust is likely to resonate across web3 and beyond.