Hijacked Monitoring Script Drains About $2.7M From Polymarket Traders

On October 29, a small piece of JavaScript that prediction market Polymarket loaded to measure page speed was quietly replaced with a malicious version. For roughly an hour, that script used traders' own signed-in sessions to hand their positions and funds to an attacker-controlled wallet. Polymarket says it is refunding about $2.7 million to 726 affected wallets.

What happened

The script belonged to DebugBear, a real user monitoring (RUM) service that measures how quickly pages load for real visitors. Each DebugBear customer embeds its own copy of the script — and the copy that was swapped was Polymarket's.

DebugBear says its DNS records were compromised through its domain registrar. Once the attackers controlled DNS, the address Polymarket's site used to fetch the script pointed to a different server, which served the malicious file instead of the legitimate one normally hosted in cloud storage. DebugBear's early findings indicate a single customer's website was targeted, and it has so far seen no sign of a break-in to its own systems; its investigation is ongoing.

How the money was taken

The malicious code did not try to steal passwords, seed phrases or private keys. Instead, it rode the access a trader already had in an open, signed-in Polymarket tab:

• it read account details stored in the browser, including trading API keys;
• it located the site's order-placement logic and the signer that approves the account's transactions;
• for accounts that sign in with a crypto wallet, it transferred positions straight to the attackers' wallet;
• for accounts that sign in with email, it sold positions at progressively worse prices and moved the proceeds out.

In both cases the code asked the account's own signer to sign the requests and passed them to Polymarket's relayer for submission. It is not established that every victim signed blindly — some wallet providers may still have shown a prompt or applied their own rules — but the outcome shows how much power code running inside a trusted page has.

On-chain records show the attacker wallet received funds between roughly 17:10 and 18:02 UTC, collecting about 28.6 million POL tokens (worth around $2.64 million at the time) plus trading positions. Between 18:28 and 18:38 UTC the POL was moved on to three other addresses.

Polymarket's response

Polymarket posted its first status update about unauthorized wallet activity at 17:38 UTC and switched its exchange to cancel-only mode at 18:05 UTC, pausing relayer actions. The company says it removed the script within the hour, purged caches, reset all active login sessions, kept trading paused until the site was clean, and referred the case to law enforcement.

By October 30, 689 of the 726 affected wallets had been fully refunded, with the remaining 37 being paid as they are verified. Polymarket is also compensating about 5,500 wallets — roughly $1.19 million — that lost money during the trading pause or had positions taken, bringing the total returned to traders to about $3.9 million. Traders do not need to file a claim. DebugBear has told its RUM customers to remove its embed code, and Polymarket says third-party scripts will only return behind stronger controls: a tighter Content Security Policy, pinned versions and sandboxing.

Why it matters

This is a textbook web supply-chain attack. Polymarket's own code was never breached — the weak point was a vendor's domain registrar, two steps removed. Any script a site loads from another domain runs with the full privileges of the page, and on a page where users trade or sign transactions, that means the ability to act as the user.

It also shows the limits of common defenses. A Content Security Policy that simply allows a trusted CDN does nothing if that CDN's DNS — or the file it serves — changes underneath you.

What to do

For site owners:

1. Inventory every third-party script your pages load, and remove anything not strictly needed from pages where users log in, trade, pay or sign.
2. Pin and verify. Where a file can be versioned, serve it with Subresource Integrity (SRI) hashes so the browser refuses it if its contents change — or self-host it.
3. Tighten CSP beyond domain allow-lists, and isolate analytics and monitoring tags in sandboxed iframes away from sensitive flows.
4. Limit what page code can make the signer do. Review which actions client-side code can trigger and require explicit, human-readable confirmation for value-moving operations.
5. Watch your vendors' infrastructure too. Unexpected DNS or hosting changes on domains you load code from are an early warning sign.

For traders and users: reject any signing request you did not expect, and check wallet and account activity after any incident notice from a platform you use.

Most organizations don't have an accurate list of the external domains and scripts their own web properties depend on. Our Attack Surface Management service continuously maps those dependencies — including third-party script sources and the DNS behind them — and flags unexpected changes, so a swapped script or hijacked vendor domain stands out before it reaches your users.