Polymarket Hack: How a Hijacked DebugBear Script Drained $2.7M

In the Polymarket hack, the script’s URL never changed. The code behind it did. Here’s how a trusted monitoring tool drained 737 accounts in an hour, and how to catch the next one.

On October 29, 2026, attackers drained about $2.73 million from 737 Polymarket accounts in roughly an hour, without touching a single smart contract or Polymarket server. They found their way in through a website performance-monitoring script that Polymarket loaded on its own pages.

This was the prediction market’s second third-party breach in four months. In June, a compromised frontend vendor was the root cause of around $3 million in losses. In both cases, Polymarket was caught off guard by third-party JavaScript running in users’ browsers and doing things it shouldn’t.

What happened: a monitoring script turned against its host

Security researchers traced the attack to a JavaScript file served from DebugBear, a U.K.-based website performance-monitoring firm, via its real user monitoring (RUM) snippet on Polymarket’s site. DebugBear confirmed a security incident the same day and told RUM customers to pull its snippet from their websites. It later said attackers had compromised its DNS records through its domain registrar, that it had found no sign its own systems were breached, and that early findings pointed to a single targeted customer website.

That detail matters. Each DebugBear customer loads its own copy of the script, and the file swapped out was Polymarket’s. The address on Polymarket’s pages never changed, but after the DNS change, a different server answered at that address. Instead of measuring page speed, the swapped file went looking for logged-in Polymarket users.

Once it found an active session, the code read account data stored in the browser, including trading API keys, located the app’s own trading tools and transaction signer, and inspected the victim’s portfolio. Then, depending on the account type, it either sold positions and moved the proceeds out or sent position tokens directly to an attacker-controlled address. Because every transaction was signed from a legitimate session and sent through Polymarket’s own relayer, the smart contracts processed them as normal. In a sample of 30 drains, Bitquery found each approval was used 3 to 7 seconds after it was created. That speed points to automation, not people clicking through hundreds of accounts. Hudson Rock, which analyzed the file, found no routine for stealing passwords, seed phrases, or private keys. The script didn’t need them: it reused the authority the logged-in user already had.

Polymarket hack timeline

The timeline, as reconstructed by researchers and blockchain analytics firm Bitquery:

Traders reported six-figure losses on X as the drain unfolded. Loss estimates range from about $2.6 million to $2.73 million, depending on the firm doing the counting, and Polymarket ties $2.7 million to the attack. Bitquery counted 985 withdrawals. Four accounts made up about 43% of its total; the single largest withdrawal was $358,369, and 276 accounts lost under $100 each. The script hard-coded the attacker’s wallet as its fallback recipient. That wallet collected about 28.6 million POL, worth roughly $2.64 million at the time, before the attacker split it across three new wallets. During the incident, the attacker also opened a fresh Polymarket account to cash out prediction shares taken from 33 accounts.

Polymarket’s U.S. platform wasn’t affected. Polymarket says it removed the script, cleared caches, reset active login sessions, and kept trading paused until the site was clean. It referred the case to authorities in the U.K., where DebugBear is based. By October 30, 689 of 726 affected wallets, about 95%, had been refunded in full. In total, Polymarket is returning $3.9 million to traders: $2.7 million tied to the attack plus about $1.2 million for losses during the trading pause. It also says it is restoring third-party scripts with stronger controls, including a stricter Content Security Policy (CSP), pinned versions, sandboxing, and new checks to verify and monitor third-party code. The timing, days before the November 3 U.S. midterms and in a peak trading week, raised the stakes.

Why traditional defenses missed it

Nothing in Polymarket’s own stack was “hacked” in the usual sense. The breach ran inside live customer browser sessions, where most security tooling doesn’t look.

• WAFs and server-side scanners inspect traffic to your servers. Here, the user’s browser fetched the malicious script straight from the vendor’s domain.
• Code review and SAST cover code you ship. A third-party script can change on the vendor’s side at any moment, with no commit, pull request, or deploy on yours.
• Content Security Policy and domain allowlists check where a script loads from, not what it does. cdn.debugbear.com was an approved host, and every other host the drainer called was already in Polymarket’s CSP.
• Subresource Integrity (SRI) would have rejected the swapped file, because its hash no longer matched. But RUM and analytics snippets change on the vendor’s schedule, so few teams pin them.
• On-chain monitoring saw transactions that looked authorized, because they were signed inside real sessions.
• Trust in the vendor was the attack path. Polymarket trusted a performance-monitoring tool to run on every page, including the pages that move money.

Where Reflectiz fits

