Polymarket Halts Trading After Third-Party Breach Drains About 2.7 Million Dollars From Users

Polymarket third-party breach halts trading

On Thursday, October 29, 2026, Polymarket took its international exchange offline briefly after a third-party provider was compromised. The Polymarket third-party breach is a supply-chain story, not a story about Polymarket's own servers being hacked directly. A script belonging to an outside vendor was compromised, and that script ran on Polymarket's site, where it could interact with logged-in users. Polymarket posted on X that the issue was identified and fixed and had been referred to law enforcement, and trading was restored the same afternoon.

The timeline was fast. Trading went into cancel-only mode at about 2:05 p.m. ET, relayer actions were paused, and trading was fully back online by about 3:00 to 3:05 p.m. ET. A one-hour halt is short by exchange standards, and it suggests Polymarket's team moved quickly once the problem was spotted. Speed matters here, because in a live trading incident every minute of exposure is another minute in which the malicious script can act on user sessions.

What was taken, and what is still unconfirmed

Blockchain analytics firms estimate roughly 2.7 million dollars stolen. Betting Intelligence and Polysights told CNBC an account withdrew at least 2.7 million dollars from 710 wallets, while Bubblemaps counted about 700 to 712 affected users and about 2.7 to 2.71 million dollars. Polymarket itself has not confirmed a loss figure or a user count, so treat the 2.7 million dollar figure as an analytics estimate, not an official total.

Security firm Hudson Rock told Decrypt the malicious script looked for logged-in trading sessions, tried to sell positions and move assets, and listed a suspected attacker wallet as a fallback recipient. On-chain data showed about 28.6 million POL moved out in three transfers between 2:28 and 2:38 p.m. ET. That ten-minute window is the core of the incident: a script that runs in a user's browser, inside a trusted site, can do a great deal of damage before anyone notices, because the browser trusts the site and the site trusts the script.

The vendor in the middle: DebugBear

Researchers linked the attack to a compromised script from DebugBear, a UK-based website performance monitoring firm whose Real User Monitoring JavaScript runs on customer sites. A person familiar with the matter told CNBC the issue stemmed from DebugBear, and Polymarket reported the incident to UK law enforcement. That detail is the most important part of this story for anyone who runs a website, not just a crypto exchange.

Third-party scripts are everywhere. Analytics, performance monitoring, chat widgets, A/B testing tools, and payment helpers all run code inside your site, with the same privileges as your own code. When one of those vendors is compromised, every customer site becomes a delivery vehicle for the attacker's script. This is the same pattern behind some of the biggest web supply-chain incidents of the past decade, and it keeps working because the trade-off is real: those scripts provide genuinely useful services, and removing them all is not practical for most teams.

Polymarket promises full reimbursement

Polymarket promised full reimbursement, saying anyone who has been impacted will be made whole and that it is fully reimbursing all affected traders. It gave no repayment schedule or claim process at the time of reporting, so affected users are waiting on details. A reimbursement promise is better than silence, but it is not the same as money back in a wallet, and the timeline will matter for trust.

Polymarket's US platform was not affected; only the international platform was hit. That separation limited the damage, and it is a reminder that platform architecture matters in an incident. If the US and international platforms had shared the same frontend scripts, the blast radius could have been much larger.

The second incident in months

This is the second third-party incident for Polymarket in recent months. In June 2026, a compromised vendor's malicious frontend script led to about 3 million dollars taken from users, so the October 29 loss sits just under that total. Two incidents with the same shape, in the same year, is a pattern, not bad luck. It raises an obvious question: what changed after June, and why was it not enough?

That question applies well beyond Polymarket. The Akira claim against CHAT insurance and the Gamdom breach claim show different attack shapes, but the lesson is consistent: the vendor and partner ecosystem is part of your attack surface, whether you like it or not. The GMO Internet breach, where a company refused a 50 million dollar ransom after 26,739 servers were hit, shows the other end of the scale, where the compromise is deep inside your own infrastructure rather than borrowed from a vendor.

What users and site owners should take from this

For users, the practical advice is unglamorous but real. Keep only what you need on an exchange, use a hardware wallet for funds you are not actively trading, and be suspicious of unexpected prompts or trades during a session, especially if a site behaves oddly. None of that would have stopped this script entirely, because the script ran inside a trusted site, but smaller balances and faster exits limit the damage when something goes wrong.

For site owners, the lesson is about third-party script hygiene. Audit which scripts run on your pages, especially on authenticated pages and checkout flows. Use subresource integrity where you can, so a changed script fails instead of running. Consider loading non-essential scripts only on pages that actually need them, and never on pages where users hold money or make trades. And have an incident plan that includes your vendors: when a vendor script is the problem, your first call should be to the vendor and to law enforcement, and your second should be to your users, with specifics, not reassurances. Polymarket moved fast on the halt and the reimbursement promise. The harder test is whether the June and October incidents together produce a real change in how it vets and isolates third-party code, because a third incident with the same shape would be much harder to explain away.