Decoding the world of cybersecurity

Polymarket reveals third-party script compromise

Polymarket says a compromised website monitoring script enabled unauthorised transactions through active user sessions, prompting a $3.9m compensation programme.

Polymarket reveals third-party script compromise
Summary
  • An attacker replaced a third-party monitoring script loaded by Polymarket's website.
  • Malicious code abused active browser sessions to sell positions and transfer funds.
  • Polymarket has committed $3.9m to compensate affected users for direct losses and trading disruption.

A compromised third-party website monitoring script enabled attackers to interfere with active sessions on Polymarket, resulting in unauthorised asset transfers and a $3.9 million compensation programme.

The prediction market operator has detailed the circumstances of its 29 October security incident, confirming that code supplied through an external website performance service was replaced with a malicious version.

The altered script executed when affected users visited the platform and was capable of interacting with their authenticated sessions.

According to Polymarket, the attacker used those sessions to sell positions and move funds from customer wallets without the users’ authorisation.

The company subsequently removed the compromised script, suspended trading temporarily, cleared relevant cached content, and reset active login sessions.

Its compensation programme includes approximately $2.7 million for direct losses and a further $1.2 million associated with the effects of the temporary trading interruption.

Monitoring software became the attack route

Websites frequently load scripts supplied by external services to monitor performance, diagnose loading problems, and understand how users interact with applications.

Such scripts can become deeply integrated into an application’s normal operation because they execute within the browser environment used to display the service.

The permissions available to a particular script depend on how the website is implemented and the controls restricting externally supplied code.

Where a malicious script can interact with sensitive application functions, it may be able to exploit information or permissions associated with an authenticated session.

In Polymarket’s case, the compromised component was associated with website monitoring provider DebugBear.

DebugBear subsequently reported that its preliminary investigation pointed towards a compromise involving its domain registrar. It said the available evidence suggested that a particular customer’s website had been targeted.

The company also stated that it had not identified evidence of compromise within its internal systems, while continuing its investigation.

Those findings remain preliminary and do not establish the complete attack path by which the malicious script was delivered.

Authenticated sessions increased exposure

The attack was particularly consequential because the malicious code operated while customers were already logged into the trading platform.

Authentication controls are designed to establish a user’s identity before permitting access to protected functions. Once a valid session exists, the application may permit a series of actions without requiring the user to repeat the complete login process.

Malicious browser code capable of operating in that context may therefore interact with workflows that would otherwise be restricted to authenticated users.

Polymarket says the script exploited active sessions to execute transactions affecting customer positions and funds.

The incident should not be characterised as evidence that each affected customer’s device, password, or private wallet key was independently compromised.

The documented mechanism concerns hostile code delivered through a website component and its interaction with the application’s authenticated environment.

The distinction is important because the risk is created by the relationship between the website, external code, and session permissions rather than necessarily by a failure of each user’s personal security controls.

Compensation and technical changes

Polymarket says it identified eligible wallets using trading records and blockchain information, allowing most compensation to proceed without individual claims.

As of its reported update, 95% of affected wallets had received full reimbursement.

The company has also introduced stronger integrity checks, monitoring, and restrictions on externally supplied scripts.

These include additional content security controls, script verification, and sandboxing measures intended to limit the consequences of a compromised external component.

The incident has a wider software supply chain dimension because externally hosted scripts are common across business applications.

Analytics, support, advertising, and performance services may all introduce code supplied by organisations outside the website operator’s direct control.

The level of resulting exposure depends on the permissions granted to those components, the integrity protections in place, and the sensitivity of the application’s functions.

Polymarket has contacted law enforcement and continues to investigate the incident, while DebugBear is examining the suspected compromise associated with its service.

The available findings identify a third-party script as the immediate route through which unauthorised transactions occurred. The investigation has not yet established the full identity of the attacker or the complete sequence of the supplier compromise.

×