In January 2025, Polymarket users experienced a significant security breach when $3 million in cryptocurrency vanished from their wallets. The culprit? Malicious JavaScript injected through a third-party vendor, transforming the platform's frontend into a phishing tool.
This was not a new exploit or a zero-day vulnerability. It was a supply-chain compromise that every security team should be prepared to defend against—but many are not.
What Happened
Attackers compromised a third-party vendor that Polymarket used for frontend functionality. They injected malicious scripts into the platform's web interface. When users accessed Polymarket, these scripts executed in their browsers, stealing credentials and initiating unauthorized transactions. According to PeckShield's analysis, the attack resulted in approximately $3 million worth of PayonUSD being stolen. The attackers swapped the stolen funds for 1,893 Ether and then bridged assets from Polygon to Ethereum to obscure the trail.
Polymarket has committed to reimbursing affected users.
Timeline
The exact timeline is not fully detailed in public reports, but the attack followed this pattern:
- Initial compromise: Attackers accessed the third-party vendor's infrastructure.
- Script injection: Malicious code was inserted into the vendor's delivery pipeline.
- Distribution: Polymarket's frontend served the compromised scripts to users.
- Execution: Users' browsers ran the malicious code during normal platform interaction.
- Exfiltration: Attackers drained wallets and swapped assets for Ether.
- Laundering: Funds were bridged from Polygon to Ethereum.
- Detection: The attack was discovered after user reports of unauthorized transactions.
Which Controls Failed or Were Missing
Subresource Integrity Validation
Polymarket's frontend loaded third-party scripts without integrity checks. Without these checks, the platform could not detect modifications to the scripts. Every user who loaded the page executed the malicious payload.
Vendor Security Assessment
The attack highlights deficiencies in vendor risk management. Your team should consider:
- Did Polymarket audit the vendor's security controls before integration?
- Were there contractual security requirements?
- Did the vendor maintain SOC 2 Type II attestation?
- Was there ongoing monitoring of the vendor's security posture?
Content Security Policy
A properly configured Content Security Policy (CSP) would have restricted script execution to known-good sources and prevented inline script execution. The absence of an effective CSP allowed attackers unrestricted access to the browser context.
Runtime Monitoring
The platform lacked effective detection for anomalous transaction patterns. Unauthorized transfers totaling $3 million should trigger automated alerts before completion.
Incident Response Preparation
The delay between attack execution and public disclosure suggests detection relied on user reports rather than internal monitoring. Your incident response plan should include:
- Automated transaction monitoring with defined thresholds
- Vendor compromise scenarios in your playbook
- Pre-approved communication templates for breach notification
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.4.3
"All payment page scripts that are loaded and executed in the consumer's browser are managed as follows:
- A method is implemented to confirm that each script is authorized
- A method is implemented to assure the integrity of each script
- An inventory of all scripts is maintained with written justification for why each is necessary"
To prevent attacks like the one on Polymarket, you need:
Script inventory: Document every third-party script, its purpose, and its source.
Integrity validation: Implement Subresource Integrity (SRI) hashes for all external scripts.
Authorization verification: Maintain a whitelist of approved script sources.
OWASP ASVS v4.0.3 Section 14.2
Verification requirements for third-party components include:
- Components from trusted sources over secure channels
- Signed components with validated signatures
- Inventory of third-party libraries and components
- Reduction of attack surface by removing unused dependencies
ISO/IEC 27001:2022 Control 5.19
"Information security in supplier relationships" requires:
- Security requirements defined for supplier relationships
- Regular review of supplier service delivery
- Managing changes to supplier services
- Monitoring and review of supplier security practices
Lessons and Action Items for Your Team
Implement Subresource Integrity Today
Add SRI hashes to every external script tag:
<script src="https://vendor.example/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
crossorigin="anonymous"></script>
If the vendor's file changes, the browser refuses to execute it. This breaks your site—but it also stops the attack.
Build a Vendor Risk Program
For every third-party dependency:
- Require SOC 2 Type II reports annually
- Review their incident response history
- Define security requirements in contracts
- Establish notification requirements for security events
- Conduct annual security assessments for critical vendors
Deploy Content Security Policy
Start with report-only mode to identify violations:
Content-Security-Policy-Report-Only:
script-src 'self' https://trusted-cdn.example;
report-uri /csp-violation-report
Monitor violations for two weeks, then enforce. Yes, this will break things. Fix them.
Monitor Transaction Patterns
Define normal transaction behavior:
- Typical transaction size by user segment
- Expected transaction frequency
- Geographic patterns
- Device fingerprint consistency
Alert on deviations. A user who normally trades $500 suddenly initiating a $50,000 transfer deserves immediate review.
Test Your Vendor Compromise Scenario
Run a tabletop exercise next quarter:
- Scenario: Your primary payment widget vendor is compromised
- Questions: How do you detect it? How quickly can you remove the compromised code? How do you notify users? What's your legal notification timeline?
If you can't answer these in the exercise, you won't answer them during an actual incident.
Separate Authentication from Third-Party Context
Never handle authentication or transaction signing in a context that loads third-party scripts. Use a separate, isolated page with no external dependencies for sensitive operations. The attack surface for your transaction signing flow should be zero third-party code.
The Polymarket incident wasn't sophisticated. It was preventable with controls that should already be standard practice. The question isn't whether your vendors will be compromised—it's whether you'll detect it before your users pay the price.