How Reflectiz covers both halves of this attack

This attack had two halves. A trusted script changed. Then Polymarket’s own page let that script move money. Reflectiz Security Hub catches the first. Reflectiz Offensive Hub finds the second before an attacker does.

Security Hub: catch the script when it turns

Others add a script to your pages to watch your scripts. Security Hub monitors without adding code. It runs real browser sessions against your site from the outside, inventories every third- and fourth-party script, and builds a Smart Baseline of what each one normally does. On the DebugBear file, you would have seen four signals:

1. New code at a trusted URL. The address never changed. The contents did. Security Hub tracks what a script contains, not only where it loads from, so it flags the swapped file on its first monitoring pass after the swap, before anyone needs to understand what the new code does.
2. Behavior outside the baseline. Security Hub learns each vendor’s normal footprint: what it reads, what it touches on the page, and where it sends data. A page-speed snippet reading auth keys from local storage, reaching into the trading client, and calling the app’s signer breaks that baseline and raises a Smart Alert.
3. New destinations. The file started calling Polymarket’s relayer, a blockchain RPC provider, and a swap-quote API. None of them belong in a RUM script’s footprint.
4. A clear first move. The alert names the script and the vendor. You pull it, or block its domain from the Reflectiz console with on-demand blocking (an optional CSP script that stays idle until you trigger it), then pause sensitive flows. Removal alone wasn’t enough here: the script came off the site at 17:59, 49 minutes after the first drain, yet drains ran until 18:10, when the relayer pause took hold. Every minute saved keeps money in users’ accounts.

Offensive Hub: shrink what a rogue script can take

Security Hub tells you a script turned. Offensive Hub tells you, ahead of time, what a rogue script could do on your logged-in pages. The drainer relied on three things inside Polymarket’s own app:

1. Trading keys in browser storage. It read trading API credentials straight from local storage. Offensive Hub flags sensitive data exposed in client-side storage.
2. A signer any script can reach. It found the order client and transaction signer in the page and used them. Offensive Hub tests injection paths, including DOM-based XSS, inside logged-in flows. A confirmed injection on a trading page carries the same blast radius as a hijacked vendor script.
3. Transfers to a new wallet in seconds. In Bitquery’s sample, funds moved 3 to 7 seconds after each approval. Offensive Hub tests business logic, such as workflow bypass, and a validator agent reproduces every finding before it reaches your report.

Offensive Hub would not have stopped the hijack at DebugBear’s registrar. That sits in your vendor’s infrastructure. It cuts what the next hijacked script can take. Testing behind the login is also how its agent found a critical OTP bypass on a major insurer’s live site. Attackers no longer work at human speed, so test continuously or on a schedule, not once a year.

What to do now

The takeaway

If a script runs on your site, it runs in your users’ sessions with their trust. Polymarket’s two third-party breaches this year show that a vendor you added for analytics or performance can speed attackers toward customer funds. Tampered frontend code also drove the $1.5 billion Bybit hack, and Reflectiz research found that 64% of third-party applications access sensitive data without justification.

Four questions you should be able to answer today:

• Do you have a live inventory of every script running on your sensitive pages, including fourth-party code your vendors pull in?
• Would you know within minutes if one of those scripts changed, even at the same URL?
• Would you know if it started touching data or functions it never touched before?
• If one turned tonight, what could it read, sign, or move on your logged-in pages?

If any answer is “no” or “not sure,” get a free Reflectiz site audit to see what’s actually running in your users’ browsers, then test your logged-in flows with Offensive Hub to see what a rogue script could reach.

Sources

• Polymarket Hack: $2.73M Drained From 737 Wallets in an Hour (Bitquery)
• Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script (The Hacker News)
• Polymarket wallet drainer served from DebugBear’s script CDN (Ohey)
• Hackers Hijacked DebugBear’s DNS To Serve Malicious JavaScript (Search Engine Journal)
• We’re impacted by an ongoing security incident (DebugBear on X)
• Polymarket Hack Drains 737 Wallets in One Hour as Investigation Reveals $2.73 Million Theft (Coinpaper)
• Polymarket Hack Drains $2.7M From 700 Users as Third-Party Breach Forces Trading Halt (CCN via Yahoo Finance)
• Polymarket Users Lose $2.7 Million in Third-Party Script Hack (Hackread)
• $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack (SecurityWeek)
• Some Polymarket user funds stolen by hackers; exchange referring matter to U.K. authorities (CNBC)
• Polymarket customers lose $3 million in supply-chain attack (BleepingComputer, June incident)