Polymarket’s $2.7M supply-chain drain

Polymarket’s international exchange lost about $2.7 million on Thursday, not because someone broke its smart contracts, but because a third-party script running on its website was compromised. The malicious JavaScript used logged-in users’ existing sessions to create withdrawals and move funds. In about an hour, 737 accounts were emptied.

The incident is smaller than the Binance hot-wallet drain that followed later on Thursday, but it is arguably more instructive for anyone building or using a decentralized application. The contracts worked as designed. The approvals were valid. The relayer did its job. The compromise happened in the layer most users never think about: the browser code a site loads from a vendor.

Polymarket says the affected users will be made whole and that its U.S. platform was not compromised. Trading on the international exchange was halted and later resumed. The exact loss figure still varies by source, but on-chain tracing puts the main route at about $2.73 million across 737 accounts.

What happened

On Thursday, October 29, between 17:10 and 18:10 UTC, Polymarket accounts began losing balances. Traders reported unauthorized withdrawals on social media and in Discord. One trader said $800,000 was gone; Bitquery found no single account that lost that much, and its largest single loss was $358,369. Others reported smaller losses. By the time a warning circulated on X at 17:45 UTC, about 48% of the eventual loss had already left, according to Bitquery’s on-chain analysis.

The pattern was unusual. Each drain was a normal Polymarket withdrawal with a valid approval, sent through Polymarket’s own relayer, which pays network fees for users. No smart contract was exploited. The attacker did not need to break the deposit wallet’s checks; the wallet accepted approvals that were signed by the account’s own login and used them to send funds to an attacker-controlled address.

Bitquery counted 985 drain transactions across 737 accounts. In its breakdown, 276 accounts lost under $100 each. The median loss was $171, and four accounts accounted for 43% of the money. The attacker also took prediction-market positions, not just cash: outcome shares from 33 accounts were transferred to a new Polymarket account, sold, or converted back into pUSD.

Polymarket initially put the exchange into cancel-only mode and paused its relayer. The relayer went quiet 30 seconds after the last drain, at 18:10 UTC. Polymarket said it had found and fixed the cause at 18:33. The relayer restarted at 18:52, and one more account was drained at 19:11 for about $11. That late drain is a useful warning: “fixed” in a live incident does not always mean every path is closed.

Why this was a supply-chain attack

Polymarket’s first status update announced cancel-only mode and a paused relayer. In a later statement, the company said one of its third-party providers had been compromised and that the matter had been referred to law enforcement. CNBC, citing a person familiar with the matter, identified the provider as DebugBear, a website performance-monitoring company. DebugBear’s Real User Monitoring product uses JavaScript embedded in customer websites to collect performance data from visitors’ browsers.

BleepingComputer and Hudson Rock traced the malicious code to a file hosted on DebugBear’s content delivery infrastructure. The script checked whether the visitor was logged into Polymarket, then used the existing trading session and Polymarket’s own transaction functionality to sell positions, transfer prediction-market tokens, or convert balances into assets that could be sent to the attacker. It also communicated with DebugBear infrastructure for instructions and exfiltration, according to the analysis.

DebugBear confirmed it was dealing with a security incident and told customers using its RUM product to remove the embed code from their websites. Polymarket’s production build metadata contained a commit message about removing the DebugBear RUM script, timestamped shortly before the public announcement. The sequence is consistent with a vendor compromise that turned a legitimate monitoring script into a wallet drainer.

This is why the incident is a supply-chain attack rather than a DeFi exploit. Polymarket’s contracts, wallets, and relayer behaved as programmed. The malicious code ran in the user’s browser with the user’s session, and it used the same approval path a normal withdrawal uses. From the chain’s point of view, the transactions looked valid because the approvals were valid. The chain cannot tell whether the person behind the approval was the user or code running in the user’s browser.

The distinction is not academic. A decentralized application’s frontend is part of its security perimeter. If a site loads analytics, support chat, A/B testing, or performance monitoring from a third party, that vendor can potentially influence what the user’s browser does with a logged-in session. A smart contract audit does not cover that risk.

The one-hour drain

The concentration of the attack in a single hour is itself a clue. The approvals were fresh: in the 30 drains Bitquery checked, each approval was used three to seven seconds after it was made. That is not a human clicking through hundreds of accounts. It is software operating at machine speed.

