Polymarket Suffers $2.7 Million Wallet Drain Via Compromised Third-Party Script
The prediction market platform **Polymarket** recently experienced a significant security incident, resulting in approximately $2.7 million in user funds being siphoned off. Attackers compromised a third-party script from **DebugBear**, injecting malicious code that drained signed-in traders' wallets. **Polymarket** has since refunded affected users and implemented enhanced security measures.
On October 29, malicious code injected into **Polymarket**'s website enabled attackers to sell signed-in traders' positions and transfer funds to their own wallets. The breach, which saw roughly $2.64 million in crypto move to the attackers' wallet in under an hour, prompted **Polymarket** to refund approximately $2.7 million to 726 affected wallets.
The attack vector was a compromised page-speed script loaded from **DebugBear**, a company providing real user monitoring (RUM) tools. Researchers at **Hudson Rock** and **Ohey** quickly identified the malicious file and the removal of the legitimate **DebugBear** script from **Polymarket**'s site code.
**DebugBear** confirmed that its DNS records were compromised through its domain registrar, indicating a targeted attack on one customer's website rather than a breach of its internal systems.
### How the Script Drained Funds
**Hudson Rock**'s analysis of the malicious file revealed its sophisticated method of operation. The code leveraged existing access within an open **Polymarket** page, reading account details and trading API keys stored in the browser. Crucially, it did not transmit sensitive information like private keys or seed phrases to an external server.
Instead, the malicious script directly interacted with **Polymarket**'s site components responsible for placing orders and approving transactions. For accounts signed in with a crypto wallet, it moved positions directly to the hackers' wallet. For email-signed accounts, it sold positions at increasingly unfavorable prices before transferring the proceeds.
In both scenarios, the code compelled the account's own signer to approve the fraudulent requests, which were then submitted via **Polymarket**'s relayer. **Ohey**'s blockchain trace showed the attackers' wallet receiving 28.6 million **POL** tokens and positions from 33 wallets between 17:10 UTC and 18:02 UTC, totaling an estimated $2.64 million.

### Polymarket's Swift Response and Refunds
**Polymarket** responded rapidly, issuing its first status update on unauthorized activity at 17:38 UTC. By 18:05 UTC, the exchange was placed in cancel-only mode, pausing relayer actions. The company stated it removed the malicious script within an hour, cleared caches, reset login sessions, and paused trading until the site was secured. Law enforcement has been engaged.
As of October 30, **Polymarket** had fully refunded 689 of the 726 affected wallets, with the remainder being processed. Additionally, **Polymarket** is compensating approximately 5,500 wallets that incurred losses during the trading pause or had positions taken, bringing the total refund amount to $3.9 million. Users do not need to file claims, though a form is available for discrepancies.
### Lessons for Sites and Users
**DebugBear** has advised its RUM product customers to remove its embed code from their websites. The compromised address, `cdn.debugbear[.]com`, had no DNS record as of November 1.
**Polymarket** is reintroducing third-party scripts with enhanced security, including a stronger Content Security Policy (**CSP**), pinned versions, and sandboxing.
**Hudson Rock** offers critical advice for websites loading external scripts:
* Avoid loading unnecessary third-party code on pages where users conduct trades or sign in.
* Implement **Subresource Integrity (SRI)** where possible. This allows browsers to reject files if their content changes, preventing supply chain attacks even from trusted CDNs.
* Thoroughly audit what actions code on a signed-in page can prompt the user's signer to perform.
For individual traders, the advice remains consistent: always reject any signing request that was not explicitly initiated or expected.