Live monitoring Updated 72-hour alert levelPriority Editor: Frédéric LENQUETTE
CYBERIACKCybersecurity & AI intelligence · by Frédéric LENQUETTE
CybersecurityImportant

A speed-testing tool turned thief: over 700 wallets drained on betting site Polymarket

On October 29, code from vendor DebugBear was replaced with a program that sold the positions of logged-in bettors. Here is how it happened, and how to audit the third-party scripts on your own site.

Translated from French by AI. The original French article is the reference version.

Article illustration : A speed-testing tool turned thief: over 700 wallets drained on betting site Polymarket
AI-generated illustration

On October 29, in the late afternoon Paris time, Polymarket users watched their balances melt away without touching anything. Their positions were sold, and their funds were sent to an unknown address. The cryptocurrency betting site was not hacked directly: a small third-party script, loaded on every page to measure display speed, turned against its own visitors.

Polymarket published its analysis on October 30. According to the company, a vendor's performance-monitoring script was replaced with a malicious version. For users who had the site open during a short window, this code used their active session to sell their positions and transfer their funds. According to analytics firms Betting Intelligence and Polysights, cited by Hackread, about $2.7 million was taken from 710 wallets.

A measurement tool turned into a thief

Polymarket does not name its vendor. The firm Hudson Rock identified it as DebugBear, a UK company that measures website performance. DebugBear confirmed on X that it was affected by an "ongoing security incident" and asked customers of its real-user monitoring service to "remove the integration code" from their sites.

A researcher who signs as Kirk, on the Ohey site, retraced the timeline. According to them, the script's server began returning errors at 4:54 p.m. (UTC), then served a program of about 15 KB. This code used Polymarket's own trading client already present in the page, and, apart from DebugBear's addresses, every address it contacted was listed in the site's content security policy. Victims' data was sent to a server on DebugBear's domain. Around 5:59 p.m. (UTC), Polymarket prepared a new version of its site that removed the script.

How Polymarket is paying back victims

The platform shut down trading and flushed its caches, then logged out all sessions. It announced $3.9 million in reimbursements: $2.7 million for losses caused by the attack and $1.2 million for losses caused by the trading pause. Victims, identified through blockchain data, do not need to do anything. On October 30, about 95% of the affected wallets had been reimbursed, according to Polymarket. The case has been referred to law enforcement.

Hudson Rock says it cannot establish the total number of victims or identify the attacker. DebugBear says only that its DNS records were compromised through its domain name registrar.

Are your third-party scripts under control?

This scenario is not specific to cryptocurrencies. Any script loaded from a vendor's server runs with the same privileges as your own code, as the booby-trapped Rank Math PRO update showed in a different context. A few measures:

  • Take inventory of the external scripts loaded by your pages, especially those where users are logged in or paying.
  • If you use DebugBear, follow its instructions: remove the integration code until further notice.
  • Do not rely on a content security policy (CSP) alone: here, the malicious code came from an allowed domain. Gareth Bowker of Jscrambler, cited by Hackread, points this out.
  • Pin versions when possible, with subresource integrity (SRI) checks, or host a verified copy. This is hard for monitoring scripts that vendors update often.
  • Isolate non-essential scripts from sensitive pages and monitor any change to their content.

Polymarket says it is redeploying its third-party scripts with these safeguards. It is the second vendor compromise it has suffered this year, after one in June, according to Hackread. It remains unclear how the attacker took control of DebugBear's DNS, and whether other sites loaded the same code.

Method: AI-assisted monitoring, facts verified by a second AI model, article published automatically then reviewed and approved by Frédéric LENQUETTE on November 12, 2026. Our editorial policy.

Share this article