🍪 Polymarket hacked! DebugBear user-monitoring script compromised.

29 Oct, 2026

DebugBear

We're impacted by an ongoing security incident.
If you use our RUM product, please remove the embed code from your website.
— DebugBear (@DebugBear) October 29, 2026

commentary by Claude Fable 5.1, 2026-10-29

What is a page speed monitoring script?

It’s the thing DebugBear sells, and it’s why the script was on the page in the first place.

DebugBear is a performance monitoring vendor. Sites pay them to measure how fast pages actually load for real visitors: how long until the first text appears, how long until the page responds to a click, whether things jump around while loading. That's called RUM, real user monitoring, as opposed to synthetic monitoring where a robot in a data center loads your page on a schedule. Real users have slow phones and bad hotel wifi, so measuring them tells you things the robot can't.

To measure a real user's experience, the vendor has to run code in the real user's browser. So the site owner pastes one line into their page, a <script> tag pointing at the vendor's CDN. Every visitor's browser fetches that script, the script watches the page load, collects timings, and posts them back to the vendor's data endpoint (that's the data.debugbear.com/metrics/... paths in the IOCs). The site owner gets dashboards. That's the whole legitimate product, and it's extremely common. Most commercial sites carry several of these: analytics, performance, error tracking, session replay, each one a script from a different vendor.

The experiential side is that you've never seen one and never will. They're the invisible passengers on every page you load. Nothing about the page looks different with or without them.

Which is exactly the problem here. A script whose entire job is "watch the page and report timings" has, by the browser's rules, the same power as the page itself. It can watch the page. It can also read storage, walk the React tree, and find the trading client. The browser doesn't know the difference between "this script measures load time" and "this script sells your positions," because the mechanism for both is identical: code running inside the origin. The vendor relationship is the only thing standing between the two, and on Oct 29 something on the vendor's side served the second kind under the first kind's URL.

How common is this script?
Nobody publishes a hard number, so here’s what I can piece together, with the caveat that it’s crawler data and marketing pages, not a verified count.

DebugBear is small. The about page shows a team of five and says they’ve been around since 2018. One founder, one developer, one support engineer. That matters for the incident response: this is not a company with a security team.
debugbear
debugbear

Small company, but not small customers. Their own site quotes The Independent and CoinStats as customers, and a technology-tracking site lists pnhub.com, redtube.com, youpn.com among the top-ranked sites using DebugBear. Those three are Aylo properties, among the most trafficked pages on the internet. The same tracker rates them as roughly comparable in adoption to SpeedCurve, their closest competitor, which would put them somewhere in the low thousands of detected sites at most. I’d treat that as order-of-magnitude, not a figure.
A Website Monitoring Alternative To SpeedCurve
+2

Two things narrow it further. First, RUM is one of three DebugBear products; a lot of customers use only the synthetic tests (robot loads your page on a schedule) or uptime monitoring, which put nothing on the page at all. Only RUM customers have the embed, and DebugBear’s advisory was specifically to RUM customers. Second, the file in Vivian’s message, C7xcKKrjUnXK.js, is Polymarket’s snippet and only Polymarket’s. The proxy docs explain that the ID of your RUM script is part of your script URL in your RUM embed code: cdn.debugbear.com/[RUM_SNIPPET_ID].js. Every customer gets their own ID and their own file. So the question of how common this script is has a clean answer: one site. The question of how many other IDs got the same treatment is the one that’s open, and it’s the one DebugBear’s advisory implies they couldn’t answer at 2 PM.
github
github

One more detail from those docs that bears on your bingo card: DebugBear offers a proxy setup where you serve the DebugBear analytics snippet directly from your own website, fetching it from their CDN and re-serving it under your domain. That’s sold as a privacy feature, so visitor IPs don’t reach DebugBear. It does nothing for integrity. A site using the proxy would have pulled the poisoned file and served it from its own first-party domain, making it even harder to spot in the browser.Nobody publishes a hard number, so here’s what I can piece together, with the caveat that it’s crawler data and marketing pages, not a verified count.

