Polymarket Lost $3M; Source Defense Found the Magecart Script on Other Customer Sites
Polymarket users lost approximately $3 million because a trusted script chain became a delivery path for attacker-controlled JavaScript inside the browser, but the broader risk went beyond Polymarket. Although the incident had already been discovered and discussed publicly, Source Defense also published a detailed blog on the incident, including the malicious script analysis and evidence of broader customer exposure.
Source Defense located the malicious file, analyzed its behavior, and added new technical detail about how the attack worked in the client-side environment. The most important finding was the hidden blast radius: the third-party provider had thousands of other customers, and Source Defense found evidence that the malicious fourth-party script also loaded on some customer sites beyond Polymarket. They were not drained because the code was hardcoded to target Polymarket, but the malicious JavaScript still loaded and ran on those sites. This turns the incident from a single-site crypto theft into a clear example of trusted-provider risk, where one compromised script dependency can reach unrelated websites.
Attack details
This was a third-party script attack involving fourth-party script activity. Polymarket loaded a trusted third-party marketing tag, which then dynamically loaded a fourth-party JavaScript library from another external host. A fourth-party script is code loaded by a third-party provider rather than directly by the website owner. In this case, Polymarket trusted the marketing provider, and that provider’s code loaded another external script into the page.
Source Defense’s analysis of the malicious file found that visitors received an 18 KB payload in place of the legitimate identity library, which was approximately 479 KB. The malicious script was not generic skimming code. It was hardcoded for Polymarket and referenced Polymarket APIs, relayer infrastructure, embedded Ethereum wallet functionality, attacker payout wallets, and attacker-controlled infrastructure. It queried Polymarket APIs to identify Ethereum wallet holdings, targeted wallets worth more than $100,000, repeatedly prompted victims to sign an EIP-712 authorization, and submitted that authorization through Polymarket’s own gasless relayer. Exfiltration occurred through image beacon requests back to the compromised fourth-party host, including wallet values, wallet addresses, authentication methods, and transferred amounts.
Source Defense also found evidence that other customers of the same third-party provider loaded the malicious fourth-party script. Those sites were not affected because the code’s active theft logic was Polymarket-specific, but the script still executed in their visitors’ browsers. CSP and SRI did not address the core issue because CSP is a browser-enforced allowlist for where code may load from, and SRI is a browser-enforced integrity check that works best for static files. In this case, the browser had already trusted the script chain, and the malicious behavior emerged at runtime inside the user’s session.
How Source Defense protects you
Source Defense protects against this class of attack by extending security control into the browser, where third-party and fourth-party JavaScript actually run. Instead of relying only on whether a script came from an approved source, Source Defense provides browser-side runtime visibility and control over what scripts are allowed to do after they execute. That distinction matters when a trusted supplier, vendor dependency, or upstream JavaScript resource is compromised. A script may be loaded by many customer sites but activate only under specific conditions, such as a target domain, user profile, Ethereum wallet value, or page state. CSP and SRI remain useful browser-enforced controls, but they can struggle with trusted-source abuse, dynamic third-party code, nested fourth-party dependencies, and behavior that becomes malicious only at runtime. WAFs and server-side monitoring protect the application environment, but they may not see browser-side script behavior before user data, wallet information, or authorization flows are manipulated. Source Defense helps secure the client side by monitoring script behavior, controlling access to sensitive data, and detecting unauthorized transfers or risky execution inside the user’s session.
How Source Defense alerts you
For third-party and fourth-party script activity like this, Source Defense can alert security teams when a script is accessing pci data, transferring data, executing risky actions such as eval, setTimeout, new Function, or setInterval, using browser storage, and using first-party cookies. When relevant, alerts appear in the bell notification center, dashboard summaries, and “Script behaviors.” Teams can also receive notifications by email and webhook, helping security, compliance, and incident response teams act quickly when trusted script chains start behaving in ways that create risk.
Key takeaways
The Polymarket incident reinforces a pattern Source Defense has tracked across years of eSkimming and digital skimming attacks: attackers do not always need to compromise the website itself when they can compromise a trusted script in the website’s supply chain. The new twist is the blast radius. A malicious fourth-party script can load across many customers of the same provider, even when the harmful logic activates only on one target site. Instead of harvesting payment card data, this malicious JavaScript drained cryptocurrency by abusing Ethereum wallet authorization flows inside the browser, and it did so through a trusted third-party tag that loaded fourth-party code. CSP and SRI are valuable browser-enforced controls, but they were not designed to decide whether an already trusted script chain is reading sensitive data, triggering wallet signatures, or beaconing results to attacker-controlled infrastructure. WAFs, firewalls, backend logs, and server-side monitoring operate outside the browser and may miss what happens before data reaches the server. Source Defense closes that client-side gap with runtime visibility and control over script behavior, helping organizations protect users even when trusted third-party and fourth-party code become the attack path.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.