On 2026-06-25, the prediction market platform Polymarket confirmed that attackers had stolen roughly $3 million from a small number of users. On-chain investigator Specter, who first flagged the theft, traced about $2.94 million drained from at least 11 wallets; blockchain analytics firm Bubblemaps put the total at fewer than 15 accounts and published the addresses involved. Polymarket contained the incident quickly, removed the offending dependency, and committed to reimbursing every affected user in full.
For anyone running a website with money or sensitive data moving through it, the detail that matters is where the attack happened. Polymarket's smart contracts were never breached. The blockchain worked exactly as designed. The theft happened in the browser, through a third-party script the platform trusted. This is a textbook client-side supply-chain attack, the same class of attack that hits e-commerce checkouts, fintech login pages, and SaaS dashboards every week.
The mechanics matter, because they explain why so many teams are exposed to the same risk.
What happened
In its own statement, Polymarket said it "discovered a 3rd party vendor had been compromised, injecting a malicious script into our frontend for some users," and that it had contained the incident and removed the affected dependency. As of publication, neither Polymarket nor independent reporting has named the compromised vendor or dependency.
The target was pUSD, Polymarket's USDC-backed stablecoin and the platform's primary trading collateral. When affected users connected their wallets, the injected code prompted them to sign or approve transactions that quietly handed funds to the attacker. Security firm PeckShield reported that the stolen pUSD was bridged from Polygon to Ethereum and swapped into roughly 1,893 ETH, which investigators traced to a single consolidation address. Multiple firms classified the event as a supply-chain compromise combined with a phishing campaign that ran through the platform's own interface.
The mechanics are simple, and they apply to almost any modern website:
- The attacker never had to break into Polymarket's servers or smart contracts.
- They compromised a trusted vendor whose code was already permitted to run on the site.
- Once that code executed inside the live frontend, it looked identical to legitimate code to the people using the site.
A user looking at the normal interface had no practical way to know that the script handling their transaction had changed. That is the defining feature of this attack class, and it is why it is so hard to catch from the outside.
The technical angle: a wallet drainer delivered through the supply chain
Most coverage stops at "supply-chain attack." The mechanism is more specific, and it is what makes this incident worth studying.
A classic Magecart skimmer is passive. It reads what a victim types into a checkout form and copies it to an attacker's server. This attack had no form to skim, so the injected script went active and went after the signature itself.
Based on the on-chain analysis, when an affected user connected their wallet, the script presented a malicious approval or signature request through the genuine Polymarket interface. Approving it gave the attacker the ability to move the victim's pUSD. This is the same approval-phishing technique wallet drainers rely on: get the holder to sign an ERC-20 approval or token permit, then sweep the balance to an attacker-controlled address. The clearest tell is the remediation every investigator gave, which was to revoke token approvals. You only revoke approvals when approvals were the weapon.
Here is what is different about this case. Wallet drainers usually reach victims through fake airdrop sites, malicious ads, typosquatted domains, or hijacked social links. Every one of those depends on luring you somewhere fake, so the usual advice works: check the URL, use the official site, look for the padlock. None of that helped here. The drainer ran on the real polymarket.com, in a session where the user had already connected their wallet and had every reason to trust the next prompt. Supply-chain injection turned the legitimate frontend into the phishing page.
This pattern has a clear, named precedent. In December 2023, attackers phished a former Ledger employee's npm account and pushed malicious versions of @ledgerhq/connect-kit, the open-source library many dApps use to connect Ledger hardware wallets. The poisoned versions injected a wallet drainer into the frontend of every site that loaded the library, including SushiSwap, Zapper, and Revoke.cash, and took roughly $600,000 in a few hours. One hijacked open-source dependency drained users across many sites at once, with no fake URL anywhere. Polymarket's compromised dependency has not been named, but the blueprint is the same.
Polymarket's own wording carries the detail that matters most for defenders: the script was injected "for some users." The payload was conditional. That is the same property that lets these attacks slip past a scanner crawling from a data center, and it is why a control that only checks a script's source cannot help once the source is trusted.
Where this attack actually happened
Filing this under "another crypto hack" hides the part every web team should care about. The blockchain layer behaved correctly. The smart contracts were not exploited. There was no reentrancy bug, no flash loan, no oracle manipulation. The attack lived entirely in the browser runtime, the layer between your server and your user's screen, where third-party JavaScript runs with the same privileges as your own code.
That layer is one of the most under-monitored surfaces in modern web applications. Teams repeat the rule "never trust the client side," then routinely load dozens of third-party fetches into that client side: analytics, tag managers, chat widgets, marketing pixels, and SDKs. Every one of those is a dependency, and every dependency is a potential entry point. The Polymarket attacker used a vendor relationship that was already trusted, because the vendor on the other side had been compromised.
We have documented this pattern before. The AppsFlyer Web SDK compromise followed the same blueprint: attackers hijacked a trusted marketing SDK and served a malicious payload to thousands of sites whose owners had no idea their scripts had changed. We have also tracked malicious browser extensions impersonating Microsoft Clarity to overwrite referral tokens and reroute revenue. Different payloads, same root cause: trusted third-party code that turns hostile, runs in the browser, and stays invisible to traditional defenses.
Why standard defenses don't catch this class
If you are wondering why common security controls do not stop this, the answer is structural. Most of the tooling teams rely on simply cannot see this attack.
- Server-side and network security monitor your own infrastructure. The malicious code never touched it. The vendor was compromised upstream, and the payload ran on the user's device.
- Content Security Policy (CSP) allow-lists which domains can serve scripts, but it validates the source, not the behavior. If a trusted, allow-listed vendor starts serving malicious code, CSP waves it through. It has no idea whether the script is reading a form field or asking the wallet for a token approval. For a deeper look, see why CSP alone doesn't stop client-side attacks.
- Static scanners crawl your site looking for known-bad scripts. More sophisticated attackers detect the scanner and serve it a clean version while delivering the real payload to actual users. Polymarket's script ran "for some users," which is exactly that kind of conditional delivery, and a scanner is the easiest thing to exclude.
The behavior that should have stood out is specific: a third-party script that had never touched the wallet provider suddenly interacting with it and prompting users to approve token transfers. That is observable at the JavaScript runtime, where the script actually executes. It is invisible to a control that only checks where the script came from.
A pattern across the web
Zoom out and the trend is clear. DefiLlama recorded Q2 2026 as the worst quarter for crypto security incidents it has ever logged, with about $74.9 million lost across 29 exploits in June alone. The defining web security story of 2026 is no longer the buggy smart contract or the unpatched server. It is the trusted dependency that goes bad, and the browser runtime where that failure plays out.
Attackers are diversifying because the older entry points are getting harder to open. As protocol-level and server-level defenses mature, the client side stays the softer target. It is easy to reach and rarely monitored in real time. The polyfill[.]io supply-chain attack, which reached hundreds of thousands of sites through a single trusted dependency, is the same story at a much larger scale.
How cside detects this class of attack
cside was built for the exact surface this attack used. Here is how it would look through our detection engine.
Behavior, not just source. We do not only check where a script comes from. We watch what it does in the runtime: DOM manipulation, event listeners, what data it accesses, and where it sends that data. A trusted vendor's script that suddenly reaches for the wallet provider, prompts a token approval, or contacts a freshly registered domain is exactly the kind of anomaly we surface.
Drift detection. Scripts do not stay static. A dependency that ran analytics last week and starts touching wallet APIs and a new domain this week triggers an alert. Our AI generates a plain-language explanation of what changed and why it matters, so you do not need a researcher to read a hash diff.
Gatekeeper mode. Our edge engine can sit between untrusted third parties and your users, serving the script through a conduit we control, for the scripts you choose. We keep a copy of what was actually delivered, which defeats the "serve the scanner a clean version" trick, and it captures payloads that only fire for specific users, geographies, or sessions, the same "for some users" targeting seen here.
Real-time blocking, not just reporting. Scanners report. CSP blocks on limited data. cside can block a script based on its observed behavior before it drains a wallet or skims a card. A tool that only tells you about a breach after it happens leaves you reacting.
Polymarket's response, containing the incident, removing the dependency, and refunding affected users in full, is what a strong response looks like after an attack. The opportunity for every other platform is to make sure there is never an "after." Real-time frontend integrity monitoring is not yet standard across the web, and incidents like this are why it should be.
Polymarket was hit on the client side, where attacks are easiest to hide and hardest to detect. If third-party JavaScript runs on your site, and it does, that surface is exposed whether you are watching it or not.
Figures and attribution above reflect early reporting from Specter, PeckShield, and Bubblemaps and are accurate as of 2026-06-26.
Want to see what is actually running in your users' browsers? Start for free or book a demo to talk with our team.