Polymarket’s response and refunds

Polymarket halted trading on its international exchange, paused the relayer, and said affected users would be made whole. Trading resumed around 3 p.m. ET on Thursday. The company’s U.S. platform was not compromised, according to CNBC.

CNBC reported that users who lost less than $10,000 would have funds restored by October 30, while users who lost more would need to sign a release form. The company has not published a full list of affected accounts or a detailed reconciliation. It referred the matter to U.K. law enforcement, according to the person familiar with the incident, because DebugBear is based in the U.K.

This is the second time in 2026 that Polymarket has blamed a third-party provider for a drain. In June, a similar vendor compromise was linked to about $2.94 million in losses across a much smaller number of wallets. The repeat is the part that should worry the industry: the first incident did not remove the structural risk, because the structural risk is the vendor script itself.

What users should do

If you have a Polymarket account, check the official status page and Polymarket’s own channels before acting. Do not trust direct messages, replies, or emails offering a refund; a real refund process does not start with someone asking you to connect a wallet or approve a transaction. If you see a withdrawal request you did not initiate, do not approve it.

The harder lesson is about wallet hygiene. A dedicated trading wallet with limited funds is safer than a wallet that also holds long-term savings. Hardware confirmation for withdrawals helps, but it is not a complete defense if the frontend can construct a valid request that looks routine. Users should treat any site that loads third-party scripts as part of the trust boundary, and should avoid granting broad token approvals that remain useful to an attacker long after the site is closed.

Polymarket says it will make users whole, and the on-chain evidence supports the idea that the losses are traceable. But recovery is not instant, and the incident is a reminder that “my funds are in a smart contract” does not mean “my funds are beyond the reach of a compromised website.”

What is still uncertain

The exact loss figure is still moving. Bitquery’s on-chain count is $2.73 million across 737 accounts. CNBC cited an analysis of at least $2.7 million across 710 other wallets. The Block reported about $2.65 million, and The Wall Street Journal reported at least $2.6 million. The differences reflect different cut-off times, routes, and whether prediction-market positions are valued at market price or at their maximum payout.

It is also not proven exactly how the approvals were generated. Polymarket blames a compromised outside provider; CNBC’s source names DebugBear; DebugBear has confirmed an incident. On-chain data shows valid approvals but cannot show who or what produced them. The most likely explanation is malicious JavaScript in the browser, but the forensic chain is still being assembled.

Finally, the refund mechanics are not fully public. The <$10,000 automatic restoration and the release form for larger losses are reported by CNBC, not fully documented by Polymarket. Users should verify the process on official channels and be wary of anyone who claims to speed it up for a fee.

The wider lesson

Prediction markets are particularly exposed to this class of attack because the product is a logged-in trading session with a wallet attached. The attacker does not need to steal a seed phrase or break cryptography. It only needs code that can act inside an authenticated session. That is a lower bar than most users assume.

For builders, the lesson is to treat frontend dependencies as production infrastructure. A vendor script that can read the page, call APIs, or trigger wallet interactions belongs in the threat model alongside the smart contracts. Integrity checks, restrictive content security policies, vendor isolation, and least-privilege wallets all help, but none of them eliminates the risk of a trusted vendor being compromised.

For users, the lesson is to separate trading balances from savings, read approval prompts, and treat a “withdrawal” you did not initiate as an emergency. The Polymarket drain was not a failure of the market’s pricing engine. It was a failure of the layer that turns a click into a signed transaction, and that layer is now part of the attack surface for every prediction market.

Sources and references

• BleepingComputer, Polymarket halts trading after crypto-draining script breach, $2.5M traced, October 29, 2026.
• Bitquery, 737 Polymarket wallets lost $2.73M in one hour, October 29, 2026.
• CNBC, Some Polymarket user funds stolen, matter referred to UK authorities, October 29, 2026.
• The Block, Polymarket resumes trading after $2.65 million exploit, October 29, 2026.
• The Wall Street Journal, Hackers swipe millions from Polymarket users in latest security breach, October 29, 2026.
• TechCrunch, Binance pauses withdrawals as hackers suspected of stealing billions in crypto, October 29, 2026, for the separate Binance incident later that day.
• DebugBear, security incident statement; Polymarket status page, incident update.