Polymarket Loses $3.1M in Frontend Supply Chain Attack, Pledges Refunds
Polymarket Hit by $3.1M Supply Chain Attack; Malicious JavaScript Siphons User Funds
Impact Scope
People Affected
fewer than 15 accounts
Industries Affected
Related Entities
Full Report
Executive Summary
The cryptocurrency prediction market Polymarket has fallen victim to a sophisticated frontend supply chain attack, resulting in customer losses of approximately $3.1 million. The attack, which occurred around June 26, 2026, did not compromise Polymarket's backend servers or smart contracts. Instead, the threat actors breached a third-party vendor that provides a software dependency for Polymarket's website. By injecting malicious JavaScript into this dependency, the attackers were able to manipulate the frontend experience for users. The script tricked users into signing what appeared to be legitimate transactions but were in fact approvals to transfer funds to attacker-controlled wallets. Polymarket has since contained the breach by removing the compromised dependency and has committed to fully refunding all losses for the small number of affected users.
Threat Overview
- Attacker: An unidentified threat actor or group.
- Victim: Polymarket, a popular crypto prediction platform, and its users.
- Attack Vector: The primary vector was a supply chain compromise. The attackers breached a third-party software provider and used that access to inject malicious code into a JavaScript library used by Polymarket's official website.
- Mechanism: The malicious script intercepted user interactions with their crypto wallets (e.g., MetaMask). When a user attempted to perform a normal action on the site, the script presented them with a fraudulent transaction approval request. Unsuspecting users approved the transaction, granting the attackers permission to drain funds from their wallets.
Technical Analysis
The attack chain follows a classic frontend supply chain compromise pattern:
- Initial Compromise: The attackers gained access to the development or distribution environment of an unnamed third-party vendor that supplies code to Polymarket.
- Code Injection: The attackers injected malicious JavaScript into a legitimate software package. This technique is a form of
T1199 - Trusted Relationship, as Polymarket's website inherently trusted the code from its vendor. - Drive-by Compromise: Users visiting the official Polymarket website loaded the compromised script in their browsers, falling victim to a
T1189 - Drive-by Compromise. - Social Engineering & Deception: The malicious script used social engineering to trick users into signing malicious transactions. This could be considered a form of
T1204.001 - User Execution: Malicious LinkorT1204.002 - User Execution: Malicious Filein a web context. - Exfiltration & Laundering: Blockchain security firm PeckShield reported that the attackers stole approximately $3 million in
ParyonUSD (pUSD). They then used a cross-chain bridge to move the funds from the Polygon network to Ethereum and swapped them for approximately 1,893 ETH to obscure the trail.
Impact Assessment
The direct financial impact was approximately $3.1 million, stolen from fewer than 15 user accounts according to analytics firm Bubblemaps. While Polymarket's pledge to fully reimburse victims mitigates the direct financial loss for users, the incident carries significant reputational damage. It erodes user trust in the platform's security, even though its core smart contracts were not breached. This attack underscores the systemic risk of software supply chains in the Web3 ecosystem, where a single compromised dependency can lead to millions in losses. It highlights that even with secure smart contracts, the user-facing web interface remains a critical and often vulnerable attack surface.
IOCs — Directly from Articles
No specific Indicators of Compromise (IOCs) such as domains, IP addresses, or file hashes were provided in the source articles.
Cyber Observables — Hunting Hints
Security teams may want to hunt for the following patterns to detect similar frontend attacks:
eth_sendTransaction, personal_signDetection & Response
- Subresource Integrity (SRI): Implement SRI for all third-party scripts. This ensures that the browser will only load a script if its hash matches a known, trusted value. This would have prevented the modified script from executing. This is a form of D3FEND File Hashing (D3-FH).
- Content Security Policy (CSP): Implement a strict CSP to control which domains the browser is allowed to load scripts from and connect to. This can prevent the malicious script from being loaded or from exfiltrating data to an attacker-controlled server.
- Third-Party Script Auditing: Regularly audit all third-party dependencies for signs of compromise, unexpected changes, or vulnerabilities. Automated tools can help monitor these scripts for malicious behavior in a sandboxed environment.
Mitigation
- Vendor Risk Management: Conduct thorough security assessments of all third-party vendors, especially those whose code runs on your frontend. This aligns with
M1016 - Validate Input. - Implement Subresource Integrity (SRI): As a top priority, use SRI hashes for all externally loaded scripts. This is the most direct technical control to prevent this type of attack.
- Local Hosting of Dependencies: Where possible, host third-party libraries on your own infrastructure after vetting them. This reduces reliance on external CDNs and repositories that could be compromised.
- Transaction Simulation: For users, wallet providers should offer transaction simulation features that clearly show the outcome of a transaction before it is signed, making it harder for users to be tricked.
Timeline of Events
MITRE ATT&CK Mitigations
Restrict Web-Based Content
Use technologies like Content Security Policy (CSP) and Subresource Integrity (SRI) to prevent the loading and execution of unauthorized or modified third-party scripts.
Vet third-party scripts in a sandboxed environment before deployment to identify malicious behavior. Isolate the execution context of different scripts to prevent one from interfering with another.
User Training
Educate users, especially in the crypto space, to be highly skeptical of transaction requests and to use wallet features that simulate or clearly explain what a transaction will do before signing.
D3FEND Defensive Countermeasures
To prevent attacks like the one on Polymarket, it is critical to implement Subresource Integrity (SRI) for all third-party JavaScript dependencies. SRI works by adding an integrity attribute to script tags, containing a cryptographic hash of the expected script file. The browser will then fetch the script, compute its hash, and compare it to the one in the integrity attribute. If they do not match, the browser refuses to execute the script. This directly defeats the attack vector, as the attacker's modified JavaScript would have a different hash, causing it to be blocked. This should be a standard practice for any web application that loads resources from external CDNs or third-party domains, providing a last line of defense against a compromise of that third party.
Deploy client-side monitoring solutions to perform web session activity analysis. These tools can detect anomalous script behavior in the user's browser, such as the unexpected modification of DOM elements related to wallet interactions or the hooking of critical JavaScript functions like eth_sendTransaction. By baselining normal application behavior, the system can flag when a third-party script begins performing suspicious actions, such as presenting a fake transaction approval dialog. This provides real-time detection of a frontend compromise, allowing the security team to be alerted, block the malicious script, and warn users, minimizing the financial impact of the attack.
Timeline of Events
The supply chain attack against Polymarket was first reported, leading to user fund losses.
Polymarket confirms the attack details and pledges to fully reimburse the fewer than 15 affected customers.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.