Overview
Follow-up details have emerged on the October 29 Polymarket incident, in which malicious JavaScript loaded on the prediction market's site sold some signed-in traders' positions and moved the proceeds to attacker wallets. The code had replaced a page-speed script Polymarket loads from analytics vendor DebugBear.
New this week: DebugBear says its DNS records were compromised through its domain registrar, and Polymarket has detailed a $3.9 million compensation program.
What Happened
All times UTC, October 29:
| Time | Event |
|---|---|
| 17:10 | First stolen funds reach the attacker wallet |
| 17:38 | Polymarket posts its first status update on unauthorized wallet activity |
| 18:02 | Last funds arrive at the attacker wallet |
| 18:05 | Exchange set to cancel-only mode; relayer actions paused |
| 18:13 | Researcher Ohey observes a different server answering for DebugBear's domains while the malicious file is still online |
| 18:28–18:38 | POL moved onward to three other addresses |
About 28.6 million POL (roughly $2.64 million) reached the attacker's wallet in under an hour, from 33 wallets, excluding positions that were taken.
Technique
The script ran inside an already-open, signed-in Polymarket page and reused the trader's session. It read account data stored in the browser, including trading API keys, and located the order-placement code and transaction signer.
- Wallet-login accounts: positions were transferred directly to the attacker's wallet.
- Email-login accounts: positions were sold at progressively worse prices, then funds were moved out.
Requests were signed by each account's own signer and submitted through Polymarket's relayer. Hudson Rock found no code sending API keys, passwords, seed phrases, or private keys to an attacker server.
DebugBear's Account
DebugBear provides a real user monitoring (RUM) script. The company says:
- Its DNS records were compromised through its domain registrar.
- It has seen no sign of a breach of its own systems, though its investigation continues.
- Early findings suggest only one customer's site was targeted. Each customer loads its own copy of the script, and the swapped file was Polymarket's.
- It has told RUM customers to remove its embed code.
Polymarket's Response
- Removed the script within the hour, cleared caches, reset active login sessions, and paused trading until the site was clean.
- Referred the case to law enforcement.
- Refunding about $2.7 million to 726 wallets; by October 30, 689 were fully refunded and the remaining 37 were being paid after verification.
- Paying a further $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken, for a total of $3.9 million. No claim is required; a form on its status page covers disputed amounts.
- Plans to restore third-party scripts only with stronger Content Security Policy, pinned versions, and sandboxing.
Indicators of Compromise
- Attacker wallet (Polygon):
0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18 - Malicious file source:
cdn.debugbear[.]com(no DNS record as of November 1)
Recommendations
For sites that load third-party scripts:
- Keep unneeded third-party code off pages where users trade or sign transactions.
- Use Subresource Integrity (SRI) where files can be pinned, so browsers reject altered files.
- Do not rely on a CSP that simply allows a trusted CDN; it will not catch changes to files that CDN serves.
- Audit what code on signed-in pages can ask a wallet signer to act.
- Enable registrar locks, MFA, and change alerts on vendor-facing domains you control.
For traders: reject any signing request you did not expect.