The Polymarket hack of October 29, 2026 did not start in a smart contract but in a third-party JavaScript file embedded in the site. The prediction market platform put its international exchange, Polymarket.com, into cancel-only mode for about an hour on Thursday and said one of its providers had been compromised. According to media reports, the provider is the UK-based performance monitoring service DebugBear. Security researchers found code in a script served from its infrastructure that hijacked logged-in Polymarket sessions and moved funds to an attacker wallet.
For crypto users the incident is a warning, and for web developers it is a lesson: a harmless-looking analytics script has the same privileges in the browser as your own code. Here is what is confirmed, what comes only from reports, and what operators can learn from it.
Key Takeaways
- Polymarket confirms that a third-party provider was compromised but has not named it. CNBC and Reuters, citing a person familiar with the matter, report that the provider is DebugBear.
- DebugBear itself reported an ongoing security incident and asked customers of its RUM product to remove the embed code from their websites.
- According to BleepingComputer and Hudson Rock, the malicious script used existing trading sessions to sell positions or transfer tokens to an attacker address.
- The loss has not been officially confirmed. Analyses of blockchain data put it at roughly 2.5 to 2.7 million US dollars.
- Polymarket promises to fully reimburse everyone affected. According to CNBC, its US platform was not compromised.
Polymarket hack: the timeline on October 29
Polymarket’s status page documents the incident with timestamps (UTC). At 6:05 PM, Polymarket put the exchange into “cancel-only mode”: orders could only be cancelled, no new trades were processed and relayer actions were paused. At 6:37 PM the explanation followed: the company had identified and fixed the issue on its international platform. “One of our third party providers was compromised,” it wrote, adding that the matter had been referred to law enforcement and that anyone affected would be made whole. At 7:05 PM the incident was marked as resolved and trading resumed.
According to BleepingComputer, the suspicious transactions of the attacker wallet took place between 5:50 PM and 5:56 PM UTC, shortly before the trading halt. An entry in Polymarket’s production build metadata, discovered by Hudson Rock, carries the commit message “remove debugbear rum script” and is timestamped 5:59 PM UTC. That would mean Polymarket removed the integration before it disclosed the incident publicly.
DebugBear’s role
DebugBear is a website performance monitoring service. Its real user monitoring (RUM) product relies on a JavaScript snippet that site operators embed in their pages to measure load times and user experience for real visitors. At 6:00 PM UTC on October 29, DebugBear wrote on X: “We’re impacted by an ongoing security incident. If you use our RUM product, please remove the embed code from your website.” (post on X). A second post followed late in the evening: the company said it was treating the incident as a top priority, had engaged specialist cyber incident response support and would work with affected customers directly.
Polymarket itself has not named DebugBear as the cause. That attribution comes from CNBC and Reuters, both citing a person familiar with the matter. According to CNBC, Polymarket referred the case to UK authorities because DebugBear is based there. DebugBear’s website was unreachable on Friday morning and showed a Cloudflare error. Whether this is related to containment efforts is unclear.
What the malicious script did
The analysis by BleepingComputer describes malware tailored specifically to Polymarket. According to Hudson Rock, it was delivered through a script file on DebugBear’s CDN domain. The code first checked whether a visitor was logged in to Polymarket and then used that person’s existing trading session and the platform’s regular trading functions. It read balances and positions to assess the value of an account. Depending on how the user had authenticated, it tried either to sell positions automatically or to transfer the position tokens directly to an attacker address. It also tried to convert crypto holdings into assets that could be moved out.
One detail is especially troubling. According to BleepingComputer, the script talked to another DebugBear subdomain for instructions and to send out data. The provider’s infrastructure was therefore used both for distribution and for command and control, which raises questions about how deep the attackers got into the vendor’s systems. DebugBear has not yet published a statement on the root cause.
How large is the loss?
Polymarket has disclosed neither the number of affected users nor the size of the loss. The available figures come from blockchain analyses and are therefore estimates. According to BleepingComputer, the wallet identified by Hudson Rock moved about 28.6 million POL, worth roughly 2.57 million US dollars, to three other addresses. The Block cites Arkham data showing that the address held about 2.65 million US dollars in POL after several swaps from USDC.e to POL. CNBC cites the analytics firms Betting Intelligence and Polysights, which counted at least 2.7 million US dollars withdrawn across 710 wallets.
On reimbursement, Polymarket told users on Discord, according to CNBC, that those who lost less than 10,000 US dollars should have their funds restored by October 30. Users with larger losses have to sign a release form. Officially, Polymarket’s status page only confirms that everyone affected will be “made whole”.
Analysis: a supply chain attack in the browser
The incident comes at a sensitive time. CNBC expects heightened volumes on both Polymarket exchanges around the US midterm elections on November 3, and the platform is already under regulatory scrutiny, as the New York lawsuit shows. According to CNBC, Polymarket already reported in June that a third-party vendor had been compromised.
Technically, this is a supply chain attack of the kind known from package registries, such as the recent npm dependency confusion wave, only this time in the browser. As with the Bitget hack, the weakness was not in the blockchain but in the infrastructure around the platform. In our view, there are several lessons for operators of web applications that touch money or wallets:
- Inventory third-party scripts: Every embedded script runs with the full privileges of the page. Operators should know which external scripts load where, including those added through tag managers.
- Separate sensitive areas: Monitoring and analytics code does not have to run on pages where users trade, pay or sign transactions.
- Enforce integrity: Subresource Integrity blocks a modified file if its hash is pinned. For scripts that a vendor updates continuously, that is often impractical, and self-hosted, reviewed versions are an alternative.
- Use a Content Security Policy: A strict CSP with narrowly defined sources for scripts and network connections makes it harder to send data to foreign servers, but it helps little when the compromised vendor itself is on the allowlist.
Polymarket users should check their accounts and positions and watch for official updates on reimbursement. Be careful with messages that promise refunds and ask for wallet details. Follow-up phishing waves are common after major incidents.
Conclusion
The Polymarket hack shows that security on crypto platforms does not end at the smart contract. Based on what is known so far, a vendor’s performance script was enough to drain millions within minutes. Polymarket reacted quickly and promises reimbursement. Still open are the exact loss, the number of affected users and, above all, how the attackers got into DebugBear’s infrastructure. Until reliable details emerge, all of the vendor’s RUM customers should follow its advice and remove the code.
