Traders at prediction market Polymarket were hit by a sneaky cyberattack on October 29: roughly $2.7 million US in digital assets were siphoned off after a third-party “real user monitoring” (RUM) script was hijacked. The breach stemmed from malicious code replacing the genuine monitoring tool, allowing threat actors to hijack traders’ open positions or force bad trades before extracting the funds. Polymarket is reimbursing the losses and has paused trading to clean house.
How the Attack Worked: Injected Script, Stolen Access
The compromised code came from DebugBear, a service that tracks how fast web pages load for visitors. The attackers replaced the usual DebugBear script on Polymarket’s site with a corrupted version. Once loaded, the fake script searched for trading-related elements on users’ browsers, especially API keys Polymarket uses for trading. It then triggered actions to illegally move or sell users’ positions—depending on how users signed in.
For users who logged in via crypto wallets, the script transferred positions directly. For those who used email sign-ins, it sold positions at unfavorable prices before routing proceeds to hacker wallets. In both scenarios, the malicious code used the account’s own signing mechanism to mimic legitimate activity. While the API keys were accessed, no passwords or private keys were directly stolen.
Timeline, Impact & Remedy Efforts
Blockchain data shows about $2.64 million in POL tokens reached attacker wallets between 17:10 and 18:02 UTC. Polymarket responded quickly: by 17:38 UTC it acknowledged unauthorized behavior, and by 18:05 UTC it restricted its systems to cancel-only mode and paused external relayer actions. The fake script was removed within the hour, and all active sessions were cleared.
The attack affected 726 wallets. By October 30, refunds were issued to 689 users, while the rest were under review. Additionally, around 5,500 wallets that lost money due to forced trades or paused positions are being refunded—bringing the total restitution to approximately $3.9 million. No action from users is needed; Polymarket set up a status page with a form for traders who believe more is owed.
Root Cause & Prevention Advice
Investigation revealed that the domain name records (DNS) for DebugBear were compromised through its registrar. However, no breach was seen in the internal systems of DebugBear itself. Researchers noticed that when Polymarket’s site loaded the malicious code, it came from a domain answering unexpectedly, instead of via the usual Google Cloud Storage. Each Polymarket customer uses their own served copy; this one was swapped without detection until it was too late.
Polymarket plans tighter security for third-party code: stronger Content Security Policies, version pinning, sandboxing, and more rigorous vetting of external scripts. Security researchers recommend site operators avoid loading unnecessary third-party code on sensitive pages like those used for trading or signing. Implementing Subresource Integrity (SRI) could help browsers reject maliciously altered content. Users are urged to be wary of unexpected signing requests.
Why this matters: as platforms grow increasingly complex, the attack shows how supply chain and third-party script vulnerabilities remain potent threats to crypto services. Polymarket’s experience is a case study in risk from external code—especially when tied to sensitive functions like order placement or signing. Watch for stricter regulations, tighter auditing practices, and possibly even tools to monitor script integrity in real-time across DeFi, prediction markets, and crypto-enabled applications.
