Malicious code on the prediction market website Polymarket sold the positions of some connected traders and transferred their funds to hackers on October 29. The code had replaced a page-speed script loaded by the site from an outside company.
Polymarket says it has refunded approximately $2.7 million to 726 affected wallets. Blockchain records show that crypto worth around $2.64 million reached the hackers’ wallet in less than an hour.
The replaced script came from DebugBear, whose Real User Monitoring (RUM) tool measures the loading speed of web pages for real visitors.
Hudson Rock researchers downloaded the malicious file on October 29 from the address used by the Polymarket site to load the DebugBear script. They also discovered a change in the Polymarket site’s code that removed the DebugBear script.
DebugBear’s DNS records were compromised through its domain registrar, the company said on X. Its initial findings indicate that the attack targeted a client’s website. He hasn’t seen any signs of intrusion into his own systems, although he continues to search.
Ohey researchers found another server responding to DebugBear’s web addresses at 6:13 p.m. UTC, while the malicious file was still online. Earlier today, the normal script was streamed from Google Cloud Storage. Each DebugBear client loads its own copy of the script and the file exchanged was Polymarket’s.
How the screenplay cost money
The code reuses access a logged-in trader already has on an open Polymarket page, Hudson Rock discovered after examining the file without running it. It reads the account details that Polymarket maintains in the browser, including a set of trading API keys.
These API keys alone cannot place an order on Polymarket, as orders also require a wallet signature. Hudson Rock could not find any part of the code that sends keys, a password, a seed phrase, or a private key to the server it depends on.
Instead, the code searches the page for the part of the Polymarket site that places the orders and the signer who approves the account’s transactions.
He then takes one of the following two paths. For accounts that log in with their own crypto wallet, the trader’s positions are transferred directly to the hackers’ wallet. For accounts that connect via email, it sells positions at lower and lower prices and then withdraws the money.
In both cases, the code asks the account signatory to sign their requests and forwards them to the Polymarket relay, which submits them. Hudson Rock said a signature request alone does not prove that a merchant signed without seeing a prompt. The wallet provider can always ask the trader, refuse or apply its own rules for the session.
The wallet written in the code received its first funds at 5:10 p.m. UTC and its last at 6:02 p.m. UTC, according to Ohey’s blockchain trace. During this period, it collected 28.6 million POL tokens and positions from 33 wallets.
As of 6:19 p.m. UTC, that 28.6 million POL was worth about $2.64 million at DefiLlama’s price of $0.0922, DefiPrime calculated. The figure only covers the POL, not the positions.
The wallet sent the 28.6 million POL to three other addresses between 6:28 p.m. and 6:38 p.m. UTC, its transaction history shows.
Response and refunds from Polymarket
Polymarket issued its first status update regarding unauthorized activity in user wallets at 5:38 p.m. UTC. At 18:05 UTC, he said his exchange was in cancel-only mode, with relay actions suspended.
The company said it removed the script “within the hour.” It also cleared all caches, reset all active login sessions, and suspended trading until the site was clean. He referred the matter to law enforcement.
As of October 30, 689 of the 726 affected wallets had been fully refunded, and the remaining 37 were in the process of being paid as they were verified. Polymarket is also paying $1.19 million to approximately 5,500 wallets that lost money during the trading break or whose positions were taken. In total, it brings in $3.9 million for traders.
Merchants do not need to file a claim. Polymarket’s status page has a form for anyone who thinks their amount is wrong or that they should have received a payment.
What sites and merchants can do
DebugBear has asked customers of its RUM product to remove its embedded code from their websites. The address that served the malicious file, cdn.debugbear(.)com, had no DNS records when The Hacker News checked on November 1.
Polymarket said it was rolling back third-party scripts with additional controls, such as a stricter Content Security Policy (CSP), pinned builds and sandboxing.
Hudson Rock’s tips for sites that load external scripts:
- Keep unnecessary third-party code off pages where users interact or sign.
- When a file can be pinned, use subresource integrity (SRI), which allows the browser to reject the file if its contents change. A security policy that simply allows a trusted CDN does not verify the files served by the CDN.
- Check what code on a login page might ask the signer to do.
Hudson Rock’s advice to traders is to reject any signing request they weren’t expecting.
Gn bussni
