A small script became the attack surface
Polymarket’s latest public account describes the October 29 incident as a compromise of a third-party performance-monitoring script loaded on Polymarket.com, not as a breach of its core trading engine or smart contracts . The company said the attacker replaced that trusted script with code built specifically to target Polymarket users who had the site open during a short window that afternoon . For affected signed-in traders, the malicious code used the authority already present in the browser session to sell positions and move funds out of wallets .
The financial scale is now clearer than it was in the first hours of the outage. The Hacker News reported on November 1 that Polymarket is refunding about $2.7 million to 726 affected wallets, while blockchain records showed roughly $2.64 million in crypto reaching the attackers’ wallet in under an hour . Polymarket’s own postmortem says the company is returning $3.9 million in total: the $2.7 million tied to the attack plus another $1.2 million for pause-related losses and goodwill coverage .
That second number matters. Polymarket was not only dealing with the direct theft; it also had to compensate traders whose markets moved or resolved while trading was paused. In the company’s wording, reimbursement covers positions taken during the attack, slippage caused by forced sales, and certain losses during the pause or immediately after trading reopened .
Timeline: less than an hour, real money gone
The attack window was short, but it was long enough. Ohey’s technical reconstruction says the DebugBear real-user-monitoring script loaded by Polymarket was replaced with a wallet drainer, with first funds reaching the recipient wallet at 17:10:23 UTC on October 29 and the Polymarket build removing the script at 17:59:20 UTC . The same analysis says the recipient wallet took in 28,636,284.45 POL and positions from 33 deposit wallets between 17:10 and 18:02 UTC, then forwarded the assets to downstream wallets by 18:38 UTC .
Polymarket’s status page shows the incident as a major outage affecting the web app and account access from 17:38 to 18:15 UTC, with the major outage period ending at 18:06 UTC . The Associated Press reported that trading on Polymarket’s international platform was paused for about an hour and resumed Thursday afternoon, after the company said it had identified and fixed the issue . Polymarket also said it referred the matter to law enforcement in the United Kingdom, where DebugBear is based .
The platform’s incident response was straightforward but disruptive: remove the compromised vendor script, clear caches, pause trading and relayer actions, reset active login sessions, and reopen only after the site was clean . Polymarket said that, as of its October 30 postmortem, 95% of affected wallets had been refunded in full . The Hacker News later reported that 689 of 726 wallets had been fully refunded by October 30, with the remaining 37 being paid as they were checked .
How the drainer worked
This was a client-side supply-chain attack. The malicious code did not need to crack a password, steal a seed phrase, or exploit a smart contract; it ran inside the browser context of users already logged into Polymarket . Ohey’s analysis says the script targeted Polymarket alone, reading Polymarket storage keys, calling Polymarket APIs, and searching the page for Polymarket’s trading client .
The mechanics are important because they explain why normal server-side defenses can miss this type of attack. The drainer looked for local storage entries holding account and trading context, then walked the page’s React component structures to find the live trading client and signer . Once it found the signer, it used Polymarket’s own relayer path to submit transactions . In other words, the malicious dependency borrowed the same browser-side tools the legitimate site already used.
The behavior differed by account type. The Hacker News reported that, for users logged in with their own crypto wallets, the code tried to move prediction-market positions directly to the attackers’ address; for email-login accounts, it sold positions at progressively worse prices and then moved the proceeds out . Ohey likewise found that browser-wallet accounts were targeted with batch transfers of qualifying positions, while email-login accounts saw positions sold through fill-and-kill sell orders before cash was swept .
The point is not that Polymarket users all signed one obvious malicious transfer. The more uncomfortable lesson is that a trusted script, once compromised, can interact with a live web application as if it were part of the application. Every host the drainer called apart from DebugBear’s own infrastructure appeared in Polymarket’s content security policy, meaning the requests fit within what the site normally allowed .
DebugBear, DNS, and the supply-chain lesson
DebugBear’s role in the incident is central because its real-user-monitoring product was the delivery channel. The Associated Press reported that DebugBear posted it was affected by an ongoing security incident and advised customers using one of its products to remove the embed code from their websites . The Hacker News reported that DebugBear said its DNS records were compromised through its domain registrar, that early findings indicated the attack targeted one customer’s website, and that it had not seen signs of a break-in to its own systems while the investigation continued .
Ohey’s reconstruction supports the idea that the script URL stayed familiar while the code behind it changed. The clean DebugBear file had been served earlier from Google Cloud Storage, while during the incident a different server answered for DebugBear hostnames and served the 15,187-byte drainer . That is the nightmare version of third-party JavaScript risk: the browser loads the same vendor URL the site already trusts, but the payload has become hostile.
Polymarket says it is redeploying third-party scripts with additional integrity controls, including stronger content security policy settings, explicit version pinning, sandboxing, continuous monitoring, and verification . Those measures will not erase the incident, but they point to the right control family. A financial web app cannot treat analytics, monitoring, chat, tag managers, and page-speed scripts as harmless decoration. If they run in the same page as wallets, sessions, signers, and trading clients, they are part of the financial attack surface.
Why this episode matters beyond Polymarket
The attack is a reminder that fintech security is no longer only about backend systems, smart contracts, authentication, or custody. It is also about what executes inside a user’s browser after login. A tiny dependency added for performance telemetry can become a privileged actor if it runs beside account state and transaction tools.
For traders, the immediate practical message is narrow: Polymarket says no claims or tickets are needed for identified eligible wallets, but it links a form for users who believe the refund amount is wrong or who think they should have received a payment . For platforms, the broader message is harsher. Every third-party script needs inventory, ownership, change detection, integrity controls, isolation where possible, and a kill switch that can be activated quickly.
The Polymarket attack did not need a cinematic breach of a fortress. It needed a trusted dependency, a live session, and a browser with too much authority. The script loaded, and the money moved.
Comments
Be the first to comment.