Polymarket's $3.9M Refund After Script Hack: What Happened

Polymarket says it is refunding $3.9 million to users after a compromised third-party script was used to sell positions and drain funds from hundreds of accounts on its international site, polymarket.com, on October 29, 2026. The company's October 30 postmortem splits that figure into $2.7 million tied directly to the attack and $1.2 million in goodwill payments for losses caused by the trading pause that followed.

What happened on October 29

According to Polymarket's own incident report, published on its status page, a third-party vendor whose performance-monitoring script loaded on Polymarket.com was compromised, and the attacker replaced the script with one built to target Polymarket users. The company said that for some people who had the site open during a small window that afternoon, it used their active session to sell positions and move funds out of their wallet. The incident was marked resolved on Polymarket's status page at 6:06 PM UTC on October 29, with a fuller postmortem posted at 8:07 PM UTC the following day.

Researchers at SecurityWeek reported that Hudson Rock researchers linked the activity to malicious JavaScript served from a DebugBear address that Polymarket's site loaded, pointing to DebugBear, a UK-based website performance monitoring firm, as the compromised vendor. The same outlet reported that website performance monitoring firm DebugBear has disclosed that its DNS records were compromised, though Polymarket itself has not named the vendor publicly. Yahoo Finance, citing security researcher Scott Helme of Report URI, reported that Polymarket's contracts weren't the problem, and a page-speed monitoring script served from vendor DebugBear's CDN was swapped for a drainer that hijacked logged-in sessions for about an hour, dumping or moving positions and sweeping cash out through Polymarket's own relayer.

On-chain analytics firm Bitquery independently traced the withdrawals using Polygon blockchain data. CCN, summarizing the findings, reported that blockchain analytics firm Bitquery traced approximately $2.73 million in unauthorized withdrawals across 737 accounts, with the main withdrawal activity between 17:10 and 18:10 UTC, when attackers executed 985 operations through Polymarket's existing infrastructure. Bitquery's own report noted that when it last read the chain, about $2.17 million in POL still sat in three Polygon wallets, meaning not all the stolen funds had moved out of traceable addresses by the time of its analysis.

Reconciling Polymarket's numbers against Bitquery's on-chain tally

Polymarket's rounded, platform-reported figures and Bitquery's independent on-chain estimate are close but not identical, and the difference matters for anyone trying to pin down an exact loss number. SecurityWeek reported that in an October 30 update, Polymarket said 726 wallets were affected, versus Bitquery's count of 737 accounts. The dollar figures also diverge slightly: Polymarket rounds the direct theft to $2.7 million, while Bitquery's on-chain tracing puts it at $2.73 million. CCN noted that Bitquery did not assign a dollar value to those positions, so the reported withdrawal total may not capture the full economic damage, since on-chain transfer amounts don't necessarily reflect what positions were worth before they were force-sold.

A hijacked browser session is not a broken smart contract

The distinction between what happened here and a flaw in Polymarket's blockchain contracts is the central technical question for users. Bitquery's investigation traced every transfer using Polygon transaction data and found that the chain shows they were valid, but it cannot show who made them. CCN reported the same conclusion in plainer terms: the withdrawals passed the wallets' approval checks and went through Polymarket's own transaction service. In other words, the transactions that moved funds were legitimate, authorized actions as far as the blockchain was concerned, because they were initiated through a session the user had already approved, not because an attacker found a way to bypass contract logic.

Bitquery's report also noted that two days earlier, the Predict.fun hack looked much the same on-chain, with valid approvals and no broken contract, suggesting the same session/approval-based attack method, rather than a contract exploit, played out at a different prediction market within the same week. None of this means Polymarket's contracts have been proven free of vulnerabilities in general; it means that in this specific incident, the documented evidence points to a compromised front-end script abusing active sessions, not a demonstrated flaw in the contracts themselves.

What the 95% refund figure does and doesn't tell you

Polymarket's claim that 95% of affected wallets have been refunded is explicitly a snapshot, not a running total. The company's October 30 postmortem reported that 95% of affected wallets had been refunded in full as of that afternoon. KuCoin's news summary repeated the same figure with the same timestamp, reporting that as of October 30, 95% of affected wallets have been reimbursed. As of this review on November 2, 2026, no subsequent Polymarket update confirming a higher completion rate, a final reconciliation, or the outcome of the law enforcement referral mentioned in the company's initial statement has been found. SecurityWeek quoted Polymarket's initial statement that "We are in active investigation with law enforcement & will share a postmortem," which the company did the following day; no further public update on that investigation has surfaced since.

It's also worth noting what the incident did not touch, based on available reporting. SecurityWeek reported that Polymarket's US platform was reportedly unaffected, consistent with the incident being confined to the international site, polymarket.com, where the compromised script was loaded. This is also not the first such incident: SecurityWeek reported that in June, Polymarket disclosed another third-party compromise that injected a malicious script into its frontend, with losses reported at around $3 million, meaning this is a recurring category of risk for the platform rather than an isolated event.