Polymarket and a vendor's script: lessons for cyber underwriters

On 29 October 2026 a vendor's monitoring script loaded on Polymarket was replaced and took about 2.7 million dollars from more than 700 accounts. The analysis: which policy responds, aggregation across third-party scripts, controls and the questions to bring to renewals.

Topic of the week, 24 to 31 October 2026 · by cybercoverinsurance

On 29 October 2026, for about an hour, Polymarket's website loaded a vendor script into its users' sessions that was no longer the original one. The script was meant to measure page performance. The replaced code used the site's own trading client to move funds from hundreds of accounts to a single wallet. Independent estimates put the loss at about 2.7 million dollars.

The figure is small next to other events of the same week. The case matters for another reason. The entry point was neither the insured's own system nor a critical supplier, but a monitoring tool that almost no underwriting questionnaire lists. For cyber underwriters, the question is how many vendors run code inside their insureds' most sensitive pages, and who controls them.

What is known

The incident. Polymarket said a third-party provider "was compromised", that the matter had been referred to law enforcement, and that affected users would be made whole. Polymarket named neither the provider nor the amount taken (The Record). The threat intelligence firm Hudson Rock identified the provider as DebugBear, a UK web performance monitoring company whose real user monitoring script was embedded on polymarket.com. DebugBear confirmed it was affected by an "ongoing security incident" and asked customers to remove its code from their sites (ICOBench).

The timeline. According to Ohey's reconstruction, the malicious script ran in logged-in sessions from about 16:54 UTC on 29 October. The first funds reached the recipient wallet at 17:10 UTC. Polymarket shipped a version of the site without the script at 17:59 UTC. DebugBear announced the incident at 18:00 UTC (Ohey). Polymarket switched the platform to cancel-only mode at 18:05 UTC and reopened trading at 19:00 UTC (ICOBench). The affected platform is the international one (The Record).

How the code worked. Hudson Rock analysed the script. The code read account data from the browser, located the trading client already loaded in the page, checked balances and, above a minimum threshold, transferred positions or sold them and then transferred the proceeds. Signatures were requested through the signer already active in the session and sent to Polymarket's relayer. The authors found no routines exporting private keys or seed phrases (Hudson Rock). Ohey notes that every host the script contacted, apart from DebugBear's, was already allowed by Polymarket's Content Security Policy.

The figures. These are third-party estimates, not company data. Bitquery reports about 2.73 million dollars from 737 accounts between 17:10 and 18:10 UTC. GoPlus reports about 2.71 million from 731 addresses. The median loss per victim is 171 dollars (ICOBench). Polymarket has not published a total.

What is not known. How the attackers reached DebugBear's delivery infrastructure has not been explained (Safestate). How many other sites loaded the same script is not known. Hudson Rock found no evidence of a wider compromise affecting other DebugBear customers (The Record). No one has attributed the attack.

The vendor nobody lists

A monitoring script has the same powers as the site's own code. A browser does not distinguish between code written by the insured and code loaded from a vendor. Once in the page, a third-party script reads what the site reads and can request what the site can request. In the Polymarket case no credentials had to be stolen: the script used the session the user had already opened.

Questionnaires look elsewhere. Supply chain questions usually focus on IT, cloud and managed software providers. Analytics, tag managers, chat, review widgets and performance monitoring stay out, because they are seen as marketing or ancillary tools. That is exactly the category with the fewest controls and the most access to login, payment and confirmation pages.

A standard already exists to borrow questions from. For card payment pages, PCI DSS 4.0 requires an inventory of all scripts with a justification for each, a method to authorise them and a method to assure their integrity (requirement 6.4.3). It also requires a mechanism that alerts on unauthorised changes to the page as received by the browser, at least every seven days (requirement 11.6.1). Both have been mandatory since 31 March 2025 (PageCrawl). Polymarket does not process cards, but the logic applies to any page where a user authorises a transfer of value.

Which policy responds

The loss is the customers', the refund is the insured's choice. The stolen funds belonged to users. Polymarket has promised to reimburse them. For underwriters the distinction matters. Cyber policies usually cover established liability to third parties or claims for damages, not voluntary payments made before any claim and without the insurer's consent. A spontaneous refund, however sensible for reputation, may stay with the insured unless the policy has a specific cover for it.

Crime cover depends on who held the funds. Computer fraud insuring agreements in crime policies usually assume a loss of the insured's money or property, or property held on behalf of others. Here the funds sat in users' wallets, with signatures requested in their own sessions. Many crime policies also exclude cryptocurrency or cover it only through dedicated extensions. The adjuster will need to establish whether Polymarket held those funds, and in what form.

The vendor has a liability, the contract caps it. DebugBear may face claims from customers. The relevant cover is the vendor's technology professional liability (tech E&O), if it has one. But SaaS contracts of this kind often cap liability at the annual fees. A subrogation recovery by Polymarket's insurer may be worth little.

The interruption was short. Trading was suspended for about an hour. Business interruption waiting periods are usually several hours. In this case the real cost lies in incident response, forensics, user communications and refunds, not in downtime.

Aggregation: one script, many sites

The same file can reach thousands of pages. A script served from a vendor's content network is loaded by every site that embeds it. In the DebugBear case researchers did not find the malicious code at other customers, and the code was written for Polymarket. But the same position, with generic code, could have hit every customer of the vendor at the same time.

It is a loss scenario to map. For a portfolio, the question is not only which cloud providers insureds share. It is also which third-party scripts appear on the login and payment pages of many insureds at once. Tag managers, analytics tools and consent platforms are common to a very large number of sites. An event at one of these vendors would produce correlated claims for fraud, personal data breach and liability to customers.

The data can be observed from outside. Unlike many internal dependencies, the scripts a public page loads are visible to anyone who opens it. An external scan of applicants' login and payment pages can show which vendors recur across the portfolio, before the questionnaire.

Controls and reaction time

Content Security Policy is not enough on its own. Polymarket had a policy, but the script used hosts that were already allowed, that is, the site's own (Ohey). A policy limits where code can send data, not what it can do inside the page.

File integrity is the most direct control. Subresource Integrity blocks a script if its content no longer matches the expected hash. Hudson Rock lists it among the measures, together with removing unnecessary third-party scripts from trading and signing pages. The limit is practical: vendors update their scripts often, and the hash must be updated through a controlled process.

An hour was enough. About 50 minutes passed between the first funds arriving and the script's removal (Ohey). The response came in less than an hour, yet it did not prevent the loss. For automatic and irreversible transactions, the controls that matter act before the signature: per-session limits, extra confirmation for unusual operations, blocks on transfers to new destinations.

What to bring to renewals

These questions apply to any insured with login, payment or transfer authorisation pages.

Impact for insurersMedium

The single claim was contained, but the same vector at a widely used vendor would produce correlated claims across many portfolios.

On the portfolio side, the useful work is a map of recurring script vendors on insureds' sensitive pages. If three or four vendors appear across most of the portfolio, that is an aggregation to treat like the large cloud providers, with dedicated scenarios and limits.