DebugBear tells RUM customers to remove its script after a DNS hijack

DebugBear tells RUM customers to remove its script after a DNS hijack

31 October 2026: DebugBear, whose real user monitoring (RUM) product measures how fast pages load for real visitors, has told customers to take its embed code off their websites after an attacker took over its DNS through its domain registrar and served a malicious script in place of one customer's copy. That customer was Polymarket, where the replaced script sold or moved signed-in traders' positions on 29 October.

Not yet independently verified. DebugBear's own statement was posted on X, and its website returned a server error when we tried to read it on 1 November, so the registrar detail and the advice to customers come from The Hacker News's reading of that post. Polymarket's status page confirms the vendor compromise but does not name DebugBear. We will update this when it can be confirmed, and remove this note.

How the script was swapped

According to The Hacker News, DebugBear said on X that its DNS records were compromised through its registrar, that its early findings point to one targeted customer website, and that it had seen no sign of a break-in to its own systems while it kept looking. Each DebugBear customer loads its own copy of the script. Researchers cited in the same report found a different server answering for DebugBear's addresses at 18:13 UTC on 29 October, while earlier that day the normal script had been served from Google Cloud Storage.

That detail is the lesson for anyone running third-party code. Nothing in DebugBear's code or storage had to change. Whoever controlled the name controlled what every browser loading it received, and a Content Security Policy that allows a vendor's host by name does nothing to check the file that host returns.

When The Hacker News checked on 1 November, the script address, cdn.debugbear.com, had no DNS record. DebugBear's website also returned a server error when we tried to read it that day.

What the script did on Polymarket

Polymarket's own status update says "a third-party vendor whose performance-monitoring script loaded on polymarket.com was compromised" and that the attacker replaced it with one "built to target Polymarket users". For people who had the site open in a short window that afternoon, it used their active session to sell positions and move funds out of their wallets.

Polymarket says it removed the script and cleared every cache, paused trading and its relayer, reset all active login sessions and referred the case to law enforcement. It is returning $3.9 million to traders: $2.7 million for the drained wallets and $1.2 million for losses during the trading pause, with no claim needed.

What to change if you load a RUM or analytics tag

The immediate step for DebugBear RUM customers is the one the vendor gave: remove the embed code until DebugBear says the service is safe to restore. Beyond that, the incident is a case for three changes that apply to any monitoring, analytics or chat tag:

• keep third-party scripts off pages where users sign in, pay or approve transactions, unless the page cannot work without them;
• pin versioned files with Subresource Integrity, so the browser rejects a file whose contents change, and treat a vendor that cannot offer a fixed file as a risk to weigh;
• check the vendor's own domain hygiene (registrar lock, DNSSEC, two-factor on the registrar account), because a hijacked name bypasses everything else.

Polymarket says it is putting its third-party scripts back with stronger CSP, explicit version pinning and sandboxing.

Our website monitoring category lists 13 products for teams reviewing how their own page monitoring is loaded.

Sources

• Polymarket status: update on the 29 October attack on polymarket.com (read 2026-11-01), 1 November 2026
• The Hacker News: Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script, 1 November 2026