Polymarket has disclosed that attackers used malicious code on its website to sell some signed-in traders’ positions and move funds to attacker-controlled wallets on 29 October. According to the report, the malicious code replaced a page-speed script loaded from an external provider, turning a performance monitoring dependency into an attack path.

Polymarket said it is refunding about $2.7 million to 726 affected wallets. The reported blockchain activity cited in the source indicates that roughly $2.64 million in crypto reached attacker-controlled addresses. While the incident took place in a crypto trading context, the underlying lesson is broader: externally loaded website scripts can become a serious business security weakness.

What happened

Based on the reported details, the attack did not rely on a direct breach of every affected user account. Instead, malicious code was introduced through a third-party script used on the website. In this case, the replaced script was reportedly associated with page-speed monitoring.

This type of incident is often described as a web supply-chain attack. A company may secure its own application code, but if its site loads JavaScript from outside services for analytics, chat, A/B testing, consent tools, performance monitoring or marketing tags, those external dependencies can also execute in users’ browsers. If one of those dependencies is altered, attackers may be able to manipulate transactions, capture data or change on-page behaviour without compromising the core platform directly.

Why it matters for European businesses

The practical relevance goes well beyond crypto platforms. Many European businesses depend on third-party scripts to run websites, e-commerce stores and marketing stacks. These scripts often come from analytics vendors, ad platforms, tag managers, personalisation tools, payment widgets and customer support software.

If one of those external scripts is compromised, the consequences can include:

• Customer account abuse where signed-in sessions are manipulated through the browser
• Payment or checkout interference affecting online stores and transaction flows
• Data exposure if forms, personal data or behavioural data are captured
• Brand and trust damage if customers are harmed while using the company website
• Regulatory and contractual risk if personal data processing, security controls or vendor oversight are found to be inadequate

For businesses operating in Europe, third-party web dependencies also overlap with broader governance issues around GDPR, vendor management and incident response. Even when a compromised script comes from an outside supplier, customers and regulators are likely to focus first on the business whose website delivered the harmful code.

Who may be affected

The risk is especially relevant for organisations that rely heavily on browser-based tools and external services, including:

• E-commerce companies using payment, tracking, review, chat and personalisation scripts
• Marketing teams deploying multiple tags through tag managers and campaign platforms
• SMEs with limited internal security review of website dependencies
• SaaS platforms whose users perform sensitive account actions in the browser
• Digital agencies and web teams responsible for selecting and integrating third-party website services

Any business that lets external JavaScript run on important pages such as login, checkout, account settings or admin panels should treat this as a material risk scenario.

What companies should consider

European businesses do not need to remove every third-party tool, but they should reduce unnecessary trust in externally loaded browser code.

• Review third-party scripts and identify which services load JavaScript on critical pages
• Limit scripts on sensitive flows such as authentication, checkout, payment confirmation and account changes
• Assess vendor security for analytics, monitoring, marketing and support tools that execute in the browser
• Use technical controls such as content security policies, subresource integrity where feasible, and tighter script governance
• Monitor changes in front-end code and third-party resources so unexpected modifications can be detected quickly
• Prepare incident response for browser-based compromise scenarios, including customer communication and supplier escalation
• Revisit tag management practices if marketing or agency partners can deploy scripts without strong change control

The Polymarket case is a useful reminder that performance, analytics and marketing tools are not just operational add-ons. In some environments, they have enough access in the browser to become a direct path to fraud, data loss or customer harm if compromised.