A Page-Speed Script Turned Thief: Questions and Answers on the Polymarket DebugBear Hijack

Most business websites load small pieces of code from other companies: analytics, chat widgets, ad tags, performance monitors. On October 29, one of those pieces became the weapon in a theft from traders on the prediction market Polymarket. The episode is a clear lesson in how much trust a single line of embedded code carries.

Answers below draw on The Hacker News’ reconstruction of the attack and SecurityWeek’s follow-up on the refunds and DebugBear’s findings.

What actually went wrong?

Polymarket’s site loaded a real user monitoring script from DebugBear, a company that measures how quickly pages load for visitors. DebugBear says its DNS records were compromised through its domain registrar. With those records changed, a different server answered for DebugBear’s web address and delivered a malicious file in place of the normal script, which had been served from Google Cloud Storage earlier that day. Each DebugBear customer loads its own copy of the script, and the copy that was swapped was Polymarket’s. DebugBear’s early read is that the attackers targeted one customer’s site and that its internal systems were not breached, though its investigation continues.

Did the attackers steal passwords or wallet keys?

According to Hudson Rock, which analyzed the file, no. The code did not send passwords, seed phrases or private keys anywhere. Instead, it used the access a signed-in trader already had in the open page. It located the site’s order functions and the account’s signer, then either transferred positions straight to the attackers’ wallet (for wallet-based logins) or sold positions at progressively worse prices and moved the proceeds out (for email-based logins).

How much was taken, and who is paying?

Polymarket says 726 wallets were affected and it is refunding about $2.7 million to them; by October 30 all but 37 had been made whole. It is also paying $1.19 million to roughly 5,500 wallets hurt by the trading pause or by the script’s forced sales, for about $3.9 million in total. Traders do not need to file claims.

How did Polymarket respond?

It put the exchange into cancel-only mode, removed the script within the hour, cleared caches, reset all active sessions and referred the case to law enforcement. It says third-party scripts are returning with tighter controls, including a stronger Content Security Policy, pinned versions and sandboxing. SecurityWeek notes Polymarket reported a similar vendor-script incident in June, with losses of around $3 million.

Could this happen on an ordinary business website?

Yes. The money angle here was crypto, but the mechanism works anywhere a page has something worth abusing: a logged-in customer portal, a checkout form, an admin dashboard. Hudson Rock’s advice for site owners is to keep unnecessary third-party code off sensitive pages, to use Subresource Integrity (SRI) where a file can be pinned so the browser rejects it if the contents change, and to remember that a policy allowing a trusted CDN does not inspect what that CDN actually serves.

What this means for your company

Make a list of every external script your website loads and ask whether each one needs to be on pages where customers log in, pay or enter personal data. Remove what you can, pin and verify what remains, and set a Content Security Policy that limits where code can come from. Just as important, protect your own domain registrar account with strong, unique credentials, multifactor sign-in and registrar lock, because this attack began with someone else’s DNS being changed. Your domain is the address everything else trusts.

Would you like a second set of eyes on the third-party code your website runs, or on how your domain and DNS are protected? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.