Polymarket Halted Trading After a Hijacked DebugBear Script Drained $2.73 Million

Polymarket halted trading on October 29 after a compromised third-party monitoring script drained $2.73 million from hundreds of user accounts, in one of the clearest demonstrations yet that a crypto platform’s weakest point may not be its smart contracts at all. The attack did not break into Polymarket’s trading contracts, its order book or its exchange engine. It rode in through a small piece of code the site loaded from an outside vendor, turned ordinary logged-in browser sessions into a theft tool, and executed in approximately one hour. For users, the episode is a lesson in a threat that feels abstract until it arrives: the supply-chain attack, where trust placed in a vendor becomes the attacker’s way in.

The basic facts are not in dispute, though the precise account count varies slightly between reports and is worth stating plainly. The week-in-review account of the incident puts the loss at $2.73 million from 737 accounts. Polymarket’s own accounting, reported by Bankless, puts the theft at $2.7 million across 726 wallets, with a further $1.19 million for roughly 5,500 wallets that lost out during the trading pause or had positions taken, bringing the total repayment to $3.9 million. What matters more than the exact count is the mechanism, because it is the mechanism that other platforms and users need to guard against.

What a monitoring script is, and why it was on the page

DebugBear is a UK-based website performance company. Its real user monitoring product, known as RUM, is a small script a site owner embeds on every page to measure how fast pages load for visitors. Polymarket embedded that script so it could track page speed, a routine practice across the web: performance monitoring, analytics and chat widgets are all delivered as third-party scripts that a site loads from a vendor’s servers. The critical point is that such a script, once loaded, runs in every visitor’s browser with the same access as the site’s own code. It is not sandboxed away from the page it measures. It can read what the page can read and, in many setups, interact with the page’s own functions.

That trust is normally harmless, because the vendor’s script normally does exactly what it promises: measure timings and send them back. The danger appears when the file the vendor serves changes. On October 29, the file served from DebugBear’s content delivery address was replaced with malicious code. DebugBear said its DNS records were compromised through its domain registrar, and it told customers using its monitoring product to remove the embed code. The attacker did not need to hack Polymarket: compromising the vendor reached every user who loaded the page while the poisoned file was served.

How the theft worked, step by step

The malicious file was small, around 15,187 bytes of minified JavaScript, none of which measured performance. All of it targeted Polymarket. Technical analyses reconstruct a consistent sequence. The script read account details that Polymarket keeps in the browser for a logged-in session, including whether the user had signed in with an email account or a self-custody wallet, the user’s proxy wallet address, and the trading API credentials the order book issues to a session. It then took control of Polymarket’s own trading client on the page, borrowing the platform’s own tools to move funds through the same channels as legitimate trades.

The path then split by login type, and the split explains why losses were so uneven. For accounts signed in with their own crypto wallet, the script moved positions straight to the attacker’s wallet. For accounts signed in by email, which sign transactions without asking the user each time, it sold positions at successively worse prices and then moved the money out. Cash balances were swapped into POL and sent through Polymarket’s gasless relayer. The first stolen funds reached the attacker’s wallet at 17:10:23 UTC, in Polygon block 96,392,296, and by 18:19:58 UTC the attacker’s address held 28,636,284 POL, about $2.64 million at the prevailing price. The losses were concentrated: four accounts that each lost over $100,000 made up roughly 43 percent of the haul.

Polymarket’s response unfolded over the same hour. The platform posted its first status update about unauthorised activity in user wallets at 17:38 UTC, put its international exchange into cancel-only mode at 18:05 UTC with relayer actions paused, and shipped a build at 17:59 UTC whose commit message recorded removing the DebugBear monitoring script. Trading resumed at about 3 p.m. Eastern time, roughly an hour after the halt. Its separate US platform was not affected. Polymarket said one of its third-party providers had been compromised, that it had referred the incident to relevant law enforcement, and that anyone affected would be made whole. Bankless reported that by the Friday morning after the attack, 689 of the 726 affected wallets had been refunded in full, with the remaining 37 being paid as each one was verified. The reporting gives no further specifics on the attacker’s identity or recovery of the stolen funds themselves. Readers should note that the account of those repayment terms comes from user-shared material, not from a Polymarket statement quoted in the reporting, and it is attributed as such.

Why the platform’s own security policy did not stop it

One of the most instructive findings from the technical analysis concerns Polymarket’s Content Security Policy, the browser mechanism that restricts which sources a page may load code and data from. Polymarket had an enforced policy, and a long one, but it necessarily allowed DebugBear’s content delivery domain in its script sources, because the monitoring product could not work otherwise. It also allowed the data domains the drainer touched, including Polymarket’s own domains and the infrastructure providers its frontend relies on. The malicious file was not smuggling data to an exotic destination; it was using the site’s own trading client, its own relayer and its own API credentials.

A pattern, not an isolated accident

Context makes the incident harder to dismiss as bad luck. In May, an attacker drained roughly $600,000 from a dormant Polymarket operational wallet using a leaked private key. In June, Polymarket confirmed that a compromised third-party vendor had injected a malicious script into its frontend for some users, with an estimated loss near $3 million, which Polymarket said it would refund in full. October’s attack is therefore Polymarket’s second frontend drain in four months and its third security incident since May, and the week’s coverage counts it as the third third-party vendor compromise affecting a major crypto platform in ten months. Three in ten months, across the industry, describe a structural exposure: modern web applications are assembled from dozens of third-party components, and each component is a potential carrier for code the site owner never wrote and may never inspect.

Lessons for users: approvals, extensions and verifying domains

For ordinary users, the most useful lessons are practical and unglamorous. First, treat token approvals as live permissions, not as one-time paperwork. Many DeFi interactions ask a wallet to approve a contract to spend tokens on the user’s behalf, and those approvals persist until revoked. Reviewing approvals regularly and revoking ones no longer needed limits what a compromised session can move. Second, treat browser extensions with the same suspicion as third-party scripts, because an extension with broad page access can read and alter the same session data the Polymarket drainer exploited.

Third, verify domains and sessions before acting, especially during fast-moving events. The drainer operated inside the genuine polymarket.com page, so domain checking alone would not have saved users in this case, and honesty requires saying so. But domain verification remains essential against the far more common attack, the lookalike site, and it should be paired with a habit that would have helped here: pausing when a trusted site behaves strangely. Positions selling themselves, balances moving without instruction, or a sudden flood of complaints on a platform’s community channels are signals to stop, disconnect and wait, not to click through and investigate while still logged in.

Fourth, prefer hardware wallets and explicit transaction confirmation for meaningful sums, and be wary of login methods that sign transactions without asking. The October attack’s split by login type is the clearest evidence for this: email-based logins that sign silently allowed the drainer to sell positions at worsening prices without any user interaction, while wallet-based sessions still required the platform’s own client to move funds but through a different path. Keeping only trading capital connected to any single platform, and the bulk of holdings in a separate wallet that is not logged into trading frontends, applies the same principle at the portfolio level.

Frequently asked questions

What happened on Polymarket on October 29?

A monitoring script from the vendor DebugBear, embedded on Polymarket’s site, was replaced with malicious code that drained about $2.73 million from roughly 730 accounts in approximately one hour. Polymarket halted trading on its international platform and removed the script the same day.

What is a supply-chain attack in this context?

It is an attack that reaches users through a trusted third party rather than through the platform itself. Here, compromising DebugBear’s distribution channel put hostile code onto Polymarket’s genuine page, where it ran with the same access as Polymarket’s own code.

Did the attackers break Polymarket’s smart contracts?

No. The conditional tokens contract, the order book and the exchange worked as designed. The theft used the site’s own trading client, API credentials stored in the browser, and its gasless relayer to move funds through legitimate channels.

Were users repaid?

Polymarket said anyone affected would be made whole, and Bankless reported $3.9 million returned in total: about $2.7 million to 726 affected wallets plus $1.19 million to roughly 5,500 wallets affected by the trading pause. By Friday morning, 689 of 726 wallets were reported fully repaid, with the rest paid as verified.

How can users protect themselves against a similar attack?

Review and revoke token approvals regularly, keep browser extensions minimal, use hardware wallets with explicit confirmation for meaningful sums, verify domains, and keep only trading capital connected to any single platform. No measure is foolproof, but together they limit what a compromised page can reach.

Source: Altcoin Investor; Bankless; DeFi Prime

Related reading on MM Crypto Analysis Web

• DeFi Yields Swung Violently in the Week of October 25 to November 1
• Binance Hackers Used DeFi Receipt Tokens to Dodge Stablecoin Freezes
• THORChain Pause After Ethereum Reorg Double-Refunds 10 ETH Deposit

More in DeFi on MM Crypto Analysis Web.