A malicious change to a third-party page-speed script on Polymarket’s site allowed attackers to use signed-in traders’ browser sessions to sell positions and siphon funds on October 29. The injected code targeted only Polymarket’s copy of a DebugBear real user monitoring (RUM) script and moved crypto to an attacker-controlled wallet in under an hour. Polymarket says it will refund roughly $2.7 million to affected wallets and is returning a total of about $3.9 million to users who lost funds directly or because trading was paused.
How the attack unfolded
Hudson Rock and other researchers traced the incident to a swapped DebugBear script file that Polymarket’s site loaded from an outside address. DebugBear later said its DNS records were compromised through its domain registrar, and early findings indicate the tampering targeted a single customer site rather than a breach of DebugBear’s internal systems. When researchers fetched the malicious file on October 29 it contained logic that could interact with a logged-in user’s open Polymarket page.
Researchers at Ohey also observed a different server answering for DebugBear web addresses while the malicious file was live. The address that served the malicious file, cdn.debugbear[.]com, had no DNS record when checked on November 1.
How the malicious script worked
The injected code re-used the permissions a trader already had in an open browser session. It read account details Polymarket stores in the page, including APIs tied to trading. Although those API keys alone cannot place orders without a wallet signature, the script located the parts of the page that initiate trades and the signer object that approves transactions.
From there the script followed two paths depending on how a trader was signed in. For wallet-signed accounts it moved positions directly to the attackers’ wallet. For accounts signed in via email, it sold positions at worsening prices and then moved the proceeds out. In both scenarios the code asked the account’s own signer to sign requests and passed those signed requests to Polymarket’s relayer for submission.
Hudson Rock noted that a signing request alone does not prove a trader signed without seeing a prompt, since a wallet provider may still show or refuse a request.
Timeline and blockchain trace
Blockchain observers recorded funds arriving at the attacker wallet between 17:10 UTC and 18:02 UTC on the day of the attack. That wallet collected 28.6 million POL tokens and positions from 33 wallets; DefiPrime’s calculation, using DefiLlama pricing, put the POL at about $2.64 million at 18:19 UTC. The attacker moved those POL tokens on to three other addresses between 18:28 and 18:38 UTC.
Polymarket’s containment and refunds
Polymarket posted its first status update about unauthorized wallet activity at 17:38 UTC and put the exchange into cancel-only mode with relayer actions paused by 18:05 UTC. The company removed the malicious script “within the hour,” cleared caches, reset active login sessions, paused trading while cleaning the site, and referred the incident to law enforcement.
By October 30, Polymarket had refunded 689 of the 726 affected wallets in full, with the remaining 37 being checked and paid. In addition to the direct refunds, Polymarket is paying about $1.19 million to roughly 5,500 wallets that lost funds during the trading pause or had positions affected — bringing the total returned to traders to about $3.9 million. Traders do not need to file claims; Polymarket’s status page links a form for anyone who believes an amount is incorrect.
What sites and traders can do
- Keep unneeded third-party code off pages where users trade or sign transactions.
- Where a file can be pinned, use Subresource Integrity (SRI) so the browser rejects altered files rather than relying on a trusted CDN alone.
- Use a stronger Content Security Policy (CSP), pinned script versions, or sandboxing when re-adding third-party scripts.
- Check what code on signed-in pages can invoke a signer or request signatures.
For traders, the core advice is simple: carefully inspect and reject any signing request you did not expect.
Why this matters
This incident is a fresh example of how supply-chain and third-party-script compromises can bypass many protections by operating from within an otherwise legitimate browser session. Even when a site’s backend is secure, anything running in a user’s browser and able to trigger signer requests presents a risk. The Polymarket case also shows the operational and financial burden of responding to such incidents: rapid containment, large-scale refunds, and post-incident hardening are costly even when a platform moves quickly to remediate.
Licensed under CC BY-ND 4.0 International