Global News | November 4, 2026

The Polymarket security incident on October 29, 2026, exposed how a compromised third-party website script could put active trading sessions and user funds at risk. The prediction-market platform subsequently pledged $3.9 million in compensation for affected users, covering reported direct losses and losses associated with trading interruptions.

The compensation commitment includes approximately $2.7 million covering direct financial losses and another $1.2 million intended to compensate traders for losses associated with the platform’s temporary trading interruption. Polymarket said it identified eligible wallets using blockchain and trading data, meaning affected users would not generally need to submit individual claims to receive compensation.

The incident highlights the security risks associated with external scripts embedded in cryptocurrency platforms. Although the malicious code was delivered through a third-party service, it could interact with authenticated users’ active sessions and initiate transactions through the platform’s existing trading functionality.

Polymarket removed the compromised script, temporarily suspended trading, reset active login sessions and introduced additional security controls. The company also referred the matter to law enforcement and began investigating the attacker.

Polymarket Platform Compromise: What Happened on October 29?

The incident became public on October 29, when Polymarket reported unauthorized activity affecting user wallets and temporarily restricted trading on its international platform.

The company’s status updates initially described an investigation into suspicious activity. Trading was placed into a restricted, cancel-only mode, while relayer actions were paused. These measures limited trading activity while the company investigated the unauthorized transactions.

Polymarket subsequently confirmed that a third-party provider whose performance-monitoring script was loaded by its website had been compromised.

The attacker replaced the legitimate monitoring script with malicious JavaScript designed to target people using Polymarket. Because the website loaded the compromised script, the malicious code could execute within users’ browser sessions when they visited the platform. The Polymarket security incident highlights the risks of relying on third-party scripts that execute within a website’s browser environment, particularly when users have active financial sessions.

This was an important distinction. The incident did not require attackers to obtain every affected user’s password or independently compromise each wallet. Instead, the malicious code took advantage of the access and permissions available through an already-active session.

According to Polymarket’s post-incident explanation, users who had the website open during a limited period were exposed to the malicious script. It used their active sessions to sell positions and move funds from their wallets.

The company said the affected third-party script was removed and that the issue was addressed within approximately an hour.

The incident demonstrates how an organization can face a serious security problem through software supplied by an external provider, even when the affected organization’s own website and services are not initially identified as the source of the compromise.

How the Compromised Third-Party Script Stole Funds

The technical mechanism involved malicious JavaScript replacing a legitimate performance-monitoring script.

Website performance-monitoring services commonly collect information about how quickly pages load, how users experience website features and whether technical problems affect visitors. Developers embed scripts from these providers into their websites to obtain performance information without building every monitoring capability themselves.

These integrations are convenient, but they also introduce a security dependency. When a browser loads an external script, that code may execute with access to parts of the website’s environment, depending on how the integration is implemented.

In this case, the attacker took advantage of that relationship.

Security researchers at Hudson Rock examined the malicious JavaScript and described functionality designed to identify accounts, inspect available positions and move assets to an attacker-controlled destination.

The analysis indicated that the code could interact with Polymarket’s trading interface and use the permissions available through an authenticated session.

For some accounts, the malicious script transferred trading positions. For others, it sold positions and moved the resulting funds.

This approach is particularly concerning because it differs from a conventional password-stealing attack. An attacker does not necessarily need to obtain a user’s password or private key if malicious code can manipulate an already-authenticated application session and access its transaction functionality.

The Hacker News reported that researchers found the script could interact with account information and trading-related API functionality stored in the browser. Its analysis also distinguished the use of existing session permissions from the theft of private wallet credentials.

Importantly, Hudson Rock’s analysis did not establish that passwords, seed phrases or private keys were transmitted to the attacker. A malicious transaction request and the theft of a wallet’s underlying private key are different security events.

The Polymarket platform compromise therefore illustrates a broader browser-security problem: trusted website functionality can become dangerous when an external script is replaced with malicious code.

DebugBear Connection: How the Third-Party Provider Was Compromised

The incident was linked in reporting to DebugBear, a company providing website performance-monitoring services.

Polymarket said a third-party provider’s performance-monitoring script had been compromised and replaced. The Record and SecurityWeek reported the connection to DebugBear, although Polymarket’s public post-mortem described the provider without naming it directly.

DebugBear subsequently published preliminary information about its own security investigation.

The company said its DNS records had been compromised through its domain registrar. It also reported that it was temporarily unable to receive email sent to its domain.

According to DebugBear, its initial investigation suggested that the attackers had targeted the website of a specific customer. The company said it had not found evidence that its internal systems were compromised, while emphasizing that its investigation was continuing.

A domain registrar compromise can be significant because control over domain-related records may allow an attacker to redirect users or services to infrastructure under the attacker’s control.

In a website-monitoring integration, this can create a path for malicious content to be delivered through a domain that a customer already trusts.

However, several details remain unresolved. DebugBear has not publicly explained how the attackers obtained access to its domain registrar account, and its preliminary statement did not identify the targeted customer.

