On October 29 a DebugBear page-speed script on Polymarket was swapped for code that sold traders' positions and moved the funds out. Polymarket is refunding $2.7 million to drained wallets and $3.9 million in total. DebugBear says its DNS was hijacked through its domain registrar. Here is what a team running any signed-in web app should check.
If your product has a signed-in web page, list every script on it that loads from a domain you don’t control, and remove the ones that page doesn’t need. On October 29, a page-speed monitoring script on Polymarket was replaced with code that used traders’ own open sessions to sell their positions and move the money out. Nothing in Polymarket’s own systems had to be broken for that to work.
What happened
Polymarket’s status page says that at 17:38 UTC on October 29 it found “unauthorized activity affecting user wallets.” A vendor’s monitoring script on the site had been replaced with malicious code. At 18:05 UTC the exchange went into cancel-only mode and paused relayer actions. Polymarket says it removed the script, cleared caches, reset login sessions and referred the case to law enforcement.
The vendor was DebugBear, which sells real-user monitoring that measures how fast pages load for actual visitors. According to The Hacker News, DebugBear said its DNS records were compromised through its domain registrar, that early findings suggest the attack targeted one customer’s website, and that it has seen no sign of a break-in to its own systems. It told its monitoring customers to remove its embed code while it investigates. In other words, the address Polymarket’s pages called for the script started answering from a server the attacker controlled.
The malicious script read what a signed-in trader’s browser already held, including trading API keys, according to an analysis by Hudson Rock. For wallet-login accounts it moved positions to the attacker’s wallet. For email-login accounts it sold positions at progressively worse prices and then moved the funds. Researcher Ohey traced positions from 33 wallets and 28.6 million POL to the attacker between 17:10 and 18:02 UTC.
What it cost
Polymarket’s postmortem says it refunded $2.7 million for drained wallets and positions taken during the attack, plus $1.2 million for losses during the trading pause, for $3.9 million in total. According to The Hacker News, 726 wallets were drained and 689 had been refunded in full by October 30. Traders don’t need to file a claim; Polymarket links a form for disputed amounts.
What a team with a signed-in web app should check
1. Inventory third-party scripts on signed-in pages. Analytics, monitoring, chat widgets, A/B testing and tag managers all run with the same access as your own code. If one isn’t needed on the page where users trade, pay or change settings, take it off that page.
2. Pin what you can. Subresource Integrity (an integrity hash on the script tag) makes the browser refuse a file that changed. It only works for files with fixed contents, so ask vendors for versioned files or self-host the script.
3. Don’t treat a domain allowlist as protection. A Content Security Policy that trusts a vendor’s domain still runs whatever that domain serves. It did nothing here once the vendor’s DNS pointed somewhere else.
4. Limit what page code can do with a session. Check whether scripts on a signed-in page can trigger signing, payments or API calls without a fresh confirmation from the user.
5. Lock down your own registrar. The weak point was a domain registrar account. Turn on registrar lock, two-step login and alerts for DNS changes on every domain that serves code to customers.
A vendor’s registrar account became a path into your users’ sessions
The attack didn’t need Polymarket’s servers, keys or staff. It needed one vendor’s DNS. That is the same lesson as last month’s hijacked Shopify apps and the Northflank breach: the code your users run includes every vendor you load, and each vendor’s weakest account is now part of your attack surface. A speed-monitoring script is easy to add and easy to forget. It is also code running inside your customers’ signed-in sessions.
Reported by The Hacker News, with Polymarket’s status page as the primary source.