Polymarket's postmortem traces account drains to a vendor script

Polymarket's October 30, 2026 postmortem traces the previous day's account drains to a compromised vendor script that used some users' active sessions. The incident illustrates why the code a trading website loads is part of the security of its logged-in workflow.

WIRED's originating report, published October 29, covered the temporary halt and reopening of international trading. It reported that the separate Polymarket US platform was unaffected. The later official postmortem adds the mechanism and reimbursement basis.

A vendor's code reached an active trading session

According to Polymarket, an attacker replaced a performance-monitoring script. For some people with the site open during a short window, that script used their session to sell positions and move funds.

The relevant boundary is what external code can do after the website loads it. OWASP's third-party JavaScript guidance explains that such code can execute with the host application's privileges. A change at the vendor can therefore change the application that the user receives, even without a corresponding release by the website operator.

That is a browser-integration problem with implications for account actions. It does not, by itself, establish a failure of a blockchain protocol or identify how the attacker first compromised the vendor.

Containment and reimbursement need separate evidence

Polymarket says it removed the script, cleared caches, reset active login sessions and paused then restored trading. It also described additional integrity controls and monitoring being deployed.

In the October 30 update, the company set out $3.9 million in reimbursements: $2.7 million plus $1.2 million for pause-related losses. The total therefore should not be described as the amount directly drained by the attacker. The post says eligible wallets were identified automatically and provides a route to question an amount.

For affected users, comparing the account's transactions and reimbursement record with that explanation is more useful than treating a restored service as proof that an individual balance has been reconciled.

Evaluate the controls around the page

For developers, OWASP describes integrity checks that reject changed script bytes and isolated frames that limit a vendor script's access to the main page. These controls address different parts of the integration and require maintenance as code changes.

The practical design question is which third-party code needs access to an authenticated workflow and how changes to it are reviewed. Polymarket's stated response is evidence of what the company reports doing; it is not an independent audit of every deployed control.

Sources

• Polymarket's October 30 postmortem

• WIRED's October 29 report

• OWASP's third-party JavaScript guidance