Polymarket DebugBear Hack: How a Hijacked Monitoring Script Drained Traders, and How to Check the Scripts on Your Site

On Thursday, October 29, 2026, someone swapped a website performance monitoring script that Polymarket loaded on its site for one that sold traders' positions and moved their funds. If your website loads any outside script on login, account or checkout pages, the same thing could happen to your customers, and no one would have to break into your servers.

Polymarket says it has paid back about $3.9 million. The lesson for businesses is not about crypto. It is about how much power one third-party script has on any page your customers sign in to.

What happened in the Polymarket DebugBear attack

Polymarket's own status page lays out the timeline (all times UTC, October 29, 2026):

• 5:38 PM: Polymarket spotted unauthorized activity affecting user wallets.
• 6:05 PM: The exchange went into "cancel-only mode" and paused relayer actions.
• 6:06 PM: The security incident was marked resolved. Polymarket said a third-party vendor's script on the site had been compromised and, for some users, had used their active sessions to sell positions and move funds.
• 7:05 PM: The cancel-only incident was closed and trading reopened.

Polymarket's postmortem, posted October 30, says "the attacker replaced the script with one built to target Polymarket users." It says the script was removed and sessions were reset. The postmortem does not name the vendor. It says only that the vendor "has confirmed the compromise publicly."

Hudson Rock, a threat intelligence company that obtained the malicious file, ties it to DebugBear, a real user monitoring (RUM) service. The file was served from DebugBear's own content delivery network. Hudson Rock also found a Polymarket build with the commit message "remove debugbear rum script," timestamped 17:59:20 UTC that day. According to SecurityWeek, DebugBear said on X that it was dealing with an "ongoing security incident" and told RUM customers to remove its snippet.

What is confirmed and what is not

Confirmed by Polymarket:

• A third-party performance monitoring script was replaced with malicious code.
• It used logged-in sessions to sell positions and move funds.
• Refunds total about $3.9 million: $2.7 million for funds lost in the attack and $1.2 million for losses during the trading pause.
• When the postmortem was posted, 95% of affected wallets had been refunded in full.

Confirmed by Hudson Rock's analysis of the file:

• The script contained code to find accounts, choose which ones to drain, ask for signatures and transfer assets.
• Hudson Rock found no code sending passwords, seed phrases or private keys out. The script used the authority the logged-in session already had.

Not known yet:

• How the attacker got control of DebugBear's script. Some headlines say DebugBear blamed a DNS hijack. We could not confirm that from a DebugBear statement.
• When the malicious version was first served, and how many users were affected.
• Whether other DebugBear customers received a malicious version.

This is separate from an earlier Polymarket incident on June 25, 2026, which also involved a third-party vendor. Some coverage mixes up the two.

How the hacked monitoring script worked

Hudson Rock's review describes the steps in plain terms:

1. Read what the browser already had. The script read entries in the browser's local storage: login context, the deposit wallet address and trading API credentials.
2. Found the live trading tools. It searched the running web app for Polymarket's trading client and signer.
3. Picked targets. It checked balances and positions against thresholds and skipped visitors flagged by Polymarket's location check.
4. Moved the money. Depending on account type, it either transferred position tokens straight to a recipient address, or placed sell orders at steadily worse prices and then tried to move the proceeds.
5. Reported back. It sent wallet addresses, IP, country, portfolio values and results to a DebugBear domain, data.debugbear.com.

Notice what the attacker never needed: Polymarket's servers, its database or anyone's password. Polymarket's site told every visitor's browser to load the script, and the browser ran it with the same rights as Polymarket's own code.

Why third-party script attacks matter for a business website

Most business websites load outside JavaScript: analytics, chat widgets, tag managers, heatmaps, ad pixels, payment helpers and performance monitors like DebugBear. Each one runs inside your page. On a login, account, patient portal or checkout page, that means it can read what the customer types, see what is on screen and act as the signed-in user.

Three things from this case apply well beyond crypto:

• MFA does not help once the session exists. The script worked inside sessions that were already authenticated.
• Allowing a "trusted" domain is not the same as checking the file. The malicious code came from DebugBear's real CDN and reported to DebugBear's real domain. An allow-list containing debugbear.com would have let it through.
• Your customers carry the loss first. Polymarket chose to refund, but the reputational damage lands on the site owner, not the vendor.

We covered the plugin version of this problem in Why WordPress Is the Most Targeted Website Platform on the Internet. Vendor risk in general came up in Northflank Breach: Customer AI API Keys Misused.

What to do this week

Polymarket hack questions people are asking

Was Polymarket itself hacked?

Not its servers, according to what has been published. Polymarket says a third-party vendor's script on its site was compromised and replaced with malicious code.

How much was stolen in the Polymarket DebugBear attack?

Polymarket puts the attack losses at $2.7 million and its total refunds at about $3.9 million, including $1.2 million for losses during the trading pause. Early on-chain estimates from researchers ranged from about $2.2 million to $2.7 million.

Did the script steal passwords or seed phrases?

Hudson Rock found no code in the sample it reviewed that sent passwords, seed phrases or private keys out. It acted through the user's existing session instead.

Would two-factor authentication have stopped it?

No. The script ran inside sessions where the user was already signed in.

What is a website supply chain attack?

It is when attackers compromise something your site depends on, such as a script, plugin or library, instead of attacking your site directly. Every site that loads the compromised piece gets the malicious code.

Does Subresource Integrity stop this?

It does for files that do not change, because the browser checks the file against a hash you set. Many vendor scripts update constantly and cannot be pinned, which is why limiting where they load matters.

The bigger lesson

Every script you add to a page is a vendor you are trusting with your customers' sessions. Keep a list of those scripts, keep them off the pages that matter most, and know how to remove one in minutes.

Need a review of the scripts and security settings on your site? See security hardening or request a quote.

Get security alerts like this by email, plus our free checklist, at /security-alerts.

Sources: Polymarket status page incident history; Hudson Rock (InfoStealers): wallet-draining code found in a third-party script; SecurityWeek: $2 million drained from Polymarket traders.