Polymarket says it is returning $3.9 million after a compromised performance-monitoring script used traders’ active sessions to move money. Its October 30 postmortem separates $2.7 million from the attack and $1.2 million covering losses around the trading pause. The important failure happened inside the familiar trading page: a third-party script gained access to machinery the customer was already using.
A performance tag reached for the trading client
Hudson Rock’s October 29 investigation retrieved the same 15,187-byte JavaScript file twice from a DebugBear CDN address. Instead of merely measuring page performance, the code searched the running application for its trading client and signer. A signer is the component that authorizes wallet operations; reaching it is more consequential than collecting a page-load statistic.
The researchers describe two routes: transferring position tokens for one account type, or attempting sales before moving balances for another. That distinction matters. Code designed to sell positions does not establish that every trader’s holdings were sold, and a requested signature does not prove a completed transaction. The researchers reviewed the sample without executing it with a wallet.
This is a different trust boundary from the earlier Polymarket-themed email scam. Here, the platform’s own page loaded the hostile dependency. Checking the address bar alone could not distinguish the changed script from the monitoring code the site intended to run.
A balance screenshot is not the loss total
The captured address matches the script’s fallback recipient. Its displayed holdings help connect the code to a destination, but a balance combines transfers and changing valuations. It cannot independently establish which deposits came from this attack. Polymarket’s later accounting is a separate, attributed claim.
What the October 30 refund update changes
At 20:07 UTC on October 30, Polymarket reported that 95% of affected wallets had received full refunds. It said eligible wallets were identified from trading and blockchain records, with no claim required for the automatic payment. The $3.9 million includes compensation around the pause as well as drained funds; it is not a $3.9 million theft estimate.
The platform says it removed the script, cleared caches and reset active sessions. These are reported response measures, not our certification of every browser or wallet. The October 29 attack and October 30 reimbursement update should also remain separate from unrelated earlier Polymarket incidents.
If you used the international platform during that window, compare orders, position movements and wallet transfers with your own records. Reach the official status history independently for the payment-review route if an amount appears wrong. Ignore unsolicited recovery messages and never supply a seed phrase to obtain a refund. A familiar domain is a starting point for checking the source, not proof that every dependency it loads is safe.
References
- Polymarket. October 29 security incident and October 30 postmortem. Status history, October 30, 2026; accessed November 1, 2026.
- Hudson Rock Research. Polymarket Breach Alert: Wallet-Draining Code Found in a Third-Party Script. InfoStealers, October 29, 2026.