The available reporting also does not establish the complete sequence of events that enabled the malicious script to replace the legitimate one.

It is therefore important not to treat the domain registrar findings as a complete forensic explanation of the intrusion. They represent DebugBear’s initial assessment, not a final public investigation report.

$3.9 Million Compensation: How Polymarket Plans to Refund Users

Polymarket’s compensation commitment totals approximately $3.9 million, divided into two principal categories.

The first component covers direct financial losses resulting from the attack. The company allocated approximately $2.7 million to reimburse affected traders whose positions or funds were taken through the malicious script.

The second component covers losses associated with the temporary trading interruption. Polymarket allocated another $1.2 million to compensate users affected by the shutdown and related trading outcomes.

This distinction matters because the total compensation figure should not be described as the amount stolen by attackers.

The approximately $2.7 million figure represents the direct-loss component, while the additional amount addresses consequences associated with the platform’s temporary suspension of trading.

Polymarket said it identified eligible wallets using on-chain information and its trading data.

According to the company’s statement, users did not need to submit claims or support tickets as a general requirement for the company to identify eligible accounts.

The Record reported that Polymarket had not disclosed the total number of individual people affected. However, the company’s technical and compensation updates provided information about affected wallets.

SecurityWeek reported that Polymarket identified 726 affected wallets. The company said that by October 30, all but 37 had been made whole, with the remaining accounts being checked and paid.

Polymarket also said that approximately $1.2 million was being distributed to roughly 5,500 wallets affected by the trading pause or the malicious handling of positions.

The company provided a way for users who believed their compensation was incorrect or who had not received an expected payment to request a review.

The compensation arrangement is notable because it extends beyond the direct theft of funds. It also recognizes that a trading platform’s security interruption can affect users whose assets were not necessarily transferred by an attacker.

However, the $3.9 million commitment should not automatically be interpreted as confirmation that every possible financial consequence has been independently assessed. The public reporting does not provide a complete breakdown of every individual claim or the final settlement status of every account.

Why the Trading Interruption Increased User Losses

The financial impact of a platform security incident can extend beyond the funds directly taken by an attacker.

When a trading service suspends operations, users may lose access to opportunities to buy, sell or close positions. This can become especially significant in prediction markets, where contracts are linked to events and their values can change rapidly.

Polymarket’s temporary trading suspension was a precautionary response intended to prevent further unauthorized activity while the company investigated the compromise.

However, the interruption also created a separate category of potential losses.

For example, a user holding a position might have intended to sell it before a market closed or before its value changed. If trading becomes unavailable, that user may be unable to carry out the intended transaction.

Similarly, users whose positions were sold or transferred by malicious code may experience financial consequences beyond the immediate value of the assets moved.

Polymarket’s compensation plan addressed some of these situations by including payments for trading-related losses associated with the interruption.

This is why the additional compensation matters. It recognizes that restoring stolen assets alone may not fully address the financial consequences experienced by platform users.

The company’s decision also illustrates a broader incident-response challenge for financial and cryptocurrency services: security measures that stop an attack can temporarily interrupt legitimate activity, creating a second set of operational and customer-protection responsibilities.

How Polymarket Responded to the Security Incident

Polymarket’s response involved removing the compromised dependency, restricting platform activity and reviewing the security of its existing integrations.

The company said it removed the malicious third-party script and cleared its caches. It also reset active login sessions to reduce the possibility that previously authenticated sessions could continue to be abused.

Trading was temporarily paused while the issue was addressed. Once the company believed the malicious script had been removed and the platform was safe to reopen, trading resumed.

Polymarket also said it had redeployed the third-party provider’s script with additional security controls.

These measures included stronger Content Security Policy protections, explicit version pinning, sandboxing and continuous monitoring and verification.

Content Security Policy, commonly known as CSP, is a browser security mechanism that allows website operators to define which sources are permitted to load particular types of content.

It can help reduce the risk of unauthorized scripts executing on a website, although its effectiveness depends on how carefully the policy is designed and maintained.

Version pinning is another protective measure. It helps ensure that a website loads an expected version of a dependency rather than automatically accepting an unexpected replacement.

Sandboxing can restrict the capabilities available to embedded content, reducing the potential impact if an external component behaves maliciously.

These measures are particularly relevant to services that handle authenticated sessions, financial transactions or other sensitive user activity.

Polymarket also confirmed that it had referred the incident to law enforcement and was conducting an investigation into the threat actor.

The company has not publicly identified the attacker or provided a complete account of how the malicious code was introduced.

What the Incident Reveals About Third-Party Script Security

The Polymarket platform compromise demonstrates how third-party integrations can become an important part of an organization’s security perimeter.

A website may rely on external providers for analytics, advertising, customer support, performance monitoring and other functionality. Each integration introduces code or services that may influence the security of the website.

If a provider is compromised, attackers may attempt to use that relationship to reach the provider’s customers.

