NEWS

Polymarket Pledges $3.9 Million to Victims After Third-Party Script Compromise

A hijacked DebugBear monitoring script on polymarket.com drained user wallets on October 29. Polymarket will refund $2.7M in losses plus $1.2M for downtime.

Dylan H.

News Desk

November 2, 2026
2 min read
Polymarket Pledges $3.9 Million to Victims After Third-Party Script Compromise

Overview

Polymarket, the crypto-based prediction market, has published a post-mortem of its October 29, 2026 incident and pledged $3.9 million in compensation. The compromise was traced to DebugBear, a website performance-monitoring vendor whose script was loaded on polymarket.com.

What Happened

An attacker replaced the performance-monitoring script served to polymarket.com with a malicious one. For users who had the site open during a short window, the script used their active sessions to sell positions and move funds out of their wallets. Hudson Rock described it as wallet-draining code able to find accounts, select assets, and transfer funds to an attacker-designated account.

Polymarket has not said how many users were affected.

Compensation

  • $2.7 million for initial losses
  • $1.2 million for losses tied to the hours-long shutdown
  • Eligible wallets were identified from on-chain and trading data, so no claims are required
  • As of Saturday, 95% of affected wallets had been fully refunded

Response

Polymarket removed the vendor's compromised script, paused trading, and reset all active login sessions. It redeployed the script with added integrity controls and continuous monitoring, contacted law enforcement, and is investigating the threat actor.

DebugBear is still investigating. Its initial findings point to a compromise through its domain registrar, and it says it cannot currently receive email at its domain. It says the attack targeted one customer's website and it has seen no sign of a breach of its internal systems.

Lessons for Web Defenders

  1. Third-party scripts run with your origin's privileges. Any script on a sensitive page can act as the logged-in user.
  2. Use Subresource Integrity (SRI) for static third-party scripts, and self-host or proxy vendor code where feasible.
  3. Tighten Content Security Policy to restrict script sources and outbound connections, and use report-only mode to discover what your pages load.
  4. Keep monitoring scripts off critical flows. Do not load analytics or performance tooling on wallet, checkout, or approval pages.
  5. Require step-up confirmation for high-value actions such as withdrawals, so a hijacked session alone cannot move funds.
  6. Harden registrar accounts with MFA, registry locks, and monitoring, since domain takeover can turn a vendor into an attack vector.

Sources