Polymarket hack moves $2.64 million via hijacked script
The Polymarket hack on October 29 used malicious JavaScript loaded by the prediction market’s website to sell some signed-in traders’ positions and transfer funds to an attacker-controlled wallet. The code replaced a third-party performance-monitoring script supplied by DebugBear. Polymarket says it is refunding about $2.7 million to 726 affected wallets, while blockchain records reviewed by researchers show that approximately $2.64 million in cryptocurrency reached the attackers’ wallet in less than an hour.
The legitimate file belonged to DebugBear’s real user monitoring (RUM) service, which measures page-loading performance for actual visitors. DebugBear said its Domain Name System (DNS) records, which direct internet traffic to the correct online destination, were compromised through its domain registrar. The company’s initial findings suggest that one customer’s website was targeted. It had found no evidence that its own systems were breached, although its investigation was continuing.
Hudson Rock researchers downloaded the malicious file on October 29 from the address Polymarket used for the DebugBear script. They also identified a subsequent change to Polymarket’s site code that removed the integration. Ohey researchers found a different server responding for DebugBear’s web addresses at 18:13 UTC while the hostile file remained available. Earlier on the same day, the normal script had come from Google Cloud Storage. DebugBear gives each customer a separate copy of the monitoring file, and the replaced copy was the one loaded by Polymarket.
Hudson Rock examined the file without executing it and found that it reused permissions already available inside an open, authenticated Polymarket page. It read account information held in the browser, including trading Application Programming Interface (API) keys, which are credentials software uses to communicate with an online service. Those keys were not sufficient to submit an order because Polymarket also required a wallet signature, an account’s cryptographic approval for a transaction.
The researchers did not find code that transmitted the API keys, a password, a seed phrase or a private key to the remote server contacted by the script. Instead, the malicious code searched the page for Polymarket’s order-placement functions and the signer responsible for approving account transactions. This meant the Polymarket hack attempted to use the website’s existing, trusted transaction process rather than extracting the trader’s most sensitive wallet credentials.
The script followed different routes depending on how the trader had signed in. For people using their own crypto wallets, it attempted to transfer trading positions directly to the attackers’ wallet. For email-based accounts, it sold positions at progressively worse prices before moving the resulting funds. In both cases, the code asked the account’s own signer to approve its instructions and passed them to Polymarket’s relayer, a service that submits signed transactions.
Hudson Rock cautioned that a request sent to a signer does not establish that a transaction was completed without the trader seeing an approval prompt. A wallet provider could still display a warning, reject the request or enforce other session rules. The practical lesson for traders is that unexpected transaction requests can be dangerous even when they appear inside a website where the user is already signed in.
Ohey’s blockchain tracing found that the wallet embedded in the malicious code received its first funds at 17:10 UTC and its last at 18:02 UTC. During that period, it collected 28.6 million POL tokens and trading positions from 33 wallets. DefiPrime calculated that the POL alone was worth about $2.64 million at 18:19 UTC, using DefiLlama’s price of $0.0922. That valuation did not include the transferred positions. Transaction records show that all 28.6 million POL were then sent to three other addresses between 18:28 and 18:38 UTC.
Polymarket issued its first status update about unauthorized wallet activity at 17:38 UTC. At 18:05 UTC, it placed the exchange into cancel-only mode, allowing existing orders to be cancelled while stopping normal trading, and paused relayer actions. The company said it removed the affected script within an hour, cleared its caches, ended every active login session and suspended trading while it checked that the site was clean. It has referred the incident to law enforcement.
By October 30, Polymarket said 689 of the 726 affected wallets had received full refunds. Payments to the remaining 37 were being processed as their cases were checked. The company is separately paying $1.19 million to about 5,500 wallets that lost money during the trading interruption or had positions taken, bringing its total planned return to traders to $3.9 million. Users do not need to submit claims, although the status page provides a form for anyone who believes a payment is missing or incorrect.
DebugBear advised RUM customers to remove its embed code from their websites. When The Hacker News checked on November 1, cdn.debugbear.com no longer had a DNS record. Polymarket said it would restore third-party scripts with additional controls, including pinned versions, sandboxing and a stronger Content Security Policy (CSP), which limits what outside resources a browser is permitted to load or run.
Hudson Rock recommends keeping unnecessary outside code away from pages where users trade or approve transactions. Where a file can be fixed to a known version, sites can use Subresource Integrity (SRI), a browser check that rejects the file when its contents no longer match an expected value. Merely allowing a trusted content delivery address through a security policy does not verify every file served from that address. Site operators should also examine what code running on an authenticated page is able to ask a transaction signer to approve.
This incident also highlights the importance of understanding where DNS trust sits in a website’s supply chain; AEU DNS provides private, secure DNS for everyone, although the compromise reported here involved registrar-managed records used by an external script provider. For website owners, the central issue is that code loaded from another domain can inherit access to a sensitive signed-in page, making script removal, strict browser controls and careful transaction approval important parts of limiting exposure.