Hijacked DebugBear RUM Script Drained Polymarket Accounts: Every Host Besides DebugBear’s Was on the CSP
Tools

Hijacked DebugBear RUM Script Drained Polymarket Accounts: Every Host Besides DebugBear’s Was on the CSP

Polymarket said on October 30 that a third-party vendor’s performance-monitoring script on polymarket.com was replaced with code that, for some people who had the site open, used their active session to sell positions and move funds out of their wallets. Its postmortem does not name the vendor. DebugBear, a web performance monitoring service with a real-user-monitoring (RUM) product, told RUM customers on October 29 at 18:00 UTC to remove its embed code, and Ohey and Hudson Rock tie the malicious file to DebugBear’s CDN.

What happened to the DebugBear RUM script?

According to Ohey’s timeline, Cloudflare returned a 521 error for cdn.debugbear.com at 16:54 UTC on October 29, meaning it could not reach the script’s origin, and the drainer ran in logged-in sessions until Polymarket built a release without the script at 17:59 UTC. The last position tokens reached the drainer’s recipient wallet at 18:02 UTC. DebugBear posted its incident notice at 18:00 UTC and said on October 30 at 23:11 UTC that its DNS records were compromised through its domain registrar. Polymarket’s postmortem says the vendor “has confirmed the compromise publicly”.

DebugBear’s follow-up says that, based on its initial investigation, the attack “targeted the website of a specific customer” and that it has “not seen any indication of a compromise of our internal systems”, while the investigation continues. Search Engine Journal wrote on October 31 that it is not yet clear whether other DebugBear customers also received malicious code.

Why didn’t Polymarket’s CSP stop it?

A Content Security Policy host allowlist answers one question: may this host serve a script to this page. Hudson Rock cites a WhoGetsMyData scan dated October 29 that records Polymarket loading the same script URL and permitting its host in the page’s CSP; Hudson Rock says it could not retrieve the scan’s underlying evidence files. The policy did what a host allowlist is built to do; a host allowlist does not look at what the file contains.

The drainer’s calls to hosts other than DebugBear’s were covered the same way. Ohey’s analysis says: “Every other host the drainer calls appears in Polymarket’s Content Security Policy: *.polymarket.com for the APIs and relayer, *.alchemy.com for RPC and *.fun.xyz for swap quotes.” Ohey adds that the drainer carries no keys and uses the trading client the page had already built, after reading three localStorage keys. Its code sends portfolio value, positions, transaction hashes, wallet, IP address and country to three endpoints on data.debugbear.com, the hostname DebugBear’s clean RUM file sends its data to. Ohey found a different server answering for both cdn.debugbear.com and data.debugbear.com on October 29. DeFiPrime noted that to anyone watching the network those requests “would pass for the RUM product’s ordinary telemetry”.

What does SRI check that CSP doesn’t?

Subresource Integrity checks bytes. MDN describes it as letting a browser verify that a fetched resource was “delivered without unexpected manipulation” by matching it against a cryptographic hash you supply in the integrity attribute. MDN also names the exact risk here: if an attacker gains control of the third-party host, they can replace its files completely.

Ohey reports the last clean copy of the file at 60,493 bytes and the drainer at 15,187 bytes. By how SRI works, a hash of the clean file would not match the drainer. We cannot say whether SRI alone would have stopped this in Polymarket’s setup, and the sources do not say Polymarket lacked it. Hudson Rock’s advice is conditional: “Where assets can be pinned, Subresource Integrity lets the browser reject unexpected file contents.” Its warning is the useful part: “simply allowing a trusted CDN does not verify the bytes it serves.”

Polymarket’s own list of fixes is to redeploy third-party scripts with “additional integrity controls and continuous monitoring and verification (some examples include stronger CSP, explicit version pinning, sandboxing, etc)”. The postmortem also lists cleared caches and reset login sessions.

Which dollar figures are comparable?

None of them measure the same thing, so we keep them apart.

Figure What it describes Source
$3.9M What Polymarket says it is returning to traders: “the $2.7M plus $1.2M to cover pause-related losses” Polymarket postmortem
28,636,284.45 POL (about $2.6M) The POL that reached the drainer’s recipient wallet on-chain Ohey for the POL count; DeFiPrime for the dollar estimate (about $2.64M at DefiLlama’s price of $0.0922 per POL, about 18:20 UTC on October 29)
33 deposit wallets Deposit wallets whose position tokens reached the recipient (36 transfers); not a count of all affected accounts Ohey

The $3.9M is a refund total that includes pause losses, not a theft total. Polymarket says 95% of affected wallets were refunded in full as of the afternoon of October 30.

What should teams running a RUM or analytics tag do now?

Polymarket’s own wording is the starting point: the script “used their active session”. A script loaded directly into a logged-in page runs inside that page with the visitor’s privileges. Two questions follow for each tag your team owns.

  • Does it need to run on pages that can move money or change an account, such as checkout, billing, settings or a dashboard?
  • Can the file be pinned? A per-site URL like cdn.debugbear.com/<ID>.js is the pattern Ohey and Search Engine Journal describe for DebugBear’s embed. Ask each vendor whether it publishes versioned files you can hash, since a hash only works if the file behind the URL stops changing.

Some platforms already limit where third-party scripts can run. Shopify, for example, stopped running script tags on non-Plus Order status pages on August 26. The same question applies to newer measurement features that rely on site logins, such as Meta Pixel’s on-device conversion matching.

For anyone who embedded DebugBear: its guidance is to remove the embed code. Removing the tag stops new loads but does not undo anything already run, and DebugBear said on October 30 that it is continuing to investigate.

Alex Savich

Digital marketing journalist covering MarTech, AI, SEO, and analytics for Elsop Insights.