Worked example · 2026-06

Polymarket — a compromised third-party frontend vendor injects wallet-draining JavaScript into the live site — Polygon / Ethereum — 2026-06-25

Loss: ~$3.0–3.1M realised from at least 11 user wallets. On 2026-06-25 an attacker served malicious JavaScript to real users on Polymarket's official site through a compromised third-party frontend dependency, draining pUSD (Polymarket's USDC-backed stablecoin). The figure firmed from ~$3.0M at disclosure to ~$3.1M within about two days. Polymarket's own backend, servers and smart contracts were not compromised; the failure was in the client-side supply chain of the website. The stolen pUSD was bridged from Polygon to Ethereum, swapped to roughly 1,893 ETH, and consolidated into a single wallet. Polymarket contained the incident within hours, removed the compromised dependency, and pledged full refunds to affected users.
OAK Techniques observed: OAK-T15.002 (Supply-Chain / Vendor-Pipeline Compromise — primary mechanism. The entry point was a compromised third-party frontend vendor / dependency that Polymarket shipped as part of its website. Polymarket disclosed only that "a 3rd party vendor had been compromised"; the specific package or domain was not named. Through that dependency the attacker inserted malicious code into the legitimate frontend served on the official site. See techniques/T15.002-supply-chain-vendor-pipeline-compromise.md). OAK-T4.002 (Compromised Front-End Permit Solicitation — the injected script hijacked active browser sessions and prompted fraudulent token-approval transactions, so users on the real site were led to approve transfers that drained their pUSD. See techniques/T4.002-compromised-frontend-permit-solicitation.md). The laundering path (pUSD bridged Polygon → Ethereum, swapped to ~1,893 ETH, consolidated to one wallet) is OAK-T7.003.
Attribution: unattributed. No named actor. Rescana notes there was no unique malware family or toolkit to attribute, and the observed behaviour is consistent with either financially-motivated crime or a more capable actor. On-chain analysts (including "Specter") sized the loss at about $2.94M across 11 wallets; the ~1,893 ETH consolidation figure traces to PeckShield's fund-flow analysis. The specific compromised vendor was never publicly identified.
Key teaching point: A wallet interface can be fully trustworthy at the smart-contract and server layer and still drain users, because the client-side supply chain of the website is its own attack surface. Nothing about Polymarket's contracts or backend failed here; a dependency in the frontend it ships was compromised, and the malicious code rode the trust users place in the official domain to solicit approvals. The controls that address this class live at the web-delivery layer: subresource integrity and pinning on third-party scripts, a strict content-security policy that constrains what injected code can do, review and provenance checks on frontend dependencies and vendors, and client-side transaction-simulation or approval-warning tooling that flags an unexpected approval prompt regardless of which site raised it. This is a different Polymarket supply-chain incident from the earlier trader-tooling campaign in examples/2026-01-polymarket-trader-tooling-supply-chain.md, which used malicious npm packages and impersonation to steal keys from developers and bot operators and did not touch Polymarket's own site; the two share the supply-chain theme but differ in surface, delivery and victims. The concurrent CFTC probe into Polymarket's marketing is unrelated to this incident and is not part of its mechanism.

Summary

Polymarket is a prediction-market platform whose users trade on its official website using pUSD, a USDC-backed stablecoin, on Polygon. On 2026-06-25, an attacker compromised a third-party frontend vendor whose dependency Polymarket shipped as part of that website, and used it to inject malicious JavaScript into the live frontend served to real users.

The injected script hijacked active browser sessions and prompted users to approve fraudulent token-approval transactions. Users who approved had their pUSD moved to attacker-controlled addresses. At least 11 wallets were drained for a total of about $3.0–3.1M. Polymarket's backend, servers and smart contracts were not involved; the compromise was entirely in the client-side supply chain of the site.

The stolen pUSD was bridged from Polygon to Ethereum, swapped to roughly 1,893 ETH, and consolidated into a single wallet. Polymarket identified and removed the compromised dependency within hours, isolated the malicious script, began contacting affected users directly, and committed to full refunds; the loss figure was revised upward to about $3.1M two days later. The specific vendor and no indicators of compromise were published.

Timeline (UTC)

When	Event	OAK ref
Pre-2026-06-25	A third-party frontend vendor / dependency shipped in Polymarket's website is compromised	T15.002 (entry vector)
2026-06-25	Malicious JavaScript is served to real users on the official Polymarket frontend; it hijacks sessions and prompts fraudulent token approvals; ~~11 wallets drained of pUSD (~~$3.0M)	T15.002 + T4.002 execution
2026-06-25	Stolen pUSD bridged Polygon → Ethereum, swapped to ~1,893 ETH, consolidated to a single wallet	T7.003
2026-06-25/26	Polymarket contains the incident, removes the compromised dependency, contacts affected users, pledges full refunds; discloses publicly	(operator response)
2026-06-27	Loss revised to ~$3.1M	(updated accounting)

What defenders observed

Pre-event (frontend dependency and vendor trust). The compromise originated in a third-party dependency Polymarket shipped. Subresource integrity, script pinning, vendor/provenance review, and a restrictive content-security policy limit what a compromised dependency can do once it is on the page. These are web-delivery controls, distinct from smart-contract audits.
At-event (approval prompt on the trusted domain). The drain relied on users approving transfers on the real site, where the domain itself lent the prompt legitimacy. Client-side transaction simulation and approval-warning tooling that flags an unexpected or excessive approval, independent of the originating site, is the user-facing control.
At-event (backend intact, client-side drained). On-chain, Polymarket's contracts behaved normally; the loss was in signed user transactions solicited by injected code. Monitoring that watches for anomalous approval patterns from users of a given frontend, rather than only contract-level events, is the relevant detection surface.
Post-event (fast containment plus refunds). Polymarket removed the dependency within hours and committed to refunds, which bounds user exposure even though the on-chain funds were bridged and consolidated quickly. Containment here is about pulling the malicious script and making users whole, not recovering the moved funds.

Public references

[bleepingpolymarket2026] — BleepingComputer, "Polymarket customers lose $3 million in supply-chain attack" (primary incident report; JS injection via frontend vendor, backend not impacted, PeckShield fund-flow): https://www.bleepingcomputer.com/news/security/polymarket-customers-lose-3-million-in-supply-chain-attack/
[securityweekpolymarket2026] — SecurityWeek, "$3 Million Reportedly Stolen in Polymarket Hack" (~$3M pUSD to ~1,893 ETH, at least 11 victims, vendor unnamed): https://www.securityweek.com/3-million-reportedly-stolen-in-polymarket-hack/
[halbornpolymarket2026] — Halborn, "Explained: The Polymarket Hack (June 2026)" (at least 11 wallets, Polygon → Ethereum bridge, consolidation to one wallet, contracts unaffected): https://www.halborn.com/blog/post/explained-the-polymarket-hack-june-2026
[rescanapolymarket2026] — Rescana, "Polymarket Supply-Chain Attack Analysis" ("fewer than 15 accounts," no IOCs or vendor disclosed, prevention guidance): https://www.rescana.com/post/polymarket-supply-chain-attack-analysis-3-million-cryptocurrency-theft-via-compromised-third-party-dependency
[coindeskpolymarket2026] — CoinDesk, "Polymarket hack updated to $3.1 million days after the platform promised users full refunds" (loss revision; refund-pledge context): https://www.coindesk.com/markets/2026/06/27/polymarket-hack-updated-to-usd3-1-million-days-after-the-platform-promised-users-full-refunds

Discussion

Polymarket 2026-06 is OAK's clean anchor for a frontend-vendor supply-chain compromise that drains users while the protocol's own contracts and servers stay intact. It belongs to the T15.002 family alongside the Ledger Connect Kit library compromise and the Nx Console extension compromise, but with a prediction-market frontend as the delivery surface and user token approvals as the extraction, which is why T4.002 is co-primary: the vendor compromise put the malicious code on the page, and the fraudulent approval prompt is how value actually left.

The case is worth keeping distinct from the earlier Polymarket trader-tooling campaign. That one poisoned npm packages and impersonated Polymarket to steal keys from developers and bot operators, and never touched Polymarket's own site. This one compromised a dependency Polymarket itself shipped and served malicious code from the official domain. The shared lesson is that "the protocol is secure" is not the same as "the website is safe to use," and the defensive unit for a wallet-facing product includes its frontend build and its vendor dependencies, checked with subresource integrity, provenance review, and a content-security policy, plus client-side approval-warning tooling for users. The vendor was never named, so the entry records the mechanism and leaves the specific dependency open.