Incident · Vendor Access

Polymarket Customers Lose $3 Million in Supply-Chain Attack

June 27, 2026 · 6 min read

On June 25, 2025, a threat actor quietly compromised a third-party frontend vendor that serves code to Polymarket's website. The malicious JavaScript they injected tricked users into approving fraudulent transactions, draining approximately $3 million in pUSD from more than 11 wallets — all without touching a single line of Polymarket's own backend infrastructure or smart contracts.

What actually happened

Polymarket is a cryptocurrency-based prediction market platform founded in June 2020 by Shayne Coplan. By October 2025, following a $2 billion investment from Intercontinental Exchange, the platform carried a reported valuation of $9 billion. On the morning of June 25, 2025, on-chain security researcher Specter flagged suspicious transactions draining user wallets. Polymarket confirmed the breach approximately 15 minutes after Specter's public report.

The mechanics were straightforward and devastating: attackers had compromised an unnamed third-party vendor whose JavaScript was loaded directly into Polymarket's frontend. Once that script was live in users' browsers, it manipulated transaction approval prompts — users believed they were interacting with Polymarket normally, but were in fact authorizing transfers of their pUSD (Polymarket's USDC-backed ERC-20 stablecoin on Polygon) to attacker-controlled addresses. Polymarket's servers, backend systems, and core smart contracts were never touched.

"This morning we discovered a 3rd party vendor had been compromised, injecting a malicious script into our frontend for some users. We've contained it & removed the affected dependency. We're contacting impacted users & refunding them in full." — Polymarket Traders, official X account, June 25, 2025

On-chain analysts Specter and PeckShield estimated total losses at approximately $2.94 million to $3 million, spread across more than 11 victim wallets; GoPlus Security placed the figure at approximately 15 affected accounts. After the theft, the stolen funds were bridged from Polygon to Ethereum and swapped into approximately 1,893 ETH. Polymarket contained the incident by removing the compromised dependency and pledged to fully reimburse all affected users. The identity of the specific third-party vendor was not publicly disclosed by Polymarket as of publication. This incident followed a separate, unrelated May 2025 event in which approximately $520,000 was drained from two smart contracts due to a compromised six-year-old private key tied to an internal operations wallet — flagged by on-chain researcher ZachXBT and described as not a platform exploit.

Why this should matter to you even if you don't run Polymarket

The Polymarket attack is a textbook third-party supply-chain compromise, and the pattern appears across every industry — not just crypto. Any organization that embeds third-party JavaScript, loads external SDKs, uses SaaS widgets, or depends on CDN-hosted libraries faces the same exposure. Your code can be perfectly audited and your servers fully hardened while an attacker slides in through a vendor you've never directly assessed.

What makes this class of attack particularly insidious is that the victim organization's own security posture is largely irrelevant to the initial breach. The compromised vendor holds the keys. Polymarket's backend was clean; its smart contracts were intact; its own developers hadn't written a malicious line. None of that mattered once a third party with frontend access was silently subverted. The same logic applies to a law firm using a compromised document-signing widget, a retailer loading a poisoned analytics tag, or a healthcare portal embedding a hijacked chat SDK.

Cyber insurers have taken note. Underwriters are increasingly scrutinizing how applicants manage vendor access — asking whether third-party scripts are reviewed before deployment, whether subresource integrity (SRI) hashes are enforced, and whether vendor contracts include security and breach-notification obligations. A weak answer to those questions is directly correlated with higher premiums and narrower coverage at renewal.

The control that would have blunted it

Subresource Integrity (SRI) enforcement combined with a formal vendor access review program is the control that sits directly between an organization and this class of attack. SRI allows browsers to verify that externally served files — JavaScript, CSS — match a cryptographic hash defined by the hosting organization. If an attacker modifies a third-party script after it has been reviewed and the hash set, the browser refuses to execute the altered file. Had Polymarket enforced SRI hashes on the compromised vendor's script, the malicious version would have been blocked client-side before any user was exposed.

SRI alone is necessary but not sufficient. The broader control is a vendor access management program with three interlocking components: (1) an inventory of every third-party dependency that touches your production environment, (2) periodic security reviews of those vendors — including contractual rights to audit and mandatory breach-notification timelines — and (3) technical controls like SRI, Content Security Policy (CSP) headers, and least-privilege API scoping that limit what vendor-supplied code can do even if it is compromised. Most cyber insurance applications now ask explicitly whether the applicant maintains a third-party vendor risk inventory and whether vendors with access to customer-facing systems are subject to security review. Demonstrating a mature program here is one of the clearest ways to improve both insurability and premium outcomes.

On the incident-response side, the Polymarket case also illustrates the value of real-time on-chain and frontend monitoring. The breach was first surfaced by an external researcher, not by Polymarket's own systems. Organizations serving financial transactions — or any high-value user action — should maintain automated alerting on anomalous transaction patterns and frontend integrity checks, so that detection latency is measured in seconds rather than in the time it takes a third party to post on X.

If you want to go deeper on building a structured third-party risk program — including vendor tiering, contract language, and continuous monitoring workflows — see our Vendor Risk Management product page for tools and templates designed for security teams managing a growing supplier footprint.