Polymarket traders drained $2.7M via hijacked DebugBear script

Malicious code loaded through a third-party monitoring script drained about $2.7 million from 726 Polymarket wallets on October 29, 2026. The script came from DebugBear, a real-user-monitoring (RUM) vendor whose snippet Polymarket embedded. Polymarket's own status timeline and its post on X are the primary record; The Hacker News and SecurityWeek corroborate the figures.

How the drain worked

This is a client-side supply-chain attack. The malicious JavaScript, served in place of DebugBear's normal page-speed script, read account data stored in signed-in traders' browsers — including trading API keys — and located the order-placement and signing components. From there it behaved two ways, per security firm Hudson Rock:

• For wallet-signed accounts, it moved positions straight to the attacker's wallet.
• For email-login accounts, it sold positions at worsening prices, then moved the proceeds.

Requests were routed through Polymarket's own relayer, reusing authority the authenticated app already held rather than stealing credentials outright. Blockchain records show roughly $2.64 million reaching the attacker within about an hour.

Indicators

The attacker wallet and the rogue delivery host, as reported and visible on-chain:

Attacker wallet (Polygon): 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18
Malicious script host:     cdn.debugbear[.]com   (no DNS record as of Nov 1)

The wallet received 28.6 million POL and positions from 33 wallets between 17:10 and 18:02 UTC, then forwarded funds to three addresses between 18:28 and 18:38 UTC (Polygonscan). Independent trackers put losses close to the same figure — GoPlus at ~$2.71M, Arkham at ~$2.65M.

What the vendors say

DebugBear says its DNS records were compromised through its domain registrar, that the rogue script was served from a host separate from its normal Google Cloud Storage origin, and that early findings point to one targeted customer. It reports no break-in to its own systems and has told RUM customers to remove its embed code while it investigates.

Polymarket posted its first notice at 17:38 UTC, switched the exchange to cancel-only at 18:05, removed the script within the hour, cleared caches, reset login sessions, and referred the case to law enforcement. By October 30 it had refunded 689 of the 726 drained wallets; it says total returned to traders reached $3.9 million, including about $1.19 million to ~5,500 wallets for trading-pause losses. Polymarket's US platform was reported unaffected.

Action checklist

1. If you embed any third-party RUM/analytics/page-speed script, audit it now — DebugBear specifically, but treat every externally hosted <script> as in scope.
2. Pin and sandbox third-party scripts. Serve them with Subresource Integrity, a strict Content-Security-Policy, and version pinning so a swapped file fails closed. Polymarket says it will restore scripts only under these controls.
3. Scope browser-held secrets. Trading or API keys reachable from page JavaScript are reachable by any injected script; keep signing authority out of the DOM where possible.
4. Lock down registrar and DNS. The root cause here was a registrar-level DNS takeover — enable registrar lock, MFA, and DNS change alerts on your own domains.

Context

A trusted analytics or monitoring tag is a direct path into every logged-in session, and attackers have worked this seam repeatedly — from Magecart card skimmers to the Polyfill.io hijack to this crypto-specific variant that converts DOM access into on-chain theft. The twist here is the compromise point: not the vendor's servers but its DNS at the registrar, which let the attacker serve a drop-in replacement from a look-alike host without touching DebugBear's infrastructure. Every third-party script you load is a decision to trust that vendor's weakest control, and DNS is one most sites never audit on a supplier.