Polymarket halts trading after vendor breach

Polymarket paused its international exchange on Thursday after a compromised performance-monitoring vendor, DebugBear, let attackers drain money from logged-in accounts. One suspected-attacker wallet took more than $2.5 million across 900-plus transactions. Polymarket pledged full refunds and referred the case to British authorities.

By Harley Young October 30, 2026 5 min read

Polymarket halted trading across its international exchange on Thursday after attackers turned a trusted outside vendor's code into a tool that drained money straight out of logged-in users' accounts, with a single suspected-attacker wallet taking more than $2.5 million. The company behind the world's largest prediction-market exchange, where traders buy and sell contracts on the outcomes of elections, sports and news, said it had found and resolved the problem, handed the case to British law enforcement, and that anyone who lost funds would be "made whole."

The disruption hit Polymarket.com, the international (non-US) venue that traders outside the United States use, and put the exchange into a cancel-only mode with its automated relayer suspended for about an hour. It is the third time in 2026 that attackers have reached Polymarket users through a compromised vendor or key, and the second this year to route through code running inside the website itself.

A monitoring script turned into a drainer

The weak point was not Polymarket's own servers or the blockchain its money sits on. It was DebugBear, a UK-based company that Polymarket paid to watch how fast its website loads and runs. Like many performance monitors, DebugBear works by embedding a small script into the pages a visitor loads, which gives that script a trusted seat inside the site.

DebugBear confirmed on X that it had been "impacted by an ongoing security incident" and told its clients to strip its embed code out of their pages. Polymarket said the vulnerability sat with that outside provider rather than its own platform, and referred the matter to law enforcement in Britain, where DebugBear is headquartered.

Researchers at Hudson Rock, a cybersecurity firm that examined the tampered code, said the DebugBear-served script had been rewritten to do something a monitoring tool never should: find a signed-in user's active trading session, liquidate whatever positions that account held, and sweep the proceeds to a destination wallet written directly into the script as a backup address. The firm said it did not yet know what triggered the script for a given user, or how many people were caught.

Following the money on-chain

Because every transfer lands on a public ledger, the aftermath is visible in a way most breaches are not. An analysis of one suspected-attacker wallet counted more than $2.5 million pulled out across more than 900 separate transactions, the signature of a script firing again and again as different accounts loaded the poisoned page.

That wallet, 0x3f99...fc18, now holds roughly $2.65 million in POL, the native token of Polygon, the network Polymarket runs on, according to data from Arkham, a blockchain-analytics platform. The two figures are not the same measurement and should not be added together: one is the gross amount swept out of accounts, the other is what the wallet is sitting on now after the stolen funds were converted into POL.

The traders caught in it

For the people on the other end, the numbers are not abstract. A trader posting as CarOnPolymarket wrote on X that $800,000 had been taken from his account and that a friend had lost around $600,000. Those claims are the trader's own and have not been independently confirmed, and they are separate from the wallet totals rather than part of them.

Hudson Rock's admission that it cannot yet count the victims matters here: the drainer did not need users to approve anything or click a bad link. If the script ran inside a session they had already opened and trusted, the money could leave while the page still looked normal.

Polymarket's pledge, and what it left out

Polymarket's public message was unambiguous on the money: "We'll make this right and are fully reimbursing all affected traders," and, separately, that "anyone who has been impacted will be made whole." It said trading would come back around 3 p.m. ET the same day, once the problem was contained.

The company's language was more careful on the damage itself. It described finding and resolving "a problem" and did not confirm in its own words that users had lost money, even as traders and on-chain analysis were describing six-figure accounts emptied in real time. The mechanics of the refund were not spelled out in that statement either. Reported terms, which Polymarket has not published itself, put the dividing line at $10,000: smaller losses restored by Friday, larger claims requiring a signed release form. Until the company confirms it, that threshold is best read as unconfirmed.

The third drain of 2026

This is not a first for Polymarket this year. Around May, roughly $700,000 was drained from an internal top-up wallet after a private key was compromised. Around June, attackers exploited a compromised third-party vendor to inject malicious front-end code and took close to $3 million, though from fewer than 15 accounts, and Polymarket pledged full refunds then too.

The through-line is the front end. Polymarket's design is non-custodial, meaning a user's funds sit in a wallet the user controls rather than in a company account, which is supposed to make a server breach far less dangerous. But the page that reaches into that wallet to place and resolve trades is assembled from code written by other companies, and in 2026 that supply of outside code has been the recurring way in.

Why it matters for traders here

The exchange that went dark is the one that matters locally: Israeli traders use Polymarket.com, the international venue, not the separate US arm. The breach also lands at an awkward moment for the platform's standing with that audience. It comes only days after Polymarket opened an insider-trading inquiry into suspicious positions taken on this week's Israeli election, questions about Netanyahu and Likud outcomes that had already put the platform's integrity into the local conversation.

A refund can make a trader whole, but it does nothing to close the door the attackers walked through. The fix Polymarket and DebugBear reached for was blunt: rip the monitoring script out of the page. That restores the accounts and stops this drainer, yet it leaves the larger fact of 2026 standing, which is that the safest part of Polymarket is the wallet you control, and the most dangerous is the code the company lets other people load next to it.

Frequently Asked Questions

How did attackers drain Polymarket accounts through a vendor like DebugBear?

DebugBear is a performance-monitoring service whose script Polymarket embedded in its own pages, which gave that code a trusted place inside the site. According to Hudson Rock, the script was rewritten to find a logged-in user's active trading session, liquidate the account's positions and send the proceeds to a wallet hard-coded as a backup address. Because it ran inside an already-trusted session, no click or approval from the victim was needed.

Will Polymarket reimburse traders who lost money in the October 2026 breach?

Yes. Polymarket said it is "fully reimbursing all affected traders" and that anyone impacted "will be made whole," with trading set to resume around 3 p.m. ET the same day. Reported terms, not confirmed in Polymarket's own statement, put the dividing line at $10,000, with smaller losses restored by Friday and larger claims requiring a signed release form.

Why has Polymarket been hit by three security incidents in 2026?

The recurring weak point is the front end, not the blockchain. A roughly $700,000 loss around May came from a compromised private key, while a nearly $3 million drain around June and this October breach both ran through third-party code loaded into the website. Polymarket's funds are non-custodial, but the page that reaches into user wallets is assembled from outside vendors' code, which has repeatedly been the way in.