Breaches

Hijacked UK DebugBear script drains up to $2.7m from Polymarket

A tampered monitoring script from UK vendor DebugBear drained $2.5m-$2.7m from Polymarket accounts. What UK firms using third-party tags should do.

Network graphic illustrating a compromised third-party script draining accounts on Polymarket

Attackers hijacked a performance monitoring script supplied by UK firm DebugBear and used it to empty hundreds of Polymarket trader accounts in roughly an hour. A small analytics tag did the damage, and that should worry every UK organisation that embeds third-party JavaScript on pages where customers log in or pay.

What happened

On the afternoon of Thursday 29 October 2026, users of Polymarket’s international prediction market began reporting withdrawals they had not made. Just after 18:00 UK time it switched to cancel-only mode and paused trading. In a statement it said that “one of our 3rd party providers was compromised” and that the matter had been referred to law enforcement. Reuters and the Associated Press both reported that the referral went to UK authorities. Polymarket said the problem had been found and fixed, and trading resumed about an hour later. Polymarket US was not reported to be affected.

Polymarket did not name the supplier. Threat intelligence firm Hudson Rock, and a source who spoke to CNBC, identified it as DebugBear, a UK company selling website performance monitoring. DebugBear posted on X that it was dealing with an “ongoing security incident”. It told anyone using its Real User Monitoring (RUM) product to remove the embed code from their websites.

Polymarket has not published a loss figure, and on-chain estimates vary. According to figures compiled by ICOBench, blockchain analytics firm Bitquery counted about $2.73m taken from 737 accounts, and security firm GoPlus roughly $2.71m across 731 addresses. Analyses cited by CNBC suggested about $2.7m from around 710 wallets, while NBC News reported estimates of $2.5m to $2.65m. In short, between $2.5m and $2.7m was drained from roughly 700 to 740 accounts. Polymarket has promised to reimburse every affected trader. CNBC reported that smaller losses were being repaid first, with larger claims requiring a signed release.

The technical picture

No flaw in Polymarket’s smart contracts or trading engine was involved. The way in was JavaScript that Polymarket chose to load on its own pages. RUM tools run a script in each visitor’s browser to time page loads, and that script has the same privileges as the site’s own code.

According to analysis by Hudson Rock, reported alongside work by BleepingComputer and Bitquery and summarised by ICOBench, the legitimate DebugBear file was replaced with a wallet drainer. It was served from DebugBear’s own content delivery infrastructure and took instructions from another domain belonging to the company. When a signed-in user loaded a page, the code reportedly valued their holdings, used the live session to sell or transfer positions, then withdrew the proceeds to a wallet hardcoded in the script.

Bitquery’s data points to automation: withdrawal approvals were reportedly used within three to seven seconds of signing, and every transfer passed through the platform’s legitimate relayer, so nothing looked broken from Polymarket’s side. The draining reportedly ran from about 17:10 to 18:10 GMT. ICOBench, citing Bitquery, says the median victim lost only $171, while four accounts made up more than 40% of the total.

DebugBear has not said how its delivery infrastructure was compromised. Hudson Rock said its evidence did not show other DebugBear customers being hit, but any site running the RUM embed that day should assume exposure until shown otherwise.

Timeline of the 29 October 2026 Polymarket incident, from first withdrawals at 17:10 GMT to trading resuming around 19:00

Why it matters for UK organisations

This was a breach at a UK supplier, referred to UK law enforcement, and the same technique could just as easily have targeted a British retailer, bank or local authority portal. Performance monitoring, analytics, chat widgets, consent banners and A/B testing tools are common on UK websites, and they often sit on login, account and checkout pages. Marketing or web teams often add them through a tag manager without security review, and they rarely appear on a supplier risk register.

On a UK e-commerce site, the same tampered script would more likely be a Magecart-style card skimmer, the kind of attack that has brought ICO enforcement on UK retailers before. If a supplier’s script leaks customers’ personal data from your pages, UK GDPR still makes you the controller responsible for that data. You will also have to decide within 72 hours whether the incident must be reported to the ICO.

The payment card industry already expects this kind of control. PCI DSS v4.0 requires merchants to keep an inventory of the scripts that run on payment pages, justify each one, and detect unauthorised changes.

Expert view

When we test web applications, third-party scripts are usually out of scope, because the client does not own them and the supplier has not given permission. That is a sensible legal position, but it leaves a blind spot. The browser does not care who wrote the code: once a tag is on the page, it can read it, call the site’s APIs with the user’s session and change what the user sees. In my experience, few organisations can quickly list every external domain their authenticated pages load code from.

This is genuinely hard to defend against. Subresource Integrity hashes stop a known file from being silently swapped. Many monitoring and analytics vendors, however, change their scripts frequently or load further code at runtime, so integrity pinning breaks them. A strict Content Security Policy helps, but it will happily allow a malicious file served from a domain you have already approved, as here. The stronger controls are architectural: keep vendor code off sensitive pages altogether, host approved versions yourself where licensing allows, and require extra confirmation, outside the browser session, for high-risk actions such as withdrawals or payee changes.

Polymarket deserves credit for removing the integration within about an hour and committing to repay users. Speed like that usually comes from having already decided who may pull the plug.

What to do now

  1. Check for DebugBear now. Search your sites, tag manager containers and content security policies for DebugBear RUM embeds and remove them, as the vendor has advised.
  2. List your third-party scripts. Record every external script on authenticated and payment pages, who owns it and why it is there. Remove anything that is not justified. This supports the Cyber Essentials secure configuration control (remove unnecessary software and functionality).
  3. Restrict where vendor code runs. Keep analytics and monitoring tags off login, account, checkout and admin pages where you can. Use a tight Content Security Policy and Subresource Integrity on files that do not change.
  4. Detect script changes. Use client-side monitoring that alerts when a script’s content or behaviour changes. PCI DSS v4.0 already requires this for payment pages.
  5. Protect high-value actions. Require step-up authentication or out-of-band confirmation for withdrawals, payee changes and bulk transfers, so a hijacked session alone cannot move money. This aligns with the Cyber Essentials user access control requirements.
  6. Bring tag suppliers into supplier assurance. Ask how vendors protect their build and delivery pipelines, how they will notify you of a compromise, and how quickly. Rehearse the decision to pull a tag in your incident plan.

Bottom line

A performance monitor, about the most harmless-sounding tool on a website, became the means of draining roughly $2.5m to $2.7m from Polymarket traders in about an hour. Any third-party script on your sensitive pages is part of your application: inventory it, restrict it and monitor it.

Sources

Related Posts