Polymarket Script Compromise Turns Browser Sessions Into Wallet Authority

Polymarket says a compromised performance-monitoring script used active browser sessions on its international site to sell positions and move funds from user wallets on October 29. The company removed the script, cleared caches, paused trading and its relayer, reset active sessions, and reopened after containment. Its October 30 postmortem says it is returning $3.9 million: $2.7 million tied to drained wallets and $1.2 million for trading-pause losses.

DebugBear, the performance vendor linked to the incident, says its DNS server records were compromised through its domain registrar and that its initial investigation found targeting of one customer rather than evidence of an internal-system compromise. That remains a vendor assessment while the investigation continues. The practical lesson is broader: JavaScript loaded into an authenticated, transaction-capable page can inherit the authority of the open session. Teams need code integrity, isolation, DNS controls, session invalidation, and transaction-level checks rather than a vendor allowlist alone.

Polymarket's status record says unauthorized activity affected user wallets on October 29. Its postmortem narrows the cause to a third-party performance-monitoring script loaded by polymarket.com. An attacker replaced that script with code built for Polymarket users. For some people who had the site open during the affected window, the code used the active session to sell positions and move funds out of the associated wallet.

The company says it removed the compromised script, cleared every cache, paused trading and its relayer, reset active login sessions, and reopened after the site was clean. The incident record marks the major outage at 37 minutes, although the security window is not defined solely by the outage clock. A browser tab that had already fetched hostile code and a CDN edge that retained it are different response problems from the exchange's visible service state.

Polymarket reports $2.7 million connected to drained wallets and another $1.2 million for losses around the trading pause, for $3.9 million returned to traders. It said 95 percent of affected wallets had been refunded by the afternoon of October 30. Those are company figures, not an independent loss audit. The postmortem does not publish an affected-wallet count, a first-malicious-response timestamp, the attacker's identity, or a complete technical sample.

An external script loaded directly into a page does not stay inside the vendor's security boundary. Unless it is isolated, the browser executes it as part of the embedding page. It can interact with the page's document, application objects, storage, network calls, and any transaction helpers made available to ordinary first-party code. The script URL may belong to a monitoring company, but its effective authority comes from the page that chose to execute it.

That explains why an active session mattered. Polymarket says the attacker used existing sessions to sell positions and move funds. A separate password prompt or phishing page was not required for the confirmed action. The incident therefore sits between conventional account takeover and a protocol exploit: the browser was already trusted, and untrusted code arrived inside that trusted execution context.

The distinction changes user and operator response. Rotating an email password does not remove code that is still loaded in a tab, and revoking a generic token approval may not stop actions authorized through a platform session. Conversely, the official account does not establish that every user wallet key or every Polymarket contract was compromised. Scope the response around the authority available to the affected web session and the transactions that authority could initiate.

Associated Press reporting linked the monitoring service to DebugBear, and DebugBear told Real User Monitoring customers to remove its embed code. In a later company update, DebugBear said its DNS server records were compromised through its domain registrar. It also said the incident affected its ability to receive email at its domain, appeared to target one customer's website, and had not produced evidence of compromise to DebugBear's internal systems at that stage.

That is an important vendor statement, not a completed independent root-cause report. DNS control can redirect a hostname to infrastructure chosen by an attacker. Browser requests, caches, certificates, and monitoring may continue to recognize the expected hostname even though a different system answers. It does not follow that the vendor's source repository, build system, or every customer script was modified. The exact record changes, authentication failure, certificate path, and duration remain unpublished.

For other DebugBear customers, the safe boundary is equally specific. The vendor's removal instruction created a reason to inventory every direct embed, tag-manager rule, single-page application template, and cached bundle that could load its RUM code. The observed payload targeted Polymarket, and DebugBear described a single-customer target, so the public evidence does not establish wallet theft or malicious behavior across its full customer base. Preserve what your own site served before drawing either conclusion.

A site operator should first stop new execution. Remove or disable the vendor include at its source, publish a clean build, purge CDN and application caches, and verify the response from multiple networks and regions. Disable high-risk transaction paths if hostile code may still be active. Invalidate server sessions and relayer credentials that the browser could exercise, then require a clean reload before users regain access.

Preserve evidence before it disappears. Capture DNS history and registrar audit logs, authoritative zone changes, certificate-transparency events, CDN cache and origin logs, response headers, script hashes, tag-manager revisions, deployment records, Content Security Policy reports, session issuance and revocation logs, and application or on-chain transaction records. A copy of the malicious response and its headers can distinguish a code-release problem from redirection at the network or DNS layer.

Affected users should review platform trade history, wallet activity, and reimbursement records through the official status channel. Unexpected position sales, transfers, or session alerts belong in the incident timeline even if funds were later returned. Treat unsolicited recovery messages, support direct messages, or links to claim refunds as a new phishing risk. Polymarket says eligible payments require no claim; only a discrepancy is directed to the review form linked from its status page.

Start by removing third-party browser code from authenticated and transaction-capable pages unless it is necessary there. Performance and analytics collection can often use a controlled first-party collector, server-side integration, or a reduced event bridge. If vendor code must run, place it on a separate origin in a sandboxed iframe and expose only the minimum messages it needs. Isolation is more durable than hoping a large script never touches sensitive application state.

Subresource Integrity lets a browser compare a fetched resource with a cryptographic hash supplied by the page. It is useful when a site can pin an immutable, reviewed file and the vendor supports the required cross-origin behavior. It deliberately blocks unreviewed updates, so teams need a controlled process to test and update the hash. A live vendor URL that changes without a version boundary is incompatible with meaningful integrity pinning.

Content Security Policy still matters, but it solves a different problem. CSP controls which resources a page may fetch or execute and can reduce unexpected destinations. If the policy already allows a vendor hostname, code served from that hostname remains allowed unless integrity, nonces, sandboxing, or application design adds another boundary. Treat script origin, code identity, execution context, and data or transaction authority as separate review questions.

Put domain administration under the same controls as production access. Use phishing-resistant multifactor authentication where the registrar supports it, unique administrator identities, registry or registrar locks for critical domains, restricted change roles, out-of-band change notifications, tested emergency contacts, and zone backups. Keep at least one incident contact outside the affected domain so a DNS or MX change cannot silence the recovery channel. Monitor authoritative records and certificate-transparency logs for unplanned change.

For high-value actions, reduce what a general browser session can do silently. Require a fresh authorization step for withdrawals, destination changes, or bulk liquidation; bind approval to the exact asset, amount, and destination; add velocity and anomaly controls; and let users disable relayed actions. A wallet signature helps only when the user can see and verify the transaction being authorized. A generic session or opaque signature request can preserve the same ambient-authority problem.

Finally, rehearse a client-side supply-chain incident. The runbook should identify who can remove a tag, purge every cache, freeze transactions, revoke sessions, contact the registrar, preserve served JavaScript, compare on-chain and application records, and communicate without loading the suspect dependency. This attack moved quickly because a trusted web dependency sat directly beside transaction authority. Recovery should be designed around that same fact.