Polymarket Hack Drains $2.5M via Compromised Vendor Script

Polymarket halted trading on October 29 after attackers compromised a third-party provider and pushed crypto-draining JavaScript to its international platform. The hack reached Polymarket traders through their own logged-in browser sessions. Blockchain trackers have traced roughly $2.5 million in stolen assets to one attacker wallet, moved across more than 900 transactions. Trading returned about half an hour later, and the company promised to reimburse every affected trader.

How the Polymarket hack unfolded

The platform switched to cancel-only mode and paused its relayer at roughly 2:33 p.m. ET on Thursday. Traders had started reporting funds leaving their accounts without permission. Polymarket confirmed within the hour that the hack came through a compromised provider, and it marked the incident resolved at 3:05 p.m.

The attack reached only Polymarket’s international site, Polymarket.com, and left the company’s US exchange untouched. That venue operates separately under Commodity Futures Trading Commission oversight. Polymarket also referred the case to UK authorities, because the provider behind the hack is headquartered in Britain.

Polymarket has not named that provider in any statement about the hack. Security researchers closed the gap themselves. They retrieved the malicious file and traced it to infrastructure belonging to DebugBear, a UK performance monitoring firm. DebugBear’s own site went dark behind a Cloudflare error during the incident.

A monitoring tag turned into a wallet drainer

Researchers at Hudson Rock identified the payload as a JavaScript file served from cdn.debugbear[.]com. That domain normally delivers real user monitoring code, the kind that measures page load speed and visitor experience. Site operators give such scripts a slot on every page and rarely look again. The replaced file called out to a DebugBear data domain for instructions, then reported back account details, wallet addresses, balances and transaction results.

The code checked first for an active Polymarket session. It then read browser storage for account data, a wallet address and trading API credentials. From there it hunted for the live trading client and the signer the platform uses to request cryptographic authorization. Behavior split by account type, with one branch requesting position token transfers and the other selling holdings outright.

An attacker wallet sat hard-coded in the script as a fallback recipient, alongside conversion and swap routes for the stolen funds. The script pushed transactions through the signed-batch mechanism, so the hack traveled on Polymarket’s own legitimate rails. That analysis was static, so researchers stopped short of proving every programmed transfer executed.

Why the session mattered more than the private key

Nothing here required a seed phrase, a stolen private key or a convincing fake website. The code used what an authenticated trader already had open, so hardware wallets and strong passwords offered no defense. A browser session with trading rights works as a live set of keys, and the hack turned that property of Polymarket’s interface into roughly $2.5 million.

Tracing the stolen funds

Loss estimates vary by tracker and by the moment of each snapshot. The suspect wallet held about $2.19 million when researchers examined it, while analysis of its activity put roughly $2.5 million in transfers from user accounts. Other trackers reported about $2.65 million in POL, Polygon’s native token. One estimate reached $2.7 million across more than 700 accounts.

Polymarket has not published a loss figure of its own, so the full cost of the hack stays unsettled. Production build metadata carries a commit message removing the DebugBear monitoring script, stamped at 17:59:20 UTC. That timestamp marks a clear end to the exposure window but says nothing about when it opened.

A second script compromise in four months

June 25 brought an attack of almost identical shape. A compromised vendor put a malicious script in front of some Polymarket users, and that hack drained close to $3 million. Fewer than 15 accounts took the loss. The company reimbursed every one of them, exactly as it has promised to do again.

A separate failure in May cost about $700,000 when a private key compromise drained an internal top-up wallet. Three incidents in six months leave Polymarket facing one blunt question. What changed in vendor governance after June, and why did the same class of attack land again? The repeat carries more weight than either loss on its own, because it points at process rather than misfortune.

Why third-party scripts carry this much risk

Every external script a site loads runs with the same privileges as the site’s own code. Tag managers, analytics snippets, chat widgets and performance monitors can read the page and call application functions. The browser trusts all of it as first-party code, and the hack against Polymarket ran on exactly that trust.

Attackers have worked out how much leverage this hands them. Compromising one monitoring provider reaches every site loading its tag. Better still for them, the payload arrives from a domain the operator allowlisted personally. Businesses running payment flows, account pages or trading interfaces carry the sharpest version of this exposure, because the session holding the money also holds the script.

What operators and traders should do now

Defending against the kind of hack that hit Polymarket takes inventory work rather than new products. Operators need to know what runs inside their users’ browsers. Traders need to assume a compromised page can act as them.

For site operators

Keep an inventory of every third-party script in production and the pages each one touches. Apply Subresource Integrity hashes so the browser rejects files that change without warning. Content Security Policy rules then control which domains may serve executable code at all. Strip non-essential tags from checkout, account and transaction pages, because a speed measurement rarely justifies code execution next to someone’s money.

For traders and account holders

Review active sessions and revoke API credentials after any incident of this kind. Reject signature requests that appear without a clear action behind them, and treat unsolicited recovery links as hostile. No legitimate support process asks for a seed phrase, so anyone requesting one runs the second stage of the attack.

What the incident leaves unresolved

How attackers reached DebugBear’s delivery infrastructure remains unexplained, and so does the length of time the malicious file stayed live. Researchers found no sign that other DebugBear customers received the payload, though nobody has confirmed containment either. Without a serving window, the count of Polymarket users the hack reached stays an estimate built from wallet activity.

UK law enforcement now holds the case, and the reimbursement promise settles the immediate damage without settling the cause. Trust granted to a performance monitor became trading authority over user accounts in the space of an afternoon. Polymarket paid for that lesson twice this year, and the hack will not be the last of its kind.