A halt that lasted about an hour
Polymarket, a leading crypto prediction market, hit its own emergency brake on October 29, 2026. At 18:05 UTC the exchange entered cancel-only mode and paused the relayer service that submits traders’ signed transactions, after detecting an incident on its Predictions Trading API. Within an hour the company said it had “identified and fixed” the issue, confirmed that “one of our third party providers was compromised,” referred the matter to law enforcement, and pledged that “anyone who has been impacted will be made whole.” The status page marked the outage resolved at 19:05 UTC, with trading set to resume the same evening.
The vector was a monitoring script, not the protocol
What makes the episode instructive is where the breach sat: not in Polymarket’s core contracts but in a vendor further up the supply chain. Security researchers at Hudson Rock retrieved JavaScript from a DebugBear performance-monitoring URL associated with the platform and found it searched for a logged-in user’s trading client, inspected the portfolio, and attempted to sell positions and move assets. Polymarket’s own production build records the removal, with the change message “remove debugbear rum script” timestamped at 17:59:20 UTC that evening. A supply-chain compromise is harder to stop than a direct hack because the malicious code arrives through a vendor that already has legitimate access to the production environment.
The loss figure is not settled
This is where precision matters. On-chain forensics firm Arkham attributed roughly $2.65 million to a single wallet linked to the suspected attacker, but Hudson Rock’s independent review shows about $2.19 million at the script’s fallback recipient and states plainly that aggregate losses remain unverified. The two figures do not reconcile, and neither is a confirmed total. What is not in dispute is the response: the halt, the fix, the law-enforcement referral and the make-whole pledge are all recorded on Polymarket’s own status page.
Why the pattern matters
The October incident is the latest in a run of third-party security events the platform has disclosed this year, which points to the weak spot being vendor tooling rather than the prediction-market protocol itself. Every venue that loads third-party scripts now has a concrete reason to audit what those scripts can reach inside a user session. For traders, the practical lesson is uncomfortable: a signature prompt or a silently sold position looks identical to normal trading until the balance is gone, so a position is only as safe as the weakest third party plugged into the frontend that manages it.
What the record leaves open
Nothing in the incident points to a flaw in the prediction-market contracts themselves; the failure sat in the browser layer, where a vendor’s script could reach a signed-in session. That distinction matters. It is not a verdict on decentralized prediction markets, but a warning about the unglamorous layer every venue shares — the third-party JavaScript that runs after a user signs in. The concrete defense is mundane: review what scripts a platform loads, treat an unexpected signature prompt as a stop signal, and keep in a hot wallet only what you are actively trading.
Source: BlockchainReporter.