Polymarket: Compromised Monitoring Script Drains User Accounts
A hijacked DebugBear performance script served malicious code on Polymarket that abused logged-in sessions. Losses: roughly $2.2M to $2.7M. Polymarket says it will reimburse all affected traders.
Translated from the German original with an AI language model, approved by me. Read the original
Another supply chain attack, this time through a third-party script. In a supply chain attack, attackers don't go after the target directly. They compromise a supplier the target trusts and get in that way. For Polymarket, the prediction market platform, that cost money on October 29, 2026, and the money belonged to its users.
What happened
On Thursday afternoon (US Eastern time), users reported withdrawals they hadn't made. Polymarket first put its international exchange into "cancel-only" mode, meaning traders could cancel open orders but not place new trades. It also paused relayer actions. The relayer is the service that submits transactions to the blockchain on users' behalf. Trading resumed after about an hour. According to BleepingComputer, the incident was marked resolved at 3:05 p.m. ET. SecurityWeek reports that Polymarket's US platform appears to have been unaffected.
Polymarket still hasn't named the vendor. It has only said that one of its third-party providers was compromised and that it referred the case to law enforcement. Security researchers at Hudson Rock and GoPlus traced the code to DebugBear, a UK-based website performance monitoring company. The malicious code came through its RUM script. RUM stands for Real User Monitoring: a small piece of JavaScript that runs in real visitors' browsers and measures how fast a page loads. DebugBear has confirmed "an ongoing security incident," brought in outside incident responders, and told customers to remove the RUM snippet from their sites. Hudson Rock also found a Polymarket production build timestamped 17:59 UTC whose change note mentions removing the DebugBear script.
How the malicious code worked
What the script did not do stands out. Hudson Rock found no code that harvested passwords, seed phrases, or private keys. Instead, the script checked whether a visitor was logged in to Polymarket and then worked through that existing session. Depending on the account type, it either sold the user's positions and moved the proceeds, or sent the position tokens straight to an attacker-controlled address. It took its instructions from DebugBear infrastructure and reported account data back there. For logged-in users, the platform saw what looked like their own activity.
How big the damage is
Estimates vary by source, and Polymarket hasn't published its own figures:
- Hudson Rock saw about $2.19 million in the attacker wallet but explicitly calls that figure unverified.
- BleepingComputer traced about 28.6 million POL (roughly $2.57 million) from that wallet to three other wallets.
- GoPlus estimates about $2.71 million across 710 deposit wallets and 731 addresses, and points out that the number of addresses isn't the number of victims.
What has changed since my post: The post only mentioned "a website monitoring tool." Since then, researchers have named the vendor, trading is back up, and Polymarket has promised to fully reimburse every affected trader. How that reimbursement will work is still unclear. It's also unclear how the attackers tampered with the DebugBear script and whether other DebugBear customers were targeted. So far, Hudson Rock has seen no sign of that. This isn't Polymarket's first incident of this kind either: in June, the platform disclosed a separate third-party compromise involving an injected frontend script, with reported losses of around $3 million.
Why it matters
Every third-party script you embed runs with the same privileges as your own code. A performance tracker can reach the same session, the same buttons, and the same API calls as the actual application. On a site where users move money with a single click, that's a master key. Because this script abused the live session and didn't steal credentials, strong passwords and two-factor authentication would not have helped.
What you should do
If you use Polymarket:
- Check your account history for sales and transfers on October 29 that you didn't make, and report them to Polymarket for the promised reimbursement.
- Review your wallet approvals and revoke any you don't need. According to the analyses, this attack went through the session and not through approvals, but cleaning them up never hurts.
- Log out when you're done trading instead of leaving sessions open.
If you run a website:
- If you use DebugBear RUM, remove the snippet, as the vendor itself recommends.
- Take stock of which third-party scripts run on your site and remove anything you don't really need. Monitoring and analytics don't belong on pages where money moves, or only in a tightly restricted form.
- Set a Content Security Policy (CSP), an HTTP header that defines where scripts may load from and where they may send data. It limits the damage, but it won't stop an attack if an allowed source is itself compromised.
- Where possible, self-host third-party scripts and include them with Subresource Integrity (SRI). The browser then checks a hash and refuses to run code that has been changed.
Your site is only as safe as the scripts it loads.