Polymarket restored trading on Oct. 29, after a compromised third-party provider disrupted its international prediction market.
The earlier website-script attack on June 25 reportedly drained about $3 million. The recurrence raises a security question about how much financial authority outside code can reach inside a trader’s browser.
Its official incident record records trading restrictions from 18:05 UTC and resolution at 19:05 UTC. Polymarket said it had fixed the issue, referred it to law enforcement, and would make affected users whole.
The issue extends beyond replacing a compromised supplier, since separate investigations describe malicious code reaching for financial functions inside the website. June’s reported route relied on approved authorizations, while October’s code searched for trading tools and requested signatures.
Two scripts, different routes to users’ assets
On June 25, Polymarket disclosed a malicious script injected through a compromised vendor. In its Source Defense investigation, it said the affected dependency had been removed, and users would receive full refunds.
Source Defense reported that roughly $3 million was drained, tracing the delivery chain through a marketing tag that loaded an external identity library, which the attacker replaced with a Polymarket-specific drainer.
The June payload selected wallets worth more than $100,000 and repeatedly requested a digital authorization, according to the researchers. Once approved, that authorization went through Polymarket’s own relayer, the infrastructure that submits signed actions.
October’s recovered code searched for trading tools inside a logged-in session. Hudson Rock’s analysis describes a script retrieved from a DebugBear-associated URL searching for the live trading client and its signer, the component used to request cryptographic authorization.
The script was programmed for different actions depending on account type: requesting position-token transfers in one branch, or sales and proceeds transfers in another. Hudson Rock also found production-build metadata recording removal of the DebugBear monitoring script.
Hudson Rock’s static review left execution, silent signatures, private-key theft and a complete victim-to-recipient trail unproven. The removal metadata also leaves the exact end of users’ exposure unresolved.
Blockchain analytics firm Bubblemaps estimated that more than 700 Polymarket users were affected by the Oct. 29 breach, with approximately $3.46 million in assets compromised.
Attackers converted roughly $2.7 million into POL and transferred it out, while another $750,000 remained on Polymarket at the time of the assessment.
Where outside code meets trading authority on Polymarket
MDN’s browser documentation explains that a third-party script included directly in a page can access the page’s other scripts and data. Hosting the file elsewhere alone leaves that access intact, while cross-origin content embedded in a separate frame has a different security boundary.
June’s marketing dependency and October’s monitoring-associated script were different delivery routes into a sensitive interface.
Reducing outside code, constraining signing requests, and verifying downloaded files address separate points in that chain. Removing unnecessary integrations from trading and signing pages reduces the code admitted to that environment. Reviewing signer access and which actions require fresh user confirmation limits what code can request once it is there.
Subresource Integrity lets a browser compare a downloaded script with an expected cryptographic fingerprint and reject changed contents. It can also protect a suitably pinned resource even when its hosting domain is trusted.
A detailed postmortem explaining the exposure window, affected accounts, and authorization paths would make the remaining risk easier to assess. The unresolved test is whether another compromised integration could turn access to the trading interface into usable financial authorization.
