Cybersecurity Data Breach

Polymarket’s Third-Party Breach: How Malicious Scripts Drained Wallets and What Traders Should Do Next

illustration of malicious script draining crypto wallet from a trading page

Polymarket suffered a security incident on October 29, 2026, when a compromised third‑party provider exposed international users to wallet theft. Traders reported missing funds, unexpected withdrawals, and positions being closed without permission. The company temporarily halted trading, said it fixed the issue, promised reimbursements for affected customers, and later resumed trading.

What happened

Hudson Rock’s technical investigation and subsequent reporting tied the incident to malicious JavaScript delivered through an address associated with a third‑party monitoring vendor. Early corporate statements only said an outside provider was compromised and referred the matter to law enforcement; later reporting connected the event to DebugBear, though Polymarket’s public statement did not name the vendor. The company also said the separate United States platform was not compromised.

How the malicious script operated

Investigators found code that did more than measure page performance: it searched for active trading sessions, read browser storage for account details and API credentials, and attempted to locate Polymarket’s live trading client and its signer—the tool that authorizes wallet actions. Rather than relying solely on stolen passwords, the script attempted to reuse access already present inside logged‑in sessions. Behavior varied by account type: one route tried to transfer position tokens directly, another attempted to sell positions before moving funds, and there were requests for signatures and transaction submissions through Polymarket’s relayer. Researchers downloaded identical copies of the malicious file; they did not execute samples, so the findings describe intended behavior rather than proof every attempted transfer succeeded.

Scale and reported losses

CNBC cited analysis from Betting Intelligence and Polysights linking at least $2.7 million in withdrawals to 710 wallets; these figures are outside estimates and not an official total. Traders reported a range of impacts, and Polymarket said it would make affected users whole. CNBC reported that users with under $10,000 stolen were told their funds would be restored by October 30, while larger claims required a release form. The precise exposure window and initial method used to compromise the provider remain unresolved.

Polymarket’s response and law enforcement

Polymarket temporarily stopped trading to mitigate further damage, issued public statements acknowledging the third‑party compromise, and promised reimbursement for affected users. The company referred the incident to law enforcement. Trading resumed after the company said it had fixed the issue; the public timeline for remediation and the full scope of reimbursements were still being clarified in early reporting.

Practical steps for exposed users

Security researchers and industry coverage recommend immediate, practical actions for anyone potentially affected:

  • Close any potentially exposed browser tabs and sessions.
  • Review recent orders and wallet transactions through trusted channels and save transaction hashes for support claims.
  • Reject unexpected signing requests and avoid unsolicited recovery links.
  • Review active sessions and permissions with official support, and verify any compensation instructions through official company channels.
  • Never share a seed phrase. Disconnecting a wallet may stop further automatic interactions but does not reverse completed transfers or remove existing blockchain approvals.

Broader context and lessons

This incident echoes prior supply‑chain compromises—such as an Adform breach that distributed crypto‑stealing code and a compromised XRPL JavaScript package—that demonstrate how trusted infrastructure and third‑party scripts can become delivery routes for theft. The Polymarket episode underscores the particular danger of outside scripts running on pages where users sign transactions: once an attacker can execute code in an active session, they can attempt to reuse the browser’s own authorizations rather than bypass authentication entirely. As automation and AI speed up attack capabilities, the episode reinforces the need for platforms to scrutinize third‑party dependencies, limit what external scripts can access, and provide clear, rapid support and remediation paths for affected users.

Leave a Reply

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

🧰

Free Tools: IP, DNS, SSL

40+ free network and other tools in one place. No signup. Click explore or visit https://technochat.in/tools

Explore