A reported supply chain attack connected to website monitoring code has been linked to losses of more than $2 million from Polymarket users, according to SecurityWeek. The reported attack was designed to hijack logged-in sessions and siphon funds, highlighting a familiar but serious risk for businesses that rely on third-party scripts in websites and web applications.

What happened

SecurityWeek reported that malicious code linked to a website monitoring tool was used in an attack affecting Polymarket traders. Based on the report, the code targeted users with active logged-in sessions, allowing attackers to hijack those sessions and drain funds.

This is described as a supply chain attack, meaning the compromise was introduced through a third-party component rather than by directly breaching each victim individually. In practice, that can make website monitoring tools, analytics scripts, customer support widgets and other embedded services potential attack paths if they are tampered with.

Why it matters for European businesses

Even though the reported incident involves a prediction market platform rather than a typical SME website, the security lesson is broadly relevant. Many European companies depend on externally hosted JavaScript and SaaS integrations for performance monitoring, analytics, marketing, consent tools, chat, payments and customer experience features.

If one of those components is compromised, attackers may be able to inject code into a business website without breaching the company’s own core systems first. That can lead to account takeover, session theft, payment fraud, malicious redirects, data collection or abuse of authenticated user actions.

For businesses operating e-commerce services, portals, customer dashboards or admin interfaces, session hijacking is especially important. If a user is already logged in, malicious browser-side code may be able to misuse that authenticated session. The business impact can include financial losses, customer trust damage, incident response costs and possible regulatory scrutiny if personal data is exposed.

Who may be affected

• E-commerce businesses using multiple third-party scripts for payments, analytics, A/B testing or customer support
• SaaS providers with logged-in user dashboards and browser-based workflows
• Marketing teams that add tracking, optimisation or campaign tools to websites
• IT and web teams responsible for tag managers, frontend dependencies and website security controls
• Regulated businesses that must assess supplier risk and protect user accounts and digital services

What companies should consider

• Review third-party scripts: Identify which external JavaScript, monitoring tools and embedded services run on business-critical pages, especially login, checkout and account areas.
• Limit script access on sensitive pages: Consider whether all marketing, analytics or monitoring code is necessary where users authenticate, manage payments or access sensitive data.
• Strengthen supply chain oversight: Include security review, vendor due diligence and change monitoring for third-party web tools and frontend dependencies.
• Use technical safeguards where feasible: Controls such as content security policies, integrity checking and tighter permission design can reduce some script-related risks, although effectiveness depends on the implementation.
• Monitor for unusual session activity: Look for suspicious account behaviour, unexpected transaction flows or anomalous actions from authenticated sessions.
• Prepare an incident response path: Ensure teams can quickly disable third-party code, rotate credentials or tokens where relevant, notify users when needed and investigate potential browser-side compromise.

The reported attack is another reminder that website security is not only about servers and passwords. For businesses that depend on modern web stacks, third-party code is part of the attack surface and should be treated as such.