A page-speed script became a way into traders’ wallets

On 29 October, an attacker replaced a performance-monitoring script loaded by Polymarket with code aimed at its users. Polymarket says the script used some active sessions to sell positions and move funds. The company removed the script, cleared caches, reset active logins and briefly paused trading and its relayer. In its 30 October report, it said it was returning $3.9 million to traders: $2.7 million connected to the attack and $1.2 million for losses around the trading pause.

Hudson Rock captured the suspicious script and found logic that searched the live page for trading and signing functions. Ohey separately analysed the script and traced funds to the recipient wallet. These findings explain how a monitoring integration could become a transaction path; they do not establish that every open session was affected.

1. 1

   Map scripts on sensitive pages. List outside JavaScript on authenticated account, payment and signing flows. Ask whether each integration needs to execute there at all.

2. 2

   Constrain what remains. Use version pinning and Subresource Integrity where the delivery model supports them, backed by a restrictive Content Security Policy. Review whether page code can invoke a signer or other high-impact action without a fresh user check.

3. 3

   Preserve the delivered file. If a provider is compromised, save the exact response bytes, hashes, request timestamps, cache records and affected sessions before the CDN content changes. Then review user actions and invalidate sessions or authorizations supported by the evidence.

The key question is not whether the script came from a familiar hostname. It is what code the browser actually received and what that code could do inside an authenticated session. Put that question on the checklist for every high-value page.