The original text is in EN, taken from the source site. Source ↗

Malicious code on the website of prediction market Polymarket sold some signed-in traders' positions and moved their funds to the hackers on October 29. The code had replaced a page-speed script that the site loaded from an outside company.

Polymarket says it is refunding about $2.7 million to 726 affected wallets. Blockchain records show crypto worth about $2.64 million reached the hackers' wallet in under an hour.

The replaced script came from DebugBear, whose real user monitoring (RUM) tool measures how fast web pages load for real visitors.

Researchers at Hudson Rock 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.

DebugBear's DNS records were compromised through its domain registrar, the company said on X. Its early findings indicate the attack targeted one customer's website. It has seen no sign of a break-in to its own systems, though it is still looking.

Researchers at Ohey found a different server answering for DebugBear's web addresses at 18:13 UTC, when the malicious file was still online. Earlier that day, the normal script had been served from Google Cloud Storage. Each DebugBear customer loads its own copy of the script, and the file that was swapped was Polymarket's.

How the Script Took the Money

The code reuses the access a signed-in trader already has in an open Polymarket page, Hudson Rock found after reviewing the file without running it. It reads account details that Polymarket keeps in the browser, including a set of trading API keys.

Those API keys alone cannot place an order on Polymarket, because orders also need 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 part of Polymarket's site that places orders, and for the signer that approves the account's transactions.

It then takes one of two paths. For accounts that sign in with their own crypto wallet, it moves the trader's positions straight to the hackers' wallet. For accounts that sign in via email, it sells positions at ever-worse prices and then moves the money out.

In both paths, the code asks the account's own signer to sign its requests and hands them to Polymarket's relayer, which submits them. Hudson Rock said a signing request alone does not prove a trader signed without seeing a prompt. The wallet provider may still ask the trader, refuse, or apply its own rules for the session.

The wallet written into the code received its first funds at 17:10 UTC and its last at 18:02 UTC, according to Ohey's blockchain trace. In that time, 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, DefiPrime calculated. The figure covers only the POL, not the positions.

The wallet sent all 28.6 million POL on to three other addresses between 18:28 and 18:38 UTC, its transaction history shows.

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 thinks their amount is wrong or that they should have received a payment.

What Sites and Traders Can Do

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:

  • Keep unneeded third-party code off pages where users trade or sign.
  • Where a file can be pinned, use Subresource Integrity (SRI), which lets the browser reject the file if its contents change. A security policy that simply allows a trusted CDN does not check the files that CDN serves.
  • Check what code on a signed-in page can ask the signer to do.

Hudson Rock's advice for traders is to reject any signing request they did not expect.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.