Polymarket hack turned a monitoring script into theft

In the Polymarket hack on October 29, 2026, attackers replaced a DebugBear monitoring script loaded by Polymarket and used the replacement to sell signed-in traders' positions and move assets to attackers. They did not need to export private keys. The code looked for the application's existing transaction signer instead. The failure sat at a specific boundary: third-party code running in the browser could reach the transaction authority of an authenticated trading session.

Polymarket is refunding about $2.7 million to affected wallets, according to The Hacker News.

How did the Polymarket hack reach trading sessions?

The entry point in the Polymarket hack was a DebugBear real user monitoring script that Polymarket loaded into its website. Attackers replaced it. DebugBear says they compromised its DNS records through its domain registrar, redirecting requests for the script away from the infrastructure that normally delivered it.

The legitimate RUM tool measures page-loading performance for real visitors. On October 29, Hudson Rock researchers downloaded the malicious file from the same address Polymarket used for its DebugBear integration.

At 18:13 UTC, Ohey researchers found a different server answering for DebugBear's web addresses. The malicious file was still online. Earlier that day, Google Cloud Storage had served the normal script. DebugBear customers each load their own copy, and the file replaced in this attack was the copy used by Polymarket—not an observation that every customer's copy had been replaced.

The reporting is less settled on the initial compromise. Yahoo Finance and CCN describe the method used to compromise the provider as unresolved; The Hacker News gives DebugBear's more specific explanation that its DNS was compromised through its registrar. DebugBear's early findings pointed to an attack targeting one customer's website.

The malicious script reused trading clients and signers

The examined code worked with authority already available in an open, authenticated Polymarket page. It read account information held in the browser, including trading API keys, then searched the application for its trading client and transaction signer.

API keys alone cannot place Polymarket orders. Orders also need a wallet signature. The demonstrated failure in the Polymarket hack was session abuse, not export of those secrets.

The code chose between two paths, depending on how the account had signed in:

Both paths asked the account's own signer to authorize requests and passed those requests to Polymarket's relayer for submission. CCN reports that the traced transactions carried valid authorizations, so the smart contracts processed them as legitimate actions despite the account owners not consenting to them.

There is a limit to what the code analysis proves. Hudson Rock reviewed the file without running it and warned that requesting a signature does not prove a trader signed without seeing a prompt. A wallet provider could prompt the trader, refuse the request or apply its session rules.

I'd add this question to credential-focused reviews: before any credential leaves the browser, what can malicious code make the authenticated application do with the authority it already holds inside that signed-in session?

Polymarket hack loss estimates use different measures

Bitquery placed the main withdrawal activity between 17:10 and 18:10 UTC. Ohey followed the wallet address embedded in the malicious code: its first incoming funds arrived at 17:10 UTC and its last at 18:02 UTC. That receiving wallet collected 28.6 million POL tokens. It also received positions from 33 wallets, which are a separate part of what was taken.

At 18:19 UTC, DefiPrime valued the POL tokens at about $2.64 million, using DefiLlama's price of $0.0922. That valuation excluded the positions. CCN likewise reports that Bitquery assigned no dollar value to the prediction-market shares seized from 33 users. The withdrawal total may therefore understate the full economic damage.

The losses were concentrated, too. CCN's account of Bitquery's findings says four accounts represented approximately 43% of the stolen amount, and the largest single withdrawal was $358,369. Another 276 accounts each lost less than $100.

The assets did not stay in the first receiving wallet. Its transaction history showed all 28.6 million POL moving to three other addresses between 18:28 and 18:38 UTC. CCN reports that some assets later moved to Ethereum through Relay, deBridge and Polygon's native bridge.

Script removal did not establish the containment window

The reported October 29 sequence shows why the timestamps need to be read separately, not collapsed into one containment time:

• 17:38 UTC: Polymarket posted its first status update about unauthorized activity in user wallets.
• 17:59 UTC: Production-build metadata recorded removal of DebugBear's monitoring script, according to Yahoo Finance and CCN.
• 18:05 UTC: Polymarket said its exchange was in cancel-only mode and relayer actions were paused. Cancel-only mode blocked new trading while allowing existing orders to be canceled.
• 18:13 UTC: Ohey found the malicious file still available from the changed server answering for DebugBear's addresses.

Polymarket said it removed the script within the hour, cleared every cache and reset all active login sessions. Trading stayed paused until the site was clean, according to the company. Polymarket also referred the incident to law enforcement. CCN, citing Reuters, reported that UK authorities were involved in the case.

Trading later resumed on the international platform. CCN puts restoration at approximately 19:05 UTC, while noting that some reports gave a later restart. Then, at 19:11 UTC, Bitquery flagged another suspicious withdrawal: $10.99 from an already-affected account, using a new authorization. By itself, it does not establish that the wider attack continued after trading resumed.

I would want evidence of session invalidation and relayer state before accepting a clean production bundle as sufficient containment. The Polymarket hack crossed from browser code into transaction authority; containment evidence needs to cover that same path.

Removing DebugBear and reviewing transaction-page scripts

1. Remove DebugBear's RUM embed wherever it is deployed. DebugBear directs this instruction to its RUM customers, not just Polymarket.
2. Remove unnecessary third-party code from pages where users trade or sign. Hudson Rock specifically identifies these pages as places to keep unneeded outside code away from the authority used to authorize transactions.
3. Review what page code can ask the signer to do. Inspect the authority available to code inside the authenticated page. Checking only whether secrets are sent elsewhere misses the session authority that the examined file sought to use.

I'd put third-party code reviews on trading and signing pages ahead of optional performance telemetry. The question is specific: does that telemetry need to run on the same page as the capability to authorize movements of the trader's assets, with the authority the malicious code sought here?

When The Hacker News checked on November 1, cdn.debugbear[.]com had no DNS record.

A CDN allowlist cannot verify script contents

A security policy that allows a trusted CDN does not verify the contents returned by that CDN. That is the gap Hudson Rock's SRI recommendation addresses. Where a file's expected contents can be pinned, the browser can reject a changed file.

Polymarket says it is restoring third-party scripts with additional checks, including a stronger Content Security Policy, pinned versions and sandboxing.

For a team unable to pin a monitoring file, I'd choose less telemetry on the signing page over treating a CDN allowlist as verification of its contents.

Polymarket refunds include trading-pause losses

Polymarket's reimbursement program covers directly affected wallets and additional losses associated with the trading pause or taken positions. Traders do not have to file a claim for the announced payments.

By October 30, Polymarket said it had refunded 689 of the 726 affected wallets in full and was paying the remaining 37 as they were checked.

The company is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken. The Hacker News reports $3.9 million being returned to traders in all. It includes losses caused by the interruption to trading, so using it as another estimate of stolen assets would combine different categories of loss under one figure.

Traders who believe their payment amount is wrong, or that they should have received a payment, can use the form linked from Polymarket's status page.

For the next signing request, Hudson Rock's advice is concrete: reject it if you did not expect it.