Polymarket Users Drained of $3M by a Trusted Third-Party Script Exposing the Limits of CSP and SRI
(aka a Textbook Digital Skimming Attack)
TL;DR – On June 25, 2026, Polymarket disclosed that a “3rd party vendor had been compromised, injecting a malicious script into our frontend for some users.” It never identified the vendor or the compromised dependency. Source Defense Research tracked down the actual payload.
A third-party script that Polymarket loaded was replaced, at its source, with an 18 KB wallet drainer hardcoded to target Polymarket. The attack ultimately drained approximately $3 million in pUSD from roughly 11 high-value wallets.
More importantly, our investigation found that the same malicious script was being served to unrelated websites at the same time. Only Polymarket users lost funds because the malware specifically targeted Polymarket – but every website loading that compromised third-party resource was unknowingly executing attacker-controlled code.
This is not simply another cryptocurrency story, it’s a textbook client-side supply-chain attack that mirrors the digital skimming (Magecart) campaigns responsible for billions of dollars in payment card fraud over the past decade.
What Polymarket Disclosed
“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.”
No vendor was identified. No dependency was named.
Blockchain researchers including Specter, PeckShield and Bubblemaps quickly estimated losses approaching $3 million across fewer than 15 wallets (approximately 11 confirmed victims). The stolen pUSD was converted into ETH and bridged from Polygon to Ethereum.
One point immediately stood out. The blockchain itself was never compromised.
The smart contracts performed exactly as designed.
The attack occurred entirely in the browser, the same attack surface that has fueled years of eSkimming and digital skimming attacks against online merchants.
So we went looking for the script.
The Hunt: From Homepage Diff to a Marketing Tag
We began where Polymarket’s disclosure pointed us: the frontend.
Comparing archived versions of the homepage before and after the incident revealed one notable difference.
A third-party marketing tag that existed before the attack disappeared immediately afterward.
That tag dynamically loaded JavaScript from an externally hosted service:
loader = function (key) { var script = document.createElement("script"); script.async = true; script.src = "https://<third-party-host>/" + key + "/loader.js"; };
By itself, this loader appeared benign.
We reviewed multiple historical versions and found no malicious wallet functionality.
However, it performed one critically important action.
It dynamically loaded another third-party JavaScript library from a second external host.
let s = document.createElement("script"); s.src = "https://<third-party-host-2>/<library>.js"; document.head.appendChild(s);
This was not an identity library. It was a purpose-built wallet drainer.
The script referenced:
Polymarket’s relayer
Polymarket APIs
Embedded wallet infrastructure
Attacker payout wallets
Attacker-controlled infrastructure
Even more importantly…
The same compromised third-party host delivered the malware and received stolen information back through image beacon requests.
Whoever controlled that infrastructure controlled the attack.
The Attack, Step by Step
1. Delivery
Polymarket loaded a trusted third-party marketing tag.
That marketing tag loaded a second third-party JavaScript library.
Instead of receiving the legitimate library, browsers received the malicious wallet drainer.
Nothing appeared suspicious to the browser.
Everything originated from trusted infrastructure.
2. Reconnaissance
The malware queried Polymarket APIs to determine the visitor’s holdings.
3. Targeting
Only wallets worth more than $100,000 were attacked.
This selective targeting dramatically reduced the number of victims while allowing the campaign to remain active longer.
4. Coerced Signature
Victims were repeatedly prompted to sign an EIP-712 authorization.
The malware continued prompting until users eventually approved the transaction.
5. Abuse of Legitimate Infrastructure
The authorization was submitted through Polymarket’s own gasless relayer.
Nothing about the blockchain transaction itself appeared malicious.
6. Exfiltration
Results – including wallet values, addresses, authentication methods and transferred amounts – were beaconed back to the attacker through the same compromised third-party host.
Following the Money
Blockchain analysis shows stolen pUSD converted into ETH before ultimately converging into:
0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD
Two attacker wallets embedded directly inside the recovered malware funded that address.
The recovered source code and blockchain activity independently validate one another.
It Wasn’t Just Polymarket
Perhaps the most significant finding from our research has received very little public discussion. The malicious JavaScript was not served exclusively to Polymarket.
It was simultaneously delivered to unrelated websites.
That means the compromise occurred upstream, in the vendor’s digital supply chain – not inside Polymarket itself.
Source Defense identified the compromised third-party as a widely deployed marketing technology provider with visibility into at least 3,000 well-known brands worldwide.
Fortunately, the attacker intentionally hardcoded Polymarket-specific targeting.
On every other website the malware quietly failed because the APIs it expected simply did not exist. But that should not provide comfort.
Every organization serving that JavaScript had effectively delegated execution of arbitrary attacker-controlled code into every visitor’s browser.
The only thing preventing a much larger incident was the attacker’s decision to target a single victim.
Tomorrow, the exact same compromised supply chain could just as easily target one of those other thousands of organizations.
The Polymarket Attack Also Exposes a Dangerous Industry Misconception
One aspect of this incident deserves considerably more attention than it has received.
Several security write-ups published shortly after disclosure recommended deploying Content Security Policy (CSP) or Subresource Integrity (SRI) to defend against attacks like this.
While understandable, those recommendations fundamentally misunderstand how this attack succeeded.
Our research indicates Polymarket maintained a sophisticated and well-managed Content Security Policy.
It simply made no difference.
Why?
Because CSP is fundamentally a whitelist.
It answers one question:
“Is this script allowed to execute?”
The compromised JavaScript originated from a trusted third-party already authorized by Polymarket.
From the browser’s perspective, nothing unusual occurred.
The browser faithfully executed code from an approved supplier.
The malicious behavior happened only after that trust decision had already been made.
This illustrates the central weakness of whitelist-based security.
If attackers compromise a trusted supplier (or a supplier’s own supply chain) the browser will execute malicious code exactly as instructed because the source has already been declared trustworthy.
That appears to be exactly what happened here.
A Textbook Digital Skimming Attack
From a client-side security perspective, there is remarkably little difference between this attack and traditional digital skimming/eSkimming (Magecart) campaigns.
The attackers:
Compromised a trusted third-party supplier instead of the website itself
Delivered malicious JavaScript through an approved supply chain
Executed inside every visitor’s browser
Examined sensitive user data before backend protections could ever see it
Selected only high-value victims to reduce detection
Quietly exfiltrated stolen information using ordinary browser functionality
The only meaningful difference was the asset being stolen.
Traditional digital skimming campaigns harvest:
payment cards
credentials
personally identifiable information
This campaign harvested cryptocurrency. The underlying attack methodology remained almost identical.
For years, Visa, Mastercard, Verizon, PCI DSS, Europol and numerous incident response organizations have warned that attackers increasingly compromise website supply chains rather than merchant infrastructure itself. This attack demonstrates that exactly the same techniques now threaten cryptocurrency platforms as well.
The CSP and SRI Fallacy
Content Security Policy and Subresource Integrity remain valuable browser technologies.
They simply were never designed to stop trusted JavaScript from behaving maliciously.
CSP controls where scripts may load from.
SRI verifies that a static file matches a cryptographic hash.
Neither answers questions such as:
Is this script reading wallet information?
Is it scraping payment data?
Is it requesting signatures?
Is it modifying the DOM?
Is it injecting additional code?
Is it transmitting sensitive information elsewhere?
Those are runtime behavioral questions.
When malicious activity originates from an already trusted supplier, static trust models become ineffective.
This is precisely why Source Defense and numerous independent QSAs have consistently warned against relying exclusively on CSP or SRI to defend against modern client-side attacks. Behavior-based runtime controls are necessary because attackers increasingly hide inside services websites already trust.
Even PCI DSS Leaves Room for Dangerous Assumptions
To be clear:
PCI DSS correctly identifies client-side attacks as a major fraud concern.
Requirements 6.4.3 and 11.6.1 require organizations to:
inventory scripts
authorize scripts
justify scripts
monitor changes
detect unauthorized modification
Those are important controls.
However, accompanying guidance references approaches including CSP and SRI as possible implementation mechanisms.
Unfortunately, many organizations have interpreted this guidance to mean that deploying CSP or SRI alone provides meaningful protection against modern digital skimming attacks.
The Polymarket incident demonstrates why that assumption is dangerous.
If attackers operate through an already trusted supplier, CSP has little ability to distinguish malicious behavior from legitimate functionality.
Likewise, SRI provides limited value for dynamic third-party JavaScript that changes frequently or delivers customized content.
The better question is no longer:
“Was this script authorized?”
The better question is:
“What was this authorized script actually allowed to do?”
Modern client-side security solutions like Source Defense answer that question by applying zero-trust principles directly to third-party JavaScript – sandboxing execution, controlling behavior, and preventing unauthorized access to sensitive data regardless of whether the code originates from a trusted partner or a compromised one. That behavioral approach aligns much more closely with the techniques attackers are using today.
The Larger Lesson: Trusted Scripts Have Become the Internet’s Soft Underbelly
Polymarket’s blockchain worked. Its smart contracts worked. Its cryptography worked.
Its audits worked. The compromise occurred somewhere entirely different.
It occurred inside a trusted third-party JavaScript supply chain executing with complete privilege inside users’ browsers.
That is exactly how modern digital skimming attacks have operated for years. The only thing that changed was the target. Instead of stealing payment cards, attackers stole cryptocurrency.
Organizations increasingly depend on dozens of third-party JavaScript suppliers. Website owners routinely extend complete trust to these partners, despite broader industry adoption of zero-trust principles everywhere else in enterprise security.
The Polymarket incident demonstrates why that model is increasingly difficult to defend.
Organizations need more than visibility into which scripts execute.
They need continuous runtime control over what those scripts are allowed to do after they begin executing.
Without that capability, every trusted third-party relationship becomes another opportunity for attackers to hide malicious activity inside software the browser has already been instructed to trust.
Research by Source Defense Research
Disclosure note: At the time of analysis, the malicious script was observed being served from a legitimate third-party provider. Whether the incident resulted from compromise of the vendor itself, its build pipeline, or associated infrastructure remains under investigation. Because the poisoned script was observed on additional websites and responsible disclosure efforts remain ongoing, identifying information relating to the vendor has been intentionally withheld pending notification.
