Third-Party Script Attack on Polymarket: How a Hijacked Monitoring File Drained 700 Wallets

On 29 October, a third-party script attack hit Polymarket, the prediction market where people bet on real-world events. Code that ran on the site’s pages emptied the accounts of hundreds of traders in under an hour. Polymarket now puts the theft at about $2.7 million and is refunding the victims.

What happened to Polymarket

Polymarket loaded a small monitoring script from DebugBear, a UK website performance firm. Sites use this kind of real user monitoring code to see how fast pages load for visitors. On the day, the file served from DebugBear’s address was not the usual one. Researchers at Ohey measured the clean file at 60,493 bytes and the file that replaced it at 15,187 bytes.

The first stolen funds reached the attacker’s wallet at 17:10 UTC. The last arrived at 18:02 UTC. In that window the attacker collected roughly 28.6 million POL tokens plus trading positions from 33 wallets. Polymarket ended the attack by pushing a release at 17:59 UTC that removed the DebugBear script, and trading resumed about an hour after it paused.

How the third-party script attack drained accounts

The code did not need to steal a password. According to Hudson Rock’s analysis, it read the login details already stored in the trader’s browser, then searched the page for Polymarket’s own trading client and its signer. It then asked that signer to approve transfers.

What happened next depended on the account type. Wallet-based accounts had their positions moved straight to the attacker. Email-based accounts had their positions sold at steadily worse prices, with the proceeds sent on. Hudson Rock found no code that sent passwords, keys or seed phrases off to a server. The script simply borrowed the authority that a signed-in session already had.

How the vendor was breached

This part is still murky. Polymarket said only that one of its third-party providers was compromised. DebugBear later said its DNS records were taken over through its domain registrar, according to The Hacker News. It said it had no sign of a break-in to its own systems and told customers to remove its embed code. Hudson Rock found no sign that other DebugBear customers were targeted.

That detail matters. Polymarket’s own code was not changed. The attacker went after the supplier, and the supplier’s address did the rest.

The cost of the script compromise so far

Polymarket says 689 of 726 affected wallets had been repaid in full by 30 October. It is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause. The total comes to about $3.9 million. SecurityWeek notes that outside loss estimates differ, and that the platform already lost about $3 million to a separate third-party compromise in June.

What this means for your business

You may not run a crypto exchange, but you almost certainly load code you do not control, so a third-party script attack could reach you too. Analytics, chat widgets, payment forms and tag managers all run with the full privileges of your page. If one of them changes, so does your site.

Hudson Rock puts it well: “A legitimate vendor hostname alone is an unreliable maliciousness test.” A rule that allows a trusted domain does not check what that domain serves today. Polymarket says it will add a stronger Content Security Policy, pinned versions and sandboxing for third-party scripts.

• List every external script on pages where customers log in, pay or approve actions.
• Remove anything you do not need on those pages.
• Use Subresource Integrity where a file can be pinned, so a swapped file fails to load.
• Tighten your Content Security Policy to the exact hosts you need.
• Check which actions need a fresh confirmation from the user, and whether page code can reach them.

A tester will check for a third-party script attack the way a real attacker would. Our software supply chain defence checklist is a good place to start. If you ship a product, the guide to penetration testing for SaaS shows how a test treats these paths. Online shops face the same exposure at checkout, which the ecommerce penetration testing guide covers.

The wider point

A third-party script attack scales, which is why attackers like it. One compromised supplier gives them a foothold on every site that trusts it. Polymarket was the target this time, but the same trick works on a bank, a retailer or a charity donation page. Polymarket also lost about $3 million to a different supplier compromise in June, so a single fix does not end the risk.

Every site that loads outside code has the same exposure, and it needs the same discipline. Treat each external file as part of your own code. Then ask what happens on the day it changes without telling you.