Polymarket Lost $2.7 Million Through a Page-Speed Script. The Weak Point Was a Vendor's Domain Registrar.
On October 29, a script that Polymarket loads from a website-monitoring vendor was replaced with malicious code. It ran inside signed-in traders' browsers and moved funds out of 726 wallets. Polymarket's own servers were not reported as breached. The vendor says its DNS records were changed through its domain registrar.
No indicator in this incident is something a network blocklist can use, and we hold none. The useful part for defenders is the list of what would have limited it.
What was reported
DebugBear sells a real user monitoring tool that measures page load speed for real visitors. Polymarket's site loaded one of its scripts. Earlier that day the script had been served from Google Cloud Storage. According to Ohey, a blockchain tracing firm, at 18:13 UTC a different server was answering for DebugBear's web addresses while the malicious file was still online.
DebugBear said its DNS records were compromised through its domain registrar and that it has reported no break-in to its own systems, though its investigation was ongoing. It said early findings indicate the attack targeted one customer's website, which was Polymarket's copy of the script. On November 1, The Hacker News confirmed that cdn.debugbear.com had no DNS record.
Hudson Rock downloaded the malicious file on October 29 and read it without running it. In its account, the code read account details stored in the browser, including a set of trading API keys, then searched the page for the order placement code and the transaction signer. For accounts using a crypto wallet, positions were moved straight to the attacker's wallet. For accounts using email login, positions were sold at progressively worse prices and the proceeds moved out. In both cases the code asked the account's signer to sign requests and submitted them through Polymarket's relayer. Hudson Rock found no code sending keys, passwords, seed phrases or private keys to a server, and notes that the API keys alone cannot place orders without a wallet signature.
The attacker wallet on Polygon is 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. Ohey traced 28.6 million POL, worth about $2.64 million at the time, plus positions from 33 wallets. All the POL was forwarded to three other addresses between 18:28 and 18:38. The Hacker News reported no attribution. Polymarket said it referred the case to law enforcement.
The cost to traders so far
Polymarket reported 726 affected wallets and refunds of about $2.7 million, with 689 refunded in full by October 30 and the other 37 being paid as they are checked. It also paid $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken. The total returned is $3.9 million.
What would have limited it
These are our suggestions, not findings from the reports above.
Keep third-party scripts off pages that sign things. A monitoring script has no reason to run on the page where a user approves a transaction. Serve monitoring from a separate origin or a separate page, or load it only on pages with no signing authority.
If you must load a vendor script on a sensitive page, pin it. Subresource Integrity makes the browser refuse a script whose bytes changed. It does not suit scripts the vendor updates often, which is itself a reason to host a pinned copy yourself.
Treat your vendors' domain registrars as part of your attack surface. Ask each vendor whose script you load whether its domains have registry lock and hardware-key authentication at the registrar. This incident is a registrar compromise, and nothing on Polymarket's side could have seen it.
Watch the DNS of the vendor hosts you load. A change in where a script host resolves, or in the file's hash, is a signal you can check from outside your own network.
Use a content security policy that lists exactly which hosts may run script on signing pages, and report violations. It will not stop a trusted host that has been hijacked, but it narrows what else can be pulled in.
For traders: a pause in trading and an unexplained position change are the cues. Revoke API keys on your account and review wallet permissions after any incident like this one.
What we hold, and what we don't
We hold nothing from this incident in our feed. The reports publish no IP address, file hash or malware name. We did not ingest cdn.debugbear.com: it is a hijacked vendor domain, a victim, and blocking it would cut off a legitimate service that now has no DNS record at all. Our feed also does not carry wallet addresses as an indicator type, so the attacker wallet above is here for readers who track one by hand.
We wrote about two earlier Polymarket incidents that also went through somebody else's security, including Polymarket Got Robbed Through Somebody Else's Security, Twice in a Month. This one has the same shape, with the weak point one step further out, at the vendor's registrar.
Limits
This post rests on The Hacker News' November 1 report and the Hudson Rock, Ohey, DebugBear and Polymarket statements it cites. We did not independently verify any on-chain movement, did not download the malicious file, and have not read DebugBear's statement ourselves. DebugBear's investigation was ongoing, so the registrar finding may change.
Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments