Polymarket Security Breach: Trading Is Back Online
The Polymarket security breach interrupted its international platform on October 29 after the company identified a compromised third-party provider. Trading subsequently resumed, making early headlines describing an ongoing shutdown outdated.
The official incident history records an approximately one-hour disruption. Polymarket initially restricted trading and paused relayer actions before announcing that it had identified and fixed the issue.
Relayers help submit transactions to the blockchain. Pausing them restricted another route through which transactions could be processed during the investigation.
Official update | UTC | India time |
|---|---|---|
Cancel-only mode; relayer actions paused | October 29, 18:05 | October 29, 11:35 p.m. |
Company reports issue identified and fixed | October 29, 18:37 | October 30, 12:07 a.m. |
Incident marked resolved | October 29, 19:05 | October 30, 12:35 a.m. |
The affected service was Polymarket’s international platform. WIRED reported that the separate Polymarket US exchange was unaffected.
That distinction matters following Bitnxt’s recent coverage of Polymarket US’s five-minute crypto markets. Services operating under the same brand should not automatically be treated as one technical or regulatory system.
Researchers Identify a Malicious Monitoring Script
Hudson Rock’s technical investigation identified malicious JavaScript retrieved from a DebugBear URL associated with Polymarket.
DebugBear provides website-performance monitoring. Its Real User Monitoring product uses embedded code to measure visitors’ experience.
The researchers found that the retrieved script instead searched for an authenticated user’s trading client, inspected holdings and attempted to sell positions or transfer assets. They also found production-build metadata recording the removal of the DebugBear integration.
Those findings support a specific explanation: malicious code was operating inside the browser environment used to trade.
However, Hudson Rock explicitly left the initial compromise mechanism and full exposure window unresolved. A timestamp showing when replacement software was built does not establish exactly when every user stopped receiving or running the earlier code.
Reuters separately reported that a source familiar with the incident identified DebugBear as the provider involved. DebugBear acknowledged a security incident and advised customers using its monitoring product to remove the embedded code.
What the $2.5 Million Figure Actually Represents
BleepingComputer reported that a suspected attacker wallet transferred approximately 28.6 million POL, valued at roughly $2.57 million, to three other wallets.
That finding explains the approximately $2.5 million figure appearing in early coverage. It should not be presented as Polymarket’s final accounting.
A wallet’s balance and its outgoing transfers measure different things. Adding them together can count the same assets twice, while changing token prices can alter dollar estimates without any additional theft.
Polymarket’s reviewed statements did not provide a final loss figure, confirmed victim count or detailed reimbursement schedule.
Its promise to compensate affected traders is therefore an important commitment, but it does not establish that all repayments have already been completed.
Why the Incident Matters Beyond Polymarket
The research highlights a security dependency outside the trading contracts themselves: code loaded into the user’s browser.
A platform can rely on blockchain settlement while also depending on login services, transaction relayers and third-party website components. Each has a different role, and each requires its own controls.
Bitnxt’s Polymarket platform review provides background on the global venue’s trading and wallet arrangements. This incident shows why assessing those arrangements also requires examining the interface through which users interact with them.
The available evidence does not justify assuming that every account was affected or that a blockchain-wide vulnerability was involved.
Bitnxt’s Take: Restoring Trading Is Only the First Milestone
Our view at Bitnxt is that operational recovery and financial remediation should be measured separately.
Reopening the platform allows trading to continue. A complete response must also establish which users lost assets, how compensation is calculated and whether repayments have reached them.
The technical follow-up should explain how third-party code gained access to sensitive trading functions and what limits now prevent a similar incident. It should also address browser sessions that were already open when the integration was removed.
For readers, the most meaningful updates will be a verified loss reconciliation, completed reimbursement figures and a detailed account of the control changes. A resolved status page answers the availability question; those disclosures will answer the remaining security and recovery questions.
