TL;DR: Polymarket's October script attack
- Another vendor compromise: On 2026-10-29, a replaced performance-monitoring script used active Polymarket sessions to sell positions and move funds.
- The June precedent: Polymarket disclosed a similar frontend supply-chain attack on 2026-06-25. cside covered the roughly $3 million reportedly stolen.
- Reimbursements: Polymarket announced $3.9 million in refunds for October, including $1.2 million for pause-related losses.
Short on time? See cside client-side security for script monitoring and browser runtime protection.
A performance-monitoring script became a route to users’ funds. Four months after Polymarket’s June frontend compromise, the platform has suffered another attack involving third-party code.
On 2026-10-29, a compromised vendor script used active Polymarket sessions to sell positions and move funds from affected wallets. Polymarket’s 2026-10-30 update put its total reimbursement at $3.9 million, including $1.2 million for losses related to the trading pause. Polymarket’s incident report describes the response and refunds.
For teams running financial applications, the recurring issue deserves attention: third-party JavaScript belongs inside your security boundary.
What happened on 2026-10-29
Polymarket said an attacker replaced a vendor’s performance-monitoring script with code targeting its users. The company removed the script and cleared caches. It also paused trading and its relayer, then reset active login sessions. Its postmortem also described additional integrity controls, monitoring, version pinning, sandboxing, and a stronger Content Security Policy.
The reimbursement figures need care. The $3.9 million announced by Polymarket includes compensation beyond drained funds. Treating that entire amount as money stolen would overstate the reported theft. Source
How monitoring code reached trading authority
Hudson Rock’s technical investigation identified malicious JavaScript served from a DebugBear URL associated with Polymarket’s real user monitoring integration.
The payload read browser-stored account context and searched React’s internal structures for the application’s trading client and signer. Its branches attempted either position-token transfers or position sales followed by transfers of proceeds. It requested signatures and attempted submission through Polymarket’s relayer.
A performance tool was attempting to exercise financial authority inside the page.
Hudson Rock’s analysis did not establish that every signature request succeeded silently. Wallet prompts, session rules, and transaction execution still matter. The researchers also did not identify a routine exfiltrating private keys or seed phrases. The observed approach centered on reusing authority available within the authenticated application. Source
Polymarket had a similar attack in June
We covered Polymarket’s previous client-side supply-chain attack after its 2026-06-25 disclosure. That incident involved a compromised third-party vendor injecting malicious code into the frontend, with roughly $3 million reportedly stolen.
Our June analysis described an approval-phishing flow through the genuine Polymarket interface. The October research describes malicious code seeking the trading client and signer inside an existing session.
| Incident | Reported mechanism | Reported financial impact |
|---|---|---|
| 2026-06-25 | Compromised vendor injects frontend code associated with malicious approval or signature requests | Roughly $3 million stolen, according to our earlier coverage |
| 2026-10-29 | Replaced monitoring script abuses active sessions; researchers identify trading and signing logic | Polymarket announces $3.9 million in reimbursements, including pause-related compensation |
The shared pattern is third-party code reaching a sensitive financial workflow. That similarity does not establish the same attacker, vendor, or initial compromise method.
What application teams should change
The practical question for a security review is whether a monitoring integration can reach capabilities far beyond its intended job.
Start by reducing third-party execution on authenticated trading and signing pages. Require a clear business reason for each integration, an owner, and a removal procedure. Review the boundary around signing authority and decide which actions require fresh, explicit confirmation.
For dependencies that can be pinned, use Subresource Integrity. SRI lets the browser compare a fetched file against an expected cryptographic hash and reject a mismatch. Cross-origin deployments require appropriate CORS support and a controlled process for approved updates.
Also preserve the script contents delivered to users. An incident investigation needs evidence of what executed, when it changed, and which sessions could have received it.
Where cside fits
cside provides browser runtime visibility, script inventory, payload history, and detection of malicious script behavior. Those capabilities help teams investigate changes to code executing in customer sessions. Explore cside client-side security.
The June and October incidents make the priority concrete: review the code you permit to run beside your most sensitive workflows, constrain its authority, and continuously verify what reaches users.
