On 29 October 2026, a performance-monitoring script supplied by a service provider and loaded on polymarket.com was replaced with malicious code. It used the sessions of users who had the site open to sell their positions and move funds out. Polymarket says it is returning $3.9 million in total and has tightened control of its third-party scripts.
What happened
In a post-mortem published on 30 October 2026, the prediction market Polymarket explains that it detected unauthorised activity on user wallets on 29 October at 17:38 UTC. The cause was not its own code: a provider whose performance-monitoring script was loaded on polymarket.com had been compromised, and the attacker swapped that script for one aimed at Polymarket users. For some people who had the site open during a short window that afternoon, the script used their active session to sell positions and transfer funds out of their wallets.
Polymarket says it is paying back $3.9 million in total: $2.7 million for the theft and $1.2 million for losses caused by the trading pause. When the post-mortem was published, 95% of affected wallets had been refunded in full. The company has not said how many users were hit, and has referred the case to law enforcement.
How the attackers got in
The site trusted the provider’s domain, so browsers ran whatever that domain served. According to an analysis by Hudson Rock, the site’s Content Security Policy allowed that host; the malicious script read authentication data stored in the browser, located the trading client in the page, then requested signatures and submitted transfers to an address controlled by the attacker. According to The Record, the provider said its first findings point to a compromise through its domain registrar.
What to do now
- List the external scripts on your sites, for example with
curl -s https://www.example.com/ | grep -oE 'src=[^ >]+', and remove those nobody needs, starting with login, payment and account pages. - Pin and verify what remains: host a fixed version yourself, or add Subresource Integrity to files that do not change (hash generated with
openssl dgst -sha384 -binary file.js | openssl base64 -A), so that a modified file is refused. - Tighten the Content Security Policy: precise
script-srcandconnect-srclists, with violation reporting enabled. Allowing a host does not check what it serves. - Monitor changes: hash third-party files regularly and raise an alert on any change.
- Prepare the response: be able to pull a script and reset all sessions within minutes, as Polymarket did.
- Protect your own domains: multi-factor authentication and registrar lock on your registrar accounts.
Our take
A script loaded from another domain runs with the same rights as your own code, inside your customers’ sessions. An analytics or monitoring tag is rarely treated as critical, yet here it was enough to empty accounts. Fewer third-party scripts, pinned versions and integrity checks cost little compared with a refund in the millions.
Sources
- Polymarket Status — Post-mortem of the 29 October 2026 incident
- The Record — Polymarket pledges to give $3.9 million back to victims after site compromise
- The Record — Polymarket confirms cyberattack involving third party
- Hudson Rock (Infostealers) — Polymarket breach alert: wallet-draining code found in a third-party script
How we choose, verify and write our analyses →
The way in was a third party. Check what your suppliers expose publicly — no intrusion, public information only:
Worried your servers are exposed? Our team audits, patches and monitors Linux and cloud infrastructure 24/7.
Talk to an expert Our managed server services →