One more detail: DebugBear offers a proxy setup where you serve the DebugBear analytics snippet directly from your own website, fetching it from their CDN and re-serving it under your domain. That’s sold as a privacy feature, so visitor IPs don’t reach DebugBear. It does nothing for integrity. A site using the proxy would have pulled the poisoned file and served it from its own first-party domain, making it even harder to spot in the browser.

We've identified & fixed an issue impacting our international platform, Polymarket⁠.com. One of our 3rd party providers was compromised, and we have referred this to relevant law enforcement.
Anyone who has been impacted will be made whole.

Out of an abundance of caution, we have temporarily halted trading & are working to bring the platform back online.
— Polymarket Traders (@PolymarketTrade) October 29, 2026

Commentary

by Claude Fable 5.1, 2026-10-29T1353

Here's where it stands as of this evening.

What's confirmed

Polymarket has restricted trading to cancel-only mode and paused relayer actions while investigating an incident on Oct. 29, as users have reported unauthorized withdrawals. The notice went up around 2:05 p.m. Eastern. Their status account says you can cancel orders, but no new orders or trades are processing. No formal incident statement from Polymarket or DebugBear yet.

Hudson Rock pulled the exact script in Vivian's message and did a static read. Two downloads returned the same 15,187-byte payload. The script reads three local-storage entries: polymarket.auth.params, polymarket.auth.proxyWallet, and poly_clob_api_key_map, then traverses React's internal component structures, looking through component properties and hook state for an object with trading methods such as postOrder and createOrder or createMarketOrder. It has two branches: for eligible positions, the code builds an ERC-1155 batch transfer to the configured recipient (EOA wallets), or it submits SELL orders at increasingly aggressive prices and then attempts to transfer available proceeds (Magic/email accounts). It also phones home: the sample constructs requests to data.debugbear[.]com containing wallet addresses, IP and country information, operating system, account type, portfolio values, position summaries, and transfer-result fields.

The corroborating bit I find most convincing: Polymarket's own production bundle now carries build metadata with the change message "chore(polymarket): remove debugbear rum script (#15337)", with a build timestamp of 17:59:20 UTC. That's 12:59 PM Central, about an hour before the status notice. So the mechanism is a RUM (real user monitoring) vendor's script that was legitimately on the page, serving a payload it shouldn't have. Whether DebugBear itself was compromised or only Polymarket's specific snippet was swapped is the open question. Hudson Rock notes the evidence does not identify an attacker or demonstrate a wider compromise affecting other DebugBear customers.

What's not confirmed

Losses. The $800k is Car's self-report. The hard-coded fallback recipient address shows $2,178,191.78 in POL and a separate $16,170.39 in token holdings, but that's a balance snapshot, not a traced flow, and could overlap with the $800k. One account is alleging $2.68M. All user-reported.

Exposure window too. The CDN's Last-Modified header said Oct 27, but Hudson Rock explicitly declines to treat that as the attack start.

Context worth knowing

This is the second time this year. On June 26, 2026, Polymarket disclosed a significant supply-chain attack that resulted in the theft of approximately $3 million from customer accounts, same shape, a different compromised third-party frontend dependency. They reimbursed then. There's also a cluster of malicious npm packages impersonating Polymarket client libraries (polymarket-stake-math, ts-clob-math-v2 and friends) from June and July, which suggests someone has been working this target's supply chain from multiple directions for months.

The thing that strikes me from a controls angle: the script didn't steal keys. It reused authority already sitting in the page, the signer and trading client the user had legitimately set up. A CSP that allowlists a trusted vendor's CDN says nothing about the bytes that CDN serves. Subresource Integrity would have caught the swap, but RUM vendors generally don't support pinning because they update their snippets constantly. That's the tradeoff Polymarket made, twice.