Polymarket Supply Chain Attack: Tampered Monitoring Script Abuses Active Sessions to Move Funds

1. Basic Information

• Article Name: Security incident - 3rd party vendor compromised
• Publisher: Polymarket
• Publication Date: 2026-10-30T20:07:00Z
• Original: Polymarket
• Related Source: SecurityWeek
• Related Source: Report URI analysis
• Related Malware: Tampered performance-monitoring JavaScript
• Related Threat Group: None specified
• Related CVE: None specified
• Related Products: Polymarket.com, DebugBear RUM
• Severity: critical

2. Brief Summary

A third-party performance-monitoring script loaded on Polymarket was tampered with, leading to unauthorized position sales and fund transfers from wallets using active sessions of some users within a short timeframe.

3. Attack Flow

From Monitoring Script to Fund Transfer

1. An attacker compromises a third-party monitoring vendor and replaces the delivered script.
2. The malicious script runs in the browser of a user who opens the legitimate Polymarket.com.
3. It uses active sessions to sell positions and transfer funds from the wallet.

4. Attacker Position and Execution Location

• Controls the delivery path of the third-party script and reaches user sessions on the legitimate site origin.

5. Visibility for Victims and Administrators

Victims

• Observed as unintended position sales and wallet transfers while using the legitimate Polymarket site.

Administrators

• Observed as changes to third-party script content, anomalous session actions, concurrent wallet transactions, and relayer activity.

6. Success and Failure Conditions

Success Conditions

• The target site is opened during the compromise window, and an active session exists in the browser.
• The malicious script is not blocked by CSP or other controls and reaches the session privileges required for transaction operations.

Failure Conditions and Mitigations

• Subresource Integrity (SRI) using trusted hashes prevents the execution of modified scripts. When an approved delivery source is compromised, URL or version pinning and CSP source allowances alone cannot prevent the attack. Sandboxing must also isolate transaction privileges and session access.
• Session resets and halting trading or relayers mitigate ongoing drains.

7. Outcomes upon Success

• Unauthorized position sales.
• Fund transfers from wallets.
• Service suspension, user compensation, and loss of trust.

8. Observable Logs

• Email: None specified
• Proxy / SWG / DNS: Third-party script requests initiated by polymarket.com, changes to script content hashes, and browser traffic to unknown destinations.
• Endpoint / EDR: Browser history, cache, loaded scripts, and artifacts of page script execution rather than browser extension execution.
• Identity / IdP: Anomalous actions per session ID, session resets, and IP or device mismatches.
• SaaS / Cloud: Changes to third-party script configurations or deployments, CDN caches, and build diffs.
• Network: Timelines of script fetches, API requests, relayer actions, and wallet transactions.

9. Attack Success Determination

• Information theft or session compromise confirmed: Public info: Polymarket confirmed position sales and fund transfers using active sessions. Individual organizations match transaction IDs with session actions. (Scope: Polymarket web session and wallet)

10. Investigation Playbook

• Trigger: Suspicious position sales, wallet transfers, or third-party script changes.
• Initial checks: Verify usage times, sessions, wallet addresses, transaction IDs, and script hashes.
• Endpoint: Preserve browser cache/history and loaded resources as much as possible.
• Identity / Cloud: Check session actions, IP/device, logins, and API/relayer operations.
• Follow-on: Track other wallets, token approvals, credential reuse, and additional transfers.
• Containment: Revoke sessions, remove scripts, stop relayers, protect wallets, and execute necessary compensation procedures.
• Classification: Determine script execution, session abuse, position sales, and on-chain fund transfers in separate stages.

11. Defense and Detection Ideas

• Single event: Detect changes to allowed script hashes, hosts, or versions.
• Timeline correlation: Correlate session actions and wallet transactions immediately following script changes.
• Hunting: Inventory all third-party scripts, CSP allowed sources, SRI status, and dynamic loaders.
• Logging gap: Without saving browser-side resource contents, it becomes difficult to reproduce individual impacts.
• Priority controls: Prioritize SRI, strict CSP, version pinning, sandboxing, and session revocation drills.

12. Facts / Inference / Hypothesis

Facts

• Polymarket stated that a third-party vendor's performance-monitoring script was compromised, and attackers replaced it with a script targeting Polymarket users.
• For some users who opened the site within a brief window, positions were sold using active sessions and funds were moved from wallets.
• Polymarket removed the script, cleared caches, halted trading and relayers, reset active login sessions, and resumed service after confirming the site was clean.
• As preventive measures, they listed a stronger CSP, explicit version pinning, sandboxing, and continuous integrity verification.
• Polymarket's October 30 postmortem stated they will refund a total of $3.9 million, combining $2.7 million in compensation for thefts and forced sales caused by the attack and $1.2 million for losses related to trading suspensions. The full $3.9 million is a refund and compensation total, not the amount stolen.

Inference

• The core issue appears to be active web session abuse rather than wallet private key theft, but official information does not fully clarify individual wallet authorization and signing paths.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Unknowns and Limitations".

13. MITRE ATT&CK Mapping

14. Unknowns and Limitations

• The attacker, vendor compromise vector, number of targeted users, and full scope of session abuse remain undisclosed. The total refund amount includes compensation for trading suspensions, so it should be distinguished from the stolen amount.

15. Impact on SOCs and Organizations

Web3 and financial sites should inventory third-party RUM and analytics scripts, and review SRI, CSP, version pinning, sandboxing, and session revocation procedures. Even JavaScript from legitimate domains requires monitoring as a trust boundary.

16. Summary by Target

• SOC: Correlate third-party script hash changes, session operations, and wallet transactions chronologically.
• Administrators: Pin and isolate external scripts, and establish session resets and integrity monitoring.
• Users: If you used the service during the affected time and notice suspicious transactions, terminate sessions and contact official support.