-
Attackers swapped a trusted outside script on Polymarket’s site on October 29. It sold traders’ positions and sent the money to the hackers.
-
Polymarket says it will return $3.9 million. Traders do not need to file a claim.
-
Researchers found no sign that passwords or private keys were taken. Open, signed-in sessions were enough.
Hackers took about $2.7 million from Polymarket traders on October 29. They did not crack the company’s contracts. Instead, they swapped a small script that the website borrowed from a vendor.
That script ran inside traders’ browsers and used their open, signed-in sessions. As a result, 726 wallets lost money or positions in under an hour. Polymarket has promised to make everyone whole.
Polymarket’s Domain Records Compromised
Polymarket is a platform that offers prediction markets whereby people make bets on actual events. Their international platform had incorporated a speed testing script by DebugBear, a company located in the UK. The tool is used to measure how fast the webpages load to real-time visitors. On October 29, someone replaced that script with malicious code.
DebugBear says attackers compromised its domain records through its domain registrar. In plain terms, DebugBear’s web addresses started pointing to a different server. That server then handed Polymarket’s site a rigged file.
DebugBear says early signs point to one targeted customer. It has found no break-in to its own systems, though it is still checking. Meanwhile, it has told customers to remove its code from their sites.
How the Script Worked
Security firm Hudson Rock studied the file without running it. The code read account details that the site stores in the browser. Then it searched the page for the parts that place orders and approve transactions. Next, it asked the trader’s own account to sign its requests.
The method depended on how a trader logged in. For people using their own crypto wallet, the code moved positions straight to the hackers’ wallet. For email users, it sold positions at worsening prices and moved the cash out. Hudson Rock found no code that sent keys, passwords or seed phrases to the attackers.
One caution applies. A signing request does not prove a trader signed without seeing a prompt. The wallet provider may still ask, refuse or apply its own rules.
Blockchain records show the exact attack timeline. The hackers moved the first chunk of money into their wallet at 17:10 UTC, and by 18:02 UTC, they’d finished, pulling in 28.6 million POL tokens, about $2.64 million in value. After that, they shipped everything out to three different addresses between 18:28 and 18:38 UTC.
Polymarket sounded the alarm at 17:38 UTC. Not long after, someone tweaked the site’s code and took out the DebugBear script at 17:59 UTC. By 18:05 UTC, the exchange had flipped into cancel-only mode and put its relayer, basically the thing that processes trades, on pause. Trading on Polymarket’s global site sat frozen for about an hour.
Polymarket’s Response to the Attack
The company says it removed the script within the hour. It also cleared every cache, reset all active login sessions and referred the case to law enforcement. Reports say the separate U.S. site was not affected.
Polymarket has also faced separate claims about user data exposure. The company previously denied a hacker’s claim that personal information belonging to 300,000 users had been breached.
Refunds moved quickly. By October 30, Polymarket had repaid 689 of the 726 affected wallets in full. It was paying the other 37 as each one cleared a check. In addition, it is sending $1.19 million to about 5,500 wallets that lost money during the pause or had positions taken. Together, the payouts total $3.9 million.
Traders do not need to apply. Still, a form on Polymarket’s status page lets anyone dispute their amount. The company is also putting outside scripts back with tighter checks, including a stronger security policy, pinned versions and sandboxing.
Why the Safeguards Missed It
Polymarket’s browser security policy already trusted DebugBear’s address. The address never changed. Only the file behind it did. Therefore, the browser saw nothing wrong. One researcher estimated about fifty minutes of exposure.
Hudson Rock offers three fixes for sites that load outside code. Firstly, it is crucial to remove all unnecessary third-party scripts from trading and registration pages. Secondly, a Subresource Integrity test should be carried out to reject any changes in the files.
Lastly, one should assess the requests that the code can make on signed-in pages. A rule that simply trusts a vendor’s address does not check the files that vendor serves.
The Estimated Loss from the Account
Reports do not agree on every figure. Polymarket counts 726 wallets and about $2.7 million. Analytics firms tracked 710 to 737 wallets, with estimated losses ranging from $2.2 million to $2.7 million. Methodology and timing account for most of the difference. Also, the $2.64 million figure covers only the POL tokens, not the seized positions.
Although the name DebugBear has not been used by Polymarket itself, DebugBear acknowledged an attack and asked its users to delete its code. It remains unclear whether the attack impacted the other sites.
It’s also worth noting that this is not the first attack that Polymarket experienced this year. In June, another vendor breach led to draining around $3 million from a limited number of accounts using another technique. However, it is clear that in both cases, the attackers exploited the same vulnerability.
For now, the advice is simple. Reject any signing request you did not expect. Since Polymarket reset all user sessions, you will have to log in again. Afterward, you may verify your balance using the status page form if the refund seems odd.