This is one form of supply-chain risk. Instead of attacking every target independently, an attacker may compromise a service that is trusted by multiple organizations.

The risk is particularly serious when external scripts execute on pages where users are authenticated or can perform sensitive transactions.

A malicious script operating in that environment may be able to interact with information and functions available to the browser session.

Organizations should therefore consider more than whether a third-party provider is reputable. They should also examine what permissions its scripts receive, which pages load them and whether their content can be independently verified.

Several security practices can help reduce exposure:

1. Minimize third-party scripts

Organizations should avoid loading unnecessary external scripts, particularly on pages used for authentication, account management and financial transactions.

2. Use Subresource Integrity where appropriate

Subresource Integrity, or SRI, allows browsers to verify that a fetched resource matches an expected cryptographic hash. If the content changes unexpectedly, the browser can reject it.

3. Apply restrictive Content Security Policies

A carefully designed CSP can reduce the sources from which executable scripts are permitted to load. Policies should be reviewed regularly rather than treated as a one-time configuration.

4. Isolate external functionality

Where possible, third-party content should operate in restricted environments with limited access to sensitive application functions.

5. Monitor changes to dependencies

Organizations should monitor external scripts and dependencies for unexpected modifications, domain changes or unusual delivery behaviour.

6. Protect authenticated sessions

Platforms should evaluate what actions a script can initiate through an active session and whether sensitive transactions require additional authorization.

These measures are not limited to cryptocurrency exchanges. Financial services, e-commerce platforms, online marketplaces and other organizations that rely on browser-based transactions face similar risks.

What Users Should Understand About Account and Wallet Protection

The incident also offers lessons for people using cryptocurrency platforms and other online financial services.

Users should understand that a secure password does not eliminate every account-related risk. An authenticated browser session can itself become a valuable target if malicious code is able to interact with the website.

Users should pay attention to unexpected transaction requests, wallet-signing prompts and changes to account activity.

Any request to approve an unfamiliar transaction should be treated cautiously. Users should also avoid assuming that a transaction is legitimate simply because it appears while they are using a familiar website.

Where available, account activity notifications and transaction-history reviews can help users identify unexpected actions.

It is also important to keep browsers and operating systems updated and avoid installing untrusted browser extensions.

However, users cannot independently prevent every supply-chain attack. In this incident, the malicious code was delivered through a service integrated into the platform itself. The responsibility for securing those integrations therefore rests substantially with the platform and its service providers.

Polymarket’s compensation commitment acknowledges that responsibility by covering both direct losses and certain consequences of the platform’s interruption.

A Wider Security Challenge for Cryptocurrency Platforms

The incident comes amid continuing concerns about the security of cryptocurrency services and the complex relationships between platforms, wallet providers, software vendors and external infrastructure.

Cryptocurrency platforms frequently depend on multiple technologies working together. These may include blockchain networks, browser-based trading interfaces, wallet-signing mechanisms, authentication services, cloud infrastructure and external monitoring tools.

A weakness in one component can affect the wider service, even if the other components are functioning as intended.

The Polymarket incident is particularly instructive because the reported attack did not depend on a conventional compromise of every individual user’s credentials. Instead, the attacker exploited a trusted software dependency and the permissions available within active trading sessions.

This makes the incident relevant to organizations that rely on externally hosted JavaScript and other browser-delivered dependencies.

The compensation response is also significant. It demonstrates how incident response can involve financial remediation, operational recovery, technical investigation and communication with affected users at the same time.

The company’s $3.9 million commitment is a substantial response to the reported losses, but compensation does not resolve every security question raised by the incident.

The initial compromise of the third-party provider, the identity of the attacker and the full technical path used to replace the script remain subjects of investigation.

Conclusion: Compensation Does Not Replace Stronger Platform Security

Polymarket’s decision to return approximately $3.9 million to affected traders addresses an important part of the October 29 security incident. The company has committed funds to cover both direct losses and certain financial consequences associated with the temporary trading suspension.

Yet the incident also exposes a broader challenge for online financial platforms: trusted third-party software can become a route into authenticated user environments.

The attack demonstrates why organizations must monitor external dependencies, restrict script permissions, verify software integrity and protect sensitive transaction functions from unauthorized activity.

For users, it reinforces the importance of reviewing transaction activity and treating unexpected signing requests with caution. For platform operators, it shows that security cannot stop at the boundaries of their own infrastructure.

The investigation into the Polymarket incident remains important not only for determining how the attacker gained control of the external script, but also for understanding how similar supply-chain weaknesses could affect other services.

Source note: This report draws on Polymarket’s official incident updates and post-mortem, reporting by The Record from Recorded Future News, SecurityWeek and The Hacker News. Technical findings about the malicious script are attributed to the security researchers cited in those reports. DebugBear’s explanation of its domain registrar compromise is identified as an initial assessment, and the complete intrusion path and attacker identity have not been publicly established.

NewsFlayer — Your trusted source for cybersecurity news, digital threats and technology developments.