decrypted · 2 november 2026 · vulnerabilities and patching · supply chain · ai and llm security

Polymarket's losses began with a third-party monitoring script

On 29 October the prediction market Polymarket halted trading after users reported money leaving their accounts. Polymarket's own code was not blamed. Researchers pointed instead at a script loaded from a website monitoring supplier, and that is a lesson any UK organisation with a login or checkout page can use this week.

What happened

Polymarket said one of its third-party providers had been compromised and that affected traders would be made whole. Hudson Rock, a threat intelligence firm, then examined a script served from DebugBear's servers and found wallet-draining code. SecurityWeek describes DebugBear as a UK-based performance monitoring company. DebugBear said it was impacted by an ongoing security incident and told customers to remove its snippet. Polymarket's build records show the script removed at 17:59 UTC on 29 October.

Loss estimates differ: about $2.19 million, $2.65 million and $2.71 million, depending on who is counting. None is a verified total, and how the script was tampered with is still unknown.

Why a monitoring tool could do this

Loading a supplier's script is like giving the meter reader a key to the house, then letting them change what the key does whenever they like. Your browser runs that script with the same authority as the site's own code.

Hudson Rock found no routine that steals passwords or seed phrases. The script did something neater. It found the live trading tools in the logged-in page, then either sold positions and moved the proceeds, or sent position tokens to an attacker's address. It is a forger who never needs the safe combination, because the cashier has already opened the till.

What the defender sees

Very little. The site's code had not changed and the malicious file lived on a supplier's server. Hudson Rock noted that a scan recorded Polymarket loading the script and allowing its host in the content security policy, the browser's list of outside sources permitted to run. That list worked as designed. It simply trusted the supplier completely. The visible symptoms were odd orders and customers asking where their money went.

SecurityWeek notes an earlier compromise of a third-party provider at Polymarket in June. Repeats like that suggest the supplier relationship, not one bad file, is the weak point.

The Secure by Design lesson

Keep third-party code out of any page where money moves or people sign in. Hudson Rock advises removing unnecessary third-party scripts from authenticated and signing flows, and pairing Subresource Integrity, which makes the browser refuse a file whose fingerprint has changed, with a restrictive policy.

The cost:

Monitoring moves to public pages, or you host a fixed copy yourself.
Fingerprint pinning breaks suppliers that change live scripts, so you need versioned files and a review each time they change.
Someone must keep an inventory of every script on login and payment pages, and own it.

For a UK director, the question for this week is simple: can your team list every outside script on those pages, and say who approved each one?

Also this week

Chainalysis discloses a breach by "offensive agentic techniques". The blockchain analytics firm, whose customers include law enforcement and exchanges, told customers on 30 October that an external actor had gained unauthorised access to its internal systems and tools earlier this month. Chainalysis says the data seen was user IDs, full names, email addresses and organisational role labels, and that it found no evidence of access to investigation content, credentials or session tokens. It has published no technical detail, and BleepingComputer notes it is unclear whether a known framework or custom AI agents were used. Chainalysis also says the incident is unrelated to the Binance theft, and tells customers to enable two-factor authentication and watch for scammers posing as the firm. The design lesson is dull but firm: if attackers can probe at machine speed, the controls that matter are the unglamorous ones, such as least privilege and logs that let you say what was not touched.

Drupal Commerce Core is being exploited. Drupal's advisory, dated 28 October, rates an access bypass in the Commerce Core module, CVE-2026-118539 (the public reference number for the flaw), as highly critical and says it is being actively exploited in the wild. The module runs shopping carts and checkouts. Fixed releases are 3.3.13 and 8.x-2.41. The advisory says the bypass may financially affect the vendor, and tells sites to audit their orders for inconsistencies. SecurityWeek reports the module is on more than 42,000 sites, and that Drupal has not said how the flaw is exploited or how many shops were hit. Patching is half the job; the other half is reconciling orders against payments for the days before you updated. Opinion, not advice: UK shops on Drupal should treat that audit as an incident, not housekeeping. Separately, TeamViewer fixed CVE-2026-111585, an 8.8-rated flaw in remote-control screen handling, in version 15.83, and says it knows of no exploitation.

Sources

If you want a second pair of eyes on the scripts and suppliers behind your own login and payment pages, get in touch.