Polymarket Halts Trading After DebugBear Script Drains Wallets

Prediction market platform Polymarket temporarily suspended trading on Thursday, October 29, after attackers compromised a third-party monitoring service to push cryptocurrency-draining JavaScript to users. BleepingComputer traced approximately 2.5 million USD in assets to a suspected attacker wallet, while Hudson Rock researchers documented how the malicious script hijacked authenticated trading sessions. The incident highlights a growing problem for financial platforms, since a single compromised vendor script can inherit the full authority of a logged-in user.

Polymarket placed its exchange into cancel-only mode at 2:05 p.m. ET and paused relayer actions while its team investigated reports of drained wallets. At 2:37 p.m., the company announced that it had identified and fixed the issue affecting its international platform, Polymarket.com, and that it had referred the matter to law enforcement.

In a status update, Polymarket blamed a compromised third-party provider and promised affected traders that "anyone who has been impacted will be made whole." Trading resumed roughly one hour after the initial suspension, and the company marked the incident as resolved on its status page at 3:05 p.m. ET.

Polymarket has not yet disclosed how many users the attack affected, how much cryptocurrency the attackers stole, or how its reimbursement process will work. The company also faces questions about repeat exposure, because Hudson Rock notes that a separate June 25 incident reportedly cost users around $3 million. Hudson Rock stresses that those earlier figures and reimbursement assurances pertain to the June event and do not apply to the October 29 compromise.

The malicious file resided on infrastructure owned by DebugBear, a website performance monitoring service that helps organizations track page load times and user experience. DebugBear's Real User Monitoring (RUM) product relies on JavaScript that customers embed in their websites to collect performance metrics directly from visitors' browsers.

DebugBear confirmed an ongoing security incident on X and told customers, "If you use our RUM product, please remove the embed code from your website." BleepingComputer found DebugBear's own website offline and displaying a Cloudflare error, although the publication could not determine whether the outage related to containment efforts.

A community warning first flagged the file at cdn.debugbear[.]com/C7xcKKrjUnXK.js, alleging that it accessed login data, triggered wallet signatures, sold holdings, and moved assets. Hudson Rock researchers downloaded the script twice on October 29 and received an identical 15,187-byte payload containing clear asset-theft logic both times.

The researchers also discovered Polymarket production build metadata with a commit message explicitly recording the removal of the DebugBear RUM script from the platform. That build carries a timestamp of 1:59 p.m. ET on October 29, placing the removal shortly before Polymarket publicly acknowledged the incident.

The script first checks whether a visitor is logged in to Polymarket, then reads local storage entries containing authorization data, wallet addresses, and API credentials. Rather than stealing passwords or seed phrases, the code searches the running web application for the trading client and signer that the user already authorized. It traverses React's internal component structures to locate an object that exposes order-placing methods, then attempts to use that object to act on the victim's behalf.

Next, the malware queries the victim's balances and positions, then calculates a total portfolio value to decide whether the account is worth targeting. The code applies configurable value thresholds to filter targets and exits immediately when Polymarket's geoblock response marks the visitor as blocked. The attack path depends on how the victim authenticated with Polymarket, and Hudson Rock identified two distinct branches within the captured code.

• EOA accounts: The script builds an ERC-1155 batch transfer that moves eligible prediction-market position tokens directly to the attacker-controlled recipient address.
• Magic and other non-EOA accounts: The script submits SELL orders at progressively aggressive prices, then attempts to transfer the proceeds from the account.

In both cases, the payload constructs EIP-712 deposit wallet batch messages for Polygon and requests signatures through the signer already present in the session. The malware also attempts to convert other cryptocurrency holdings into transferable assets, abusing Polymarket's legitimate transaction functionality to move value. Throughout the process, the script communicates with data.debugbear[.]com, which serves as both a command-and-control server and an exfiltration point for stolen data.

BleepingComputer notes that the attackers' use of DebugBear infrastructure for both delivery and data collection raises questions about how deeply they accessed the vendor's systems. Hudson Rock adds that DebugBear's domains are legitimate monitoring infrastructure, so the hostnames alone do not prove malice without examining the code they actually serve. The researchers found no evidence that the attackers compromised other DebugBear customers, although investigators have not yet determined how the initial breach occurred.

Tracing the Stolen Funds

Hudson Rock found the Polygon address 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18 hard-coded in the payload as the default recipient for stolen assets, although remote configuration could select another destination. BleepingComputer's blockchain analysis showed this wallet transferring roughly 28.6 million POL, worth about $2.57 million, onward to three additional wallets.

Blockchain records also show the wallet interacting repeatedly with Polymarket's prediction-market token contract between 1:50 p.m. and 1:56 p.m. ET on Thursday. Hudson Rock reviewed a PolygonScan screenshot showing approximately $2.19 million at the address, but cautioned that this figure is not a verified total of the theft.

One trader, posting as @CarOnPolymarket, reported losing $800,000 after their account was drained and later stated that the attacker had sold all of their positions. That liquidation matches the selling behavior present in the payload, although Hudson Rock could not independently verify the original post or its underlying transactions. Researchers also warn readers not to add the reported 800,000 USD loss to the wallet balance, since the two figures could overlap significantly.

This incident demonstrates that any code running alongside an authenticated trading interface effectively becomes part of that interface's security boundary, regardless of its intended purpose. A performance monitoring tool should measure page speed; however, once attackers alter its code, the browser grants it the same trust as the host site.

Because users never see these background scripts, they have little reason to suspect danger when a familiar website suddenly requests a transaction signature. Hudson Rock recommends that platform operators pin trusted assets with Subresource Integrity and pair this protection with a restrictive Content Security Policy.

Hudson Rock emphasizes that a signing request alone does not prove a completed theft, because wallet providers may prompt, reject, or restrict such requests. Nevertheless, users who accessed Polymarket around the time of the incident should review their accounts carefully and take several precautions to limit exposure. The following steps reflect guidance from Hudson Rock's investigation and general best practices for anyone holding assets on Web3 platforms:

• Reject unexpected requests: Users should never approve a signature or transaction prompt simply because it appears while a familiar website remains open.
• Close exposed tabs: Users should close any tabs left open during the incident, since cached pages could still contain the malicious script.
• Review account activity: Users should check recent orders, position changes, and wallet transactions through a clean session or an independently accessed blockchain explorer.
• Keep records: Users who spot anomalies should save timestamps and transaction hashes, as this evidence can support any reimbursement claim with Polymarket.
• Avoid recovery scams: Users should ignore unsolicited recovery links and never share a seed phrase, because scammers frequently exploit high-profile breaches like this one.

Disconnecting a wallet does not reverse completed transfers or automatically revoke on-chain approvals, so users should review permissions in accordance with official platform support guidance. Affected traders should also monitor Polymarket's official status page and X account for details about the promised reimbursement process. Website owners using DebugBear's RUM product should follow the vendor's advice immediately and remove the embed code until the company completes its investigation.