VULNpocalypse
HighSupply chainMonitoring

Polymarket traders drained via hijacked DebugBear monitoring script, DNS compromise cited

A DebugBear monitoring script on Polymarket.com was swapped for wallet-draining code on October 29, costing traders about 2.7 million dollars.

Published
Updated
Fixed in
No software patch. Polymarket removed the script and DebugBear told RUM customers to remove its embed code.
Exploitation
Yes, about 2.7 million dollars stolen from 726 wallets per Polymarket figures, with the refund pledge confirmed by several outlets

What happened

On October 29, Polymarket halted trading on its international platform after users reported unauthorized withdrawals. The exchange went into cancel-only mode with relayer actions suspended, and Polymarket said one of its third-party providers was compromised SecurityWeek. Researchers linked the theft to malicious code served from DebugBear, a UK-based website performance monitoring firm. Polymarket’s US platform was reportedly unaffected SecurityWeek.

Polymarket’s post-mortem said the attacker replaced the performance-monitoring script loaded on polymarket.com with code built to steal from users. For people who had the site open during a small window, it used their active session to sell positions and move funds out of their wallet The Record.

How the script worked. Hudson Rock reviewed the file without running it. The code reuses the access a signed-in trader already has in an open Polymarket page. It reads account details kept in the browser, including trading API keys, and looks for the part of the site that places orders and for the signer that approves transactions The Hacker News.

  • For accounts that sign in with their own crypto wallet, it moves positions straight to the attacker’s wallet.
  • For accounts that sign in via email, it sells positions at ever-worse prices and then moves the money out The Hacker News.

Hudson Rock found no routine that sends the credential map, a password, a seed phrase or a private key to the reporting endpoint SecurityWeek. Hudson Rock also said a signing request alone does not prove a trader signed without seeing a prompt, because the wallet provider may still ask the trader, refuse, or apply its own rules The Hacker News.

Root cause as stated by the vendor. DebugBear said its DNS records were compromised through its domain registrar. Early findings indicate the attack targeted one customer’s website, and it has seen no sign of a break-in to its own systems SecurityWeek. Ohey found a different server answering for DebugBear’s web addresses at 18:13 UTC while the malicious file was online. Earlier that day the normal script had been served from Google Cloud Storage The Hacker News. How the attackers gained registrar-level access is not confirmed, and the investigation is ongoing SecurityWeek. The identity of the attacker is not confirmed.

Losses and timeline. Figures differ by source:

  • Polymarket said 726 wallets were affected and about $2.7 million was stolen SecurityWeek.
  • Betting Intelligence and Polysights estimated about $2.7 million from 710 wallets Hackread.
  • GoPlus put losses at roughly $2.71 million SecurityWeek.
  • A DefiPrime calculation valued the 28.6 million POL tokens collected by the hard-coded wallet at about $2.64 million. That figure excludes the positions The Hacker News.

Polymarket posted its first status update at 17:38 UTC and said at 18:05 UTC that the exchange was in cancel-only mode The Hacker News. Trading resumed about an hour later SecurityWeek. Hudson Rock also spotted a Polymarket production build timestamped 17:59 UTC with a change note about removing the DebugBear script SecurityWeek.

Response. Polymarket said it removed the script within the hour, cleared caches, reset all active login sessions, and referred the case to law enforcement The Hacker News. It is returning $3.9 million in total, made up of $2.7 million for stolen funds and $1.2 million for pause-related losses. No claims are needed, and as of Saturday 95% of affected wallets had been refunded in full The Record. Polymarket redeployed the vendor script with additional integrity controls and continuous monitoring and verification The Record.

Context. Polymarket disclosed another third-party compromise in June, when a malicious script was injected into its frontend, with losses reported at around $3 million SecurityWeek.

Am I affected?

  • Polymarket.com (international) traders who had the site open during the attack window on October 29 may have been affected. Polymarket said it identified eligible wallets from on-chain and trading data The Record. The US platform was reportedly unaffected SecurityWeek.
  • Sites that load DebugBear’s RUM script were told by DebugBear to remove the embed code SecurityWeek. DebugBear’s early finding is that one customer’s site was targeted. Hudson Rock’s findings do not indicate that other DebugBear customers were targeted, but this is preliminary SecurityWeek.
  • Everyone else who loads third-party scripts from vendor-controlled domains faces the same class of risk. A Content Security Policy that allows a trusted vendor domain would have permitted this traffic, according to Jscrambler’s Gareth Bowker Hackread.

The scope of affected users beyond the reported wallet counts is not confirmed. The number of users hit was also not determined by Hudson Rock SecurityWeek.

What to do now

  1. Remove the DebugBear RUM snippet from your pages if you use it, as DebugBear instructed. At the time The Hacker News checked on November 1, cdn.debugbear[.]com had no DNS record The Hacker News. Search your code and tag managers for references to that host.
  2. Keep unneeded third-party code off pages where users trade or sign. Check what code on a signed-in page can ask the signer to do The Hacker News.
  3. Pin third-party files with Subresource Integrity (SRI) where possible. A policy that simply allows a trusted CDN does not check the files that CDN serves The Hacker News. SRI has limited use for RUM scripts because vendors update them often, so also monitor what third-party code does in the browser at runtime Hackread.
  4. Review your own DNS and registrar exposure. DebugBear attributed the hijack to a registrar-level DNS compromise, though how access was gained is not confirmed SecurityWeek. Checking who can change your DNS records and how that access is protected is our recommendation, not a step stated in the sources.
  5. If you are a Polymarket trader, reject any signing request you did not expect The Hacker News. Review your transaction history and revoke token approvals you do not recognize Hackread. If you think a refund amount is wrong, Polymarket’s status page links a form for that The Hacker News.
  6. Watch for the postmortem. Polymarket said it will share one, and DebugBear’s investigation is still open SecurityWeek.

Sources