Polymarket has suffered its second multimillion-dollar security breach in just four months, and the details should make every prediction market trader pay closer attention to what runs inside their browser. Trading was restored on October 29 after a compromised third-party provider disrupted the platform, but the incident record tells only part of the story. Investigators now describe malicious code that reached directly for the financial machinery inside Polymarket’s own website.
What happened on October 29
According to Polymarket’s official incident record, trading restrictions began at 18:05 UTC on October 29 and were resolved about an hour later, at 19:05 UTC. The company said it had fixed the issue, referred the matter to law enforcement, and would make affected users whole. Blockchain analytics firm Bubblemaps estimates that more than 700 Polymarket users were affected, with approximately 3.46 million USD in assets compromised. Attackers converted roughly 2.7 million USD into POL and moved it out, while another 750,000 USD remained on the platform at the time of the assessment.
June was the warning shot
The earlier attack hit on June 25, when Polymarket disclosed a malicious script injected through a compromised vendor. According to an investigation by security firm Source Defense, roughly 3 million USD was drained. The delivery chain ran through a marketing tag that loaded an external identity library, which the attacker replaced with a Polymarket-specific drainer. The payload was selective: it targeted wallets holding more than 100,000 USD and repeatedly requested a digital authorization. Once a user approved it, the authorization was executed through Polymarket’s own relayer, the infrastructure that submits signed actions. At the time, Polymarket said the affected dependency had been removed and affected users would receive full refunds.
October’s code went hunting for the trading client
The October breach followed a different path to the same destination. An analysis by Hudson Rock describes a script retrieved from a URL associated with the monitoring service DebugBear that searched for the live trading client and its signer, the component used to request cryptographic authorization from users. The script was programmed to behave differently depending on the account type: one branch requested position-token transfers, while another handled sales and the transfer of proceeds.
Hudson Rock also found production-build metadata recording the removal of the DebugBear monitoring script, but its static review left key questions open. Execution, silent signatures, private-key theft, and a complete victim-to-recipient trail all remain unproven, and the removal metadata makes it hard to pin down exactly when user exposure ended.
Why third-party scripts are such a stubborn problem
The uncomfortable truth is that both attacks exploited a basic property of the modern web. As browser documentation explains, a third-party script included directly in a page can access the page’s other scripts and data. Simply hosting the file elsewhere does not change that access; only cross-origin content embedded in a separate frame gets a different security boundary. June’s marketing dependency and October’s monitoring-associated script were different delivery routes into the same sensitive interface.
Security engineers point to several layers of defense. Removing unnecessary integrations from trading and signing pages shrinks the amount of code admitted to the environment in the first place. Reviewing signer access and requiring fresh user confirmation for sensitive actions limits what rogue code can request once it is there. Subresource Integrity, a browser feature that compares a downloaded script against an expected cryptographic fingerprint and rejects changed contents, can protect a pinned resource even when its hosting domain is trusted.
What traders should actually do
For everyday users, the practical lessons are straightforward. Treat any unexpected signature request as hostile, especially if it appears without an action you explicitly initiated, because approving a malicious authorization is exactly how the June attack monetized access. Consider using a dedicated browser profile or separate wallet for prediction market activity, so that a compromised script on one site does not sit in the same environment as your larger holdings. And if a platform you use suffers this kind of incident, watch for a detailed postmortem, because an explanation of the exposure window, affected accounts, and authorization paths is what makes the remaining risk possible to assess.
The unresolved question hanging over Polymarket is whether another compromised integration could again turn access to the trading interface into usable financial authority. Until the platform demonstrates that outside code can no longer reach its signing flows, four months between multimillion-dollar incidents is a pattern, not a coincidence.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice.
2.7M already rotated into POL and moved off platform. that money is gone, whatever refund process they promise
script pulled from a DebugBear url too, thats a perf monitoring domain nobody blocklists. clever and gross
Third party marketing tags with wallet context loaded at runtime is the structural problem. Subresource integrity everywhere or self host, no middle ground left.
the June one came through a browser angle, this one hunted the trading client signer. two different entry points in four months is the part that gets me
700 users and 3.46 million USD gone in roughly an hour of downtime. Second time in four months after June 25. At some point you have to question the whole third party script model.
The 2.7 million already rotated into POL and moved out is the painful part. The 750k still on platform is the only chunk they can realistically claw back fast.
Questioning the model is right but the alternative is shipping a slower front end with zero vendor scripts, and every product team chose speed. Twice burned in four months tho. Users will demand the boring version now.
The June drainer came through a marketing tag loading an external identity library. If your front end pulls vendor code at runtime, no audit of your own code saves you.
The scariest detail is the relayer. The payload asked for an authorization and executed it through the Polymarket relayer itself, so users thought they were confirming a normal trade.
The relayer detail is what should scare people. You approve what looks like a trade and the authorization does something else entirely. Hardware wallets do not save you from blind signing.
And it only fired for wallets above 100k. Selective targeting so the whales would not flood support and tip everyone off sooner.
Trading halted 18:05 UTC, restored 19:05, law enforcement involved, users made whole. Standard playbook now. The real fix would be subresource integrity on every single tag they load.