Press ESC to close

Polymarket’s Provider Postmortem Connects Session Security With Trading Recovery

Polymarket’s October 30 postmortem identifies a compromised third-party monitoring script as the source of unauthorized activity reported the previous day. The account connects website session security with trading controls, showing how an application dependency can affect several parts of a customer’s experience.

TL;DR: Polymarket says it removed the script, reset sessions and paused trading and relayer operations. It also reported that 95% of affected wallets had been refunded in full by the afternoon of October 30.

The postmortem identifies the affected trust boundary

In its official incident account, Polymarket says an attacker replaced a vendor’s performance-monitoring script with code that used some visitors’ active sessions to sell positions and move funds. It says the vendor publicly confirmed the compromise.

The company describes removing the script, clearing caches and resetting login sessions. It also lists additional integrity and monitoring controls for third-party scripts. These are the platform’s account of the incident and its response, rather than an independent technical audit.

The trust-boundary lesson is concrete. A script added to observe application performance can still execute inside a sensitive user experience. Evaluating such a dependency requires attention to what it can do in that context, as well as the business purpose for which it was originally installed.

Component notices describe different operational states

A separate trading and relayer entry in the status history records cancel-only trading and paused relayer actions. Its timestamps describe that operational notice and should not be treated as the full duration of the attack or every affected service.

Allowing cancellation while restricting new orders can reduce outstanding exposure without restoring normal market activity. That is a different state from a website being unavailable, and different again from login sessions being reset.

Polymarket’s trading documentation describes authenticated order submission. During recovery, a connected application needs to establish whether a request was accepted, rejected or still awaiting a definitive result. A lost connection does not establish an order’s final state.

Position actions require their own recovery checks

The platform’s position-management guide covers splitting collateral into outcome tokens, merging complete sets and redeeming winning positions. These operations are distinct from placing an order, and the documented integrations include relayer authentication.

That separation explains why an incident notice can mention both trading and relayer controls. Different components support different stages of the user’s activity. Restoring an order interface does not by itself prove every position-management route is ready.

For an illustrative user trying to redeem a resolved position, a generic message that trading is available would be incomplete. The relevant evidence is whether redemption can be submitted and confirmed. Precise service labels help users understand which action remains restricted and prevent repeated attempts based on an ambiguous recovery announcement.

Refund reporting needs a date and a defined scope

Polymarket’s postmortem says it is returning $3.9 million, including $2.7 million and another $1.2 million covering pause-related losses. The reported 95% wallet-refund figure is explicitly tied to the afternoon of October 30; it should not be rewritten as a claim that every refund is complete.

For customers, a remediation update is most useful when it identifies the eligible events and explains how disputed amounts will be reviewed. For operators, the associated records need to connect affected sessions, trading actions and final account outcomes.

The available account provides more detail than the initial outage notice, while leaving room for further verification of the controls and remediation. Its practical implication is that session security, trading restrictions and customer reconciliation need to be designed together. A platform’s recovery is clearest when each action has an explicit state and a verifiable result.

Written by the News Desk and edited by Samuel Rae.

Leave a Reply

Your email address will not be published. Required fields are marked *