Inside the Polymarket $3M client-side supply-chain attack

TL;DR: Polymarket 1,893 ETH approval-phishing drainer

• Contracts were fine: Polymarket's smart contracts were fine. The blockchain worked exactly as designed. The theft happened in the browser tab, through a vendor script the platform had already trusted for months.
• The browser theft: A compromised third-party vendor injected a wallet drainer that swept about $3 million from fewer than 15 wallets, laundered as roughly 1,893 ETH through consolidation wallet 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD. cside watches script behavior and blocks a trusted script that suddenly requests token approvals.
• Revoke approvals today: If your dApp or checkout loads any third-party JS, add runtime script monitoring this quarter. If you cannot, at least revoke unused wallet approvals today, because that is what every investigator told Polymarket users to do.

Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.

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.

Indicators of compromise (on-chain)

On-chain investigators traced the stolen funds to a single consolidation wallet, fed by six staging wallets. The amounts below sum to 1,892.92 ETH, the full consolidated balance. These addresses are attacker-controlled and listed for defender reference, not victim wallets.

Consolidation wallet: 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD

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.

The entire attack lived in the browser runtime layer. The blockchain and smart-contract layer was never breached, it worked exactly as designed, because the signature was authorized in the browser:

1. Compromised third-party vendor. A dependency was poisoned and, per Polymarket's wording, served "for some users."
2. Malicious script injected into the polymarket.com frontend.
3. Real Polymarket interface. The script rode the genuine UI: the user clicked "Connect wallet," then the script presented a malicious ERC-20 approval / signature request.
4. Attacker sweeps victim pUSD once the approval was signed.
5. Bridged Polygon → Ethereum, swapped to roughly 1,893 ETH and laundered through the consolidation wallet 0xe65b…E1eD.

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 let the attacker 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 to prevent a client-side supply chain attack

The Polymarket incident shows a repeatable pattern. Every web application that loads third-party JavaScript has the same exposure. These four controls reduce the risk in any stack.

Maintain a live script inventory. Know every dependency that runs in your users' browsers: who owns it, what data it can access, and why it is there. This is not a one-time audit. Scripts change. Vendors add sub-dependencies. Code that was reviewed and approved a year ago may load very different behavior today. PCI DSS 4.0.1 §6.4.3 requires a live inventory for payment pages precisely because an unknown script is an unmonitored script. Start with payment flows and authentication pages.

Monitor what scripts actually do, not just where they come from. CSP validates source origin. Once a trusted vendor is compromised, CSP has no way to detect that their analytics tag is now requesting wallet approvals. A trusted domain is not the same as trusted behavior. Monitoring at the JavaScript runtime layer, where scripts actually execute, catches what any source-based control misses: a script that handled analytics yesterday and is interacting with the wallet provider today.

Alert on behavioral drift before a signature is published. Threat intelligence is reactive by definition. A vendor that was compromised this morning will not appear on any feed until after the damage is done. Detection that responds to behavioral drift, a script that contacts new external domains, gains new browser API access, or reads data structures it previously ignored, closes that window.

Practice the removal playbook before you need it. Polymarket's team identified the compromised dependency, removed it, and committed to reimburse affected users. Most teams have not practiced this sequence. Knowing which scripts to remove and how fast a clean build can be deployed turns a supply chain compromise from a days-long crisis into a containable incident.

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 over source. We watch what a script 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.

Script Method. cside runs in two modes, Script Method and Scan Method. In Script Method we watch each script's behavior in the live user session and analyze the script server-side on our own infrastructure, then block it the moment the behavior is confirmed malicious, with no proxy required. Because we observe what actually executes in the session, the "serve the scanner a clean version" trick does not help, and we catch payloads that only fire for specific users, geographies, or sessions, the same "for some users" targeting seen here.

Real-time blocking. 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.