Polymarket: tampered DebugBear RUM script steals crypto

On 29 October 2026 Polymarket, the cryptocurrency-based prediction market platform, halted trading on its international platform, Polymarket.com, for about an hour after a third-party provider was compromised. According to BleepingComputer, SecurityWeek and The Record, the provider is DebugBear, a UK-based website performance monitoring service: its infrastructure served malicious JavaScript that used logged-in users’ sessions to move their assets to attacker-controlled wallets.

Polymarket confirmed the incident, referred it to law enforcement and pledged to reimburse all affected users. It has not named the provider, the number of victims or the amount stolen. According to SecurityWeek, Polymarket’s US platform was not affected.

Timeline

The three outlets agree on the main steps, reconstructed from Polymarket’s status page and public messages (times in UTC):

• 17:50–17:56: according to BleepingComputer’s blockchain analysis, the suspected wallet carries out numerous transactions on Polymarket’s prediction-market token contract;
• 17:59: Hudson Rock spots a Polymarket production build with the commit message chore(polymarket): remove debugbear rum script (#15337), i.e. the removal of the DebugBear integration;
• 18:05: the exchange switches to cancel-only mode and relayer actions are paused;
• 18:37: Polymarket says it has identified and fixed the issue, but halts trading as a precaution;
• 19:05: incident resolved and trading back online.

DebugBear confirmed it is affected by an «ongoing security incident», asked customers of its RUM (Real User Monitoring) product to remove the embed code from their websites and, according to SecurityWeek, brought in specialist incident responders.

How the script worked

RUM services rely on a JavaScript snippet embedded in the customer’s pages, which measures performance in visitors’ browsers. That is exactly why the script runs with the same privileges as the site’s own code. According to Hudson Rock and BleepingComputer, the malicious version was served from cdn.debugbear[.]com/C7xcKKrjUnXK.js and:

1. checked whether the visitor was logged in to Polymarket;
2. read cryptocurrency balances and prediction-market positions to estimate their value;
3. depending on how the account authenticated, sold the positions and moved the proceeds, or transferred the position tokens directly to an attacker-chosen address;
4. converted cryptocurrency into transferable assets using the platform’s own transaction functions.

BleepingComputer, which analysed a copy of the file, reports that the script exchanged data with data.debugbear[.]com to receive instructions and send targeted accounts, wallet addresses, balances and transaction results: the provider’s own infrastructure thus served both for delivery and as a command-and-control channel. Hudson Rock notes that the code reads credential-related material, but that it found no routine sending passwords, seed phrases or private keys: the approach is to reuse the authority already available in the authenticated application.

How the script was tampered with is not yet known. Hudson Rock says it has no evidence of a wider attack on other DebugBear customers.

In our reading, the relevant MITRE ATT&CK techniques are T1195.002 (Compromise Software Supply Chain), T1185 (Browser Session Hijacking), T1071.001 (Web Protocols), T1041 (Exfiltration Over C2 Channel) and T1657 (Financial Theft).

Losses: diverging estimates

The figures do not match and none is official:

• BleepingComputer traced about 28.6 million POL (roughly $2.57 million) transferred from the suspected wallet to three other wallets;
• Hudson Rock saw about $2.19 million at the fallback address hard-coded in the script, stressing that this is not a verified tally;
• according to SecurityWeek, GoPlus estimates about $2.71 million, with an attack path running through 710 deposit wallets and 731 addresses (which do not equal the number of victims), while Arkham data show about $2.65 million at the same address;
• The Record cites more than $2.1 million according to several blockchain security firms.

SecurityWeek also recalls that in June Polymarket disclosed another third-party compromise, with a malicious script injected into its frontend and losses reported at around $3 million.

Impact for European and Italian companies

The case goes beyond cryptocurrency. Any third-party script loaded into a page (performance monitoring, analytics, tag managers, chat, A/B testing) can read and do everything the logged-in user can. In the authenticated areas of banks, e-commerce sites, healthcare portals and SaaS applications, that means personal data, orders, payments and transactional operations.

For NIS2 entities, the providers of these scripts fall under supply chain security: they should be inventoried and assessed like any other ICT supplier. A compromised script that reads data in authenticated pages must also be assessed as a possible personal data breach under the GDPR.

What to do now

1. If you use DebugBear RUM, remove the embed code as the provider advises and search proxy and firewall logs and CSP reports for requests to cdn.debugbear[.]com and data.debugbear[.]com.
2. Inventory the external scripts loaded in production, starting with authenticated pages and those that initiate transactions.
3. Remove from sensitive pages any script they do not need to work: monitoring and analytics rarely need to run where users handle money or data.
4. Enforce a Content Security Policy with script-src and connect-src limited to the domains you need and violation reporting enabled.
5. Where the script is static, host a versioned copy or use Subresource Integrity; for scripts that change often, monitor changes to their content.
6. On the server side, require separate confirmation for high-risk operations (withdrawals, transfers to new recipients) and watch for abnormal bursts of transactions from the same session: a script reusing the session cannot pass a second factor requested at the time of the operation.
7. If you work with cryptocurrency, add the address reported by Hudson Rock to your block lists: 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18.

How ARXDOME helps

ARX Horizon lets you search the public indicators of this incident across threat intelligence sources, and the firewall events collected by ARX Sentry, enriched with threat lists, help you find out whether company workstations and servers contacted the domains used by the script.

Last updated: 30 October 2026