Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Hudson Rock report summary cards on the Polymarket script: Polymarket-specific theft logic, removal recorded in a live build, and 2.19 million dollars displayed at the recipient address.
Image: Hudson Rock (fair use). Summary cards from Hudson Rock's analysis, published Oct. 29, 2026.

Response

Hudson Rock Says a DebugBear Performance-Monitoring Script on Polymarket Was Rewritten to Hijack Logged-In Trading Sessions, Sell Positions and Send Assets to an Attacker Wallet

Polymarket halted trading for about an hour and said a third-party provider was compromised, as DebugBear told customers to pull its monitoring embed code. The 15,187-byte payload reused the page's own trading client and signer, and Hudson Rock warns that allowing a trusted CDN does not verify the bytes it serves.

Noah Park, ResponseNew York5 min read

NEW YORK - A performance-monitoring script that the prediction market Polymarket loaded from the web analytics company DebugBear contained code built to hijack logged-in users' trading sessions, sell or transfer their positions and send the proceeds to an attacker's wallet, according to an analysis published on Thursday by the threat intelligence firm Hudson Rock.

Polymarket put its exchange into cancel-only mode and paused relayer actions at 18:05 UTC on Thursday, 2:05 p.m. in New York. At 18:37 UTC it said on its status page that it had identified and fixed the issue on its international platform. "One of our third party providers was compromised, and we have referred this to relevant law enforcement," the company said. "Anyone who has been impacted will be made whole." It marked the incident resolved at 19:05 UTC.

DebugBear, whose Real User Monitoring product embeds JavaScript in customer pages to measure load times, said on X that it was "impacted by an ongoing security incident" and told customers: "If you use our RUM product, please remove the embed code from your website."

A payload that borrows the user's own session

Polymarket's post on X saying it had identified and fixed an issue on its international platform after a third-party provider was compromised.
Image: Polymarket Traders account on X, via Hudson Rock (fair use).Polymarket's statement on Oct. 29, 2026.

Hudson Rock downloaded the file named in a community warning, cdn.debugbear[.]com/C7xcKKrjUnXK.js, at 18:12:06 UTC and again at 18:13:04 UTC, and got the same 15,187-byte payload both times. It reviewed the code as text and did not run it or connect a wallet.

The script reads three local-storage entries, polymarket.auth.params, polymarket.auth.proxyWallet and poly_clob_api_key_map, which hold authorization context, the deposit-wallet address and a map of trading API credentials. It then walks React's internal component structures looking for an object with trading methods and its signer. With that in hand, it queries balances and positions, values the portfolio against thresholds and exits if Polymarket's geoblock check marks the visitor as blocked.

From there the code branches. For some positions it builds a batch transfer of the position tokens to the configured recipient. For others it submits sell orders at increasingly aggressive prices and then tries to move the proceeds. It requests signatures through the signer already in the page, submits the signed batches to Polymarket's relayer and reports wallet addresses, IP and country, operating system, account type, portfolio values and transfer results back to its endpoint.

Hudson Rock said it did not find a routine that sends the credential map, a password, a seed phrase or a private key to that endpoint. "Its central approach is to reuse authority already available in the authenticated application," the analysis said. It also cautioned that "a signing request is not proof of a silent signature or a completed theft," since a wallet provider may prompt or reject.

What the money and the build show

PolygonScan screenshot of the address hard-coded as the payload's fallback recipient, showing about 2.18 million dollars in POL value and 16,170 dollars in token holdings.
Image: PolygonScan screenshot supplied to Hudson Rock (fair use).Holdings at the payload's fallback recipient address.

The payload's hard-coded fallback recipient is 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. A PolygonScan screenshot supplied to Hudson Rock showed about $2.19 million at that address. Hudson Rock called that "evidence of substantial holdings at an address explicitly selected by the payload," not a verified total of stolen funds. BleepingComputer, examining the same wallet, found it had moved about 28.6 million POL, worth roughly $2.57 million, to three other wallets, and had made a string of transactions involving Polymarket's token contract between 17:50 and 17:56 UTC, minutes before the exchange halted trading.

Hudson Rock panel showing Polymarket production build metadata with the change message chore(polymarket): remove debugbear rum script and a build timestamp of Oct. 29, 2026, 17:59:20 UTC.
Image: Hudson Rock (fair use).Polymarket's own build metadata recording the removal of the DebugBear script.

Polymarket's own published code records the response. Production build metadata carries the change message "chore(polymarket): remove debugbear rum script (#15337)" with a build timestamp of 17:59:20 UTC. Hudson Rock's homepage capture at 18:12:06 UTC no longer referenced the script or allowed DebugBear in its Content Security Policy, and of the 102 first-party JavaScript files that response listed, the only DebugBear match was that removal note. Hudson Rock said a build time is not a verified containment time.

Several questions remain open: how many users were affected, total losses, the exact exposure window and how the script was altered. Hudson Rock said the evidence does not identify an attacker or show a wider compromise of other DebugBear customers.

The response lesson

For incident responders, Hudson Rock's checklist starts with evidence: capture the exact response bytes, hashes, HTTP metadata, loader references and browser request history "before a changing CDN response obscures the exposure window." It recommends removing unnecessary third-party integrations from authenticated trading and signing flows, and warns that "a legitimate vendor hostname alone is an unreliable maliciousness test."

Where assets can be pinned, Subresource Integrity lets the browser reject a file whose contents have changed, paired with a restrictive Content Security Policy and a controlled update process. "Simply allowing a trusted CDN does not verify the bytes it serves," the analysis said. Teams should also review what an authenticated page can request and which actions demand fresh user confirmation. For affected users, Hudson Rock advised rejecting unexpected signing requests, checking recent orders and wallet activity from a clean session and remembering that disconnecting a wallet does not reverse completed transfers or revoke on-chain approvals.

Sources:


Noah Park covers incident response and blue-team operations for SOCtember from New York.

Related stories

Response desk