MONERO.LOVE / NEWS / SECURITY

Polymarket Hack: A Monitoring Script Drained Traders’ Wallets

A hijacked DebugBear monitoring script targeted signed-in Polymarket traders. How the October 29 attack worked, what refunds cover, and why scripts matter.

Published · 4 min read

Coins escape a trading page through a torn monitoring widget.

A tool meant to measure website speed became a route into traders’ wallets. On October 29, attackers replaced a DebugBear monitoring script loaded by Polymarket with malicious code targeting people who already had the prediction market open and were signed in.

The Hacker News reports about $2.7 million in losses across 726 wallets. Polymarket’s incident update puts total compensation at $3.9 million, including losses connected to the trading pause. Those figures measure different things.

A trusted script changed hands

DebugBear’s real user monitoring service normally measures how pages perform in visitors’ browsers. Polymarket loaded a customer-specific JavaScript file from the vendor’s infrastructure. That familiar address began serving code designed to move money.

According to The Hacker News, DebugBear said its DNS records were compromised through its domain registrar. The company’s preliminary investigation pointed to one customer’s website and found no indication that its internal systems were breached. That account does not establish how the attacker obtained registrar access.

Ohey’s researchers compared archived scripts with the malicious file and observed a different server answering for DebugBear’s addresses. Their blockchain trace found 28.6 million POL reaching the recipient wallet, alongside transferred trading positions. Token balances and dollar loss estimates should not be added together.

Ohey places the first recipient inflow at 17:10 UTC and the last position-token inflow at 18:02 UTC. That window describes observed transfers. It does not establish when browsers loaded the malicious script or when every session stopped running it.

The attacker used an existing session

Hudson Rock’s analysis found code that read browser account information and searched the running application for its trading client and transaction signer. The researchers reviewed the file without executing it.

The script took different paths depending on account type. For accounts using an external crypto wallet, it attempted to transfer position tokens. For email-login accounts, it attempted to sell positions at increasingly poor prices before moving the proceeds.

Both paths requested signatures through the account’s existing signer and submitted transactions through Polymarket’s relayer, the service that sends them onward. Reading the code does not prove every request succeeded without a prompt. Wallet providers could still ask for confirmation, reject a request, or enforce session rules.

Hudson Rock found no routine sending a seed phrase, private key, password, or trading credential map to the reporting endpoint. The danger was misuse of authority already available inside the page.

What Polymarket says it refunded

Polymarket says it removed the compromised script, cleared caches, reset active login sessions, and paused trading and relayer activity. It also referred the case to law enforcement.

Its October 30 update says 95% of affected wallets had been refunded in full. The $3.9 million package includes the approximately $2.7 million theft and about $1.2 million covering additional losses. These are company figures, not an independent audit of completed payments.

Polymarket says eligible traders need not submit claims. Anyone disputing an amount should reach the review form through its official incident page.

A familiar website still needs boundaries

For operators, Subresource Integrity lets a browser compare a downloaded script with an expected cryptographic hash and reject changed contents. It requires controlled updates and a known, reviewed version. Merely allowing a vendor’s hostname does not verify the file that arrives.

For traders, unexpected signing requests deserve scrutiny even on a bookmarked site. Review account activity through a trusted route and ignore unsolicited recovery offers.

Our Binance coverage examines a separate failure around transaction authorization. The connection is a security lesson, not evidence of shared attackers. For Monero users, keeping recovery information private remains essential. A safe backup cannot compensate for approving an unwanted transaction.

Support Monero Love

Help keep the public nodes and packages running. Send any amount of XMR.

89hGTKxRVA3AUeKAbCRBt5TMSzq3MQZooNNsezCpNFjp2oeJPRx8AJeGKA8ziHZNqab78f4Vr1ntxhPDxX5298nnGZjHkhm