Polymarket Third-Party Script Hack: Lessons for Websites

A third-party script meant to measure page speed became the entry point for theft at Polymarket on October 29, 2026. Attackers swapped the DebugBear script loaded by the site and used signed-in traders’ sessions to sell positions and move funds. Polymarket is now returning a total of $3.9 million to its users.

The case matters to anyone who runs a website because the entry point sat outside Polymarket’s own systems, in a piece of code from a trusted vendor that loaded on the site’s pages.

Timeline of the October 29 attack

Polymarket is a crypto-based prediction market. On October 29, users began reporting withdrawals they had not made. Polymarket switched its exchange to cancel-only mode, which allows users to cancel orders but not place new ones, and paused its relayer, the service that forwards user transactions to the blockchain.

According to the blockchain trace summarized by The Hacker News, the attackers’ wallet received its first funds at 17:10 UTC and its last at 18:02 UTC. Polymarket posted its first status update at 17:38 UTC. Researchers at Hudson Rock found a Polymarket production build timestamped 17:59 UTC with a change that removed the DebugBear script, and cancel-only mode took effect at 18:05 UTC.

SecurityWeek reported that trading resumed about an hour later. Polymarket’s separate US platform was reportedly unaffected. The company said one of its third-party providers had been compromised and that it had referred the case to law enforcement.

How the swapped script worked

DebugBear is a UK-based website performance monitoring company. One of its products is a real user monitoring (RUM) script, a small piece of code that records how quickly pages load on real visitors’ devices. Scripts like this are common, and they usually sit alongside analytics tags, chat widgets and ad pixels.

A script loaded from a vendor’s domain runs with the same privileges as the site’s own code. It can read the page, access data the browser stores for that site, and call any function available to a signed-in user.

Hudson Rock analyzed a copy of the malicious script without executing it. Its findings, as reported by The Hacker News and SecurityWeek:

• The script looked for the order component and the portfolio of a signed-in user, including trading API keys stored in the browser.
• API keys alone cannot place an order, because every order also needs a wallet signature. The script asked the account’s own signer to approve its requests and passed them to Polymarket’s relayer.
• For accounts that signed in with a crypto wallet, the script moved positions directly to the attackers’ wallet. For accounts that signed in with email, it sold positions at progressively worse prices and then moved the proceeds.
• Hudson Rock found no code that sent passwords, seed phrases or private keys to the attackers’ server.

In other words, the attackers did not need to steal credentials. They rode on sessions that were already legitimate. Hudson Rock also noted that static analysis cannot prove every step succeeded, since a wallet provider may still show a prompt or refuse a request.

The root cause sat in the vendor’s DNS

At first, DebugBear only confirmed that it was affected by a security incident and told customers of its RUM product to remove the embed code from their sites. On November 2, SecurityWeek quoted the company’s preliminary findings: “Our DNS server records were compromised through our domain registrar.”

DNS works like the internet’s address book, deciding which server answers when a browser requests an address. The registrar is where a domain is registered and where its DNS records are managed. If attackers gain access at the registrar, they can point a vendor’s official address to a different server without ever breaking into the vendor’s infrastructure.

The Hacker News reported that the normal DebugBear script had been served from Google Cloud Storage. At 18:13 UTC, a different server was answering for DebugBear’s addresses. Each DebugBear customer loads its own copy of the script, and the file that was swapped belonged to Polymarket. DebugBear’s preliminary findings suggest the attack targeted a single customer’s website, and so far it has seen no sign that its internal systems were breached. It has not explained how the attackers gained registrar-level access. At the time of writing, the DebugBear homepage still displayed a notice that the service was temporarily unavailable due to a security incident.

Refunds and compensation

In an October 30 update, Polymarket said 726 wallets were affected, with direct losses of about $2.7 million. By that day, all but 37 wallets had been made whole, with the rest to be paid once their details were verified. Security firm GoPlus put the figure slightly differently, at roughly $2.71 million across 710 deposit wallets.

Polymarket is also paying $1.19 million to about 5,500 wallets that lost money because of the trading halt or had positions sold or moved by the script, bringing the total to $3.9 million. According to Hackread, users do not need to file claims because eligible wallets were identified from trading data.

This was not the first such incident. In June 2026, Polymarket reported a similar case in which a malicious script was injected into its frontend through a third-party vendor, with losses of around $3 million.

What this means for website owners

Almost every website loads code from someone else. Online stores add chat widgets and ad pixels, public service portals run analytics, and banking web apps use performance monitoring tools. Unless they are managed, all of those scripts also run on login pages, shopping carts and personal data forms. The Polymarket case shows that trusting a vendor is not enough, because even an honest vendor can lose control of its domain.

Inventory scripts and remove them from sensitive pages

Start with a list of every script loaded from another domain: the vendor, its purpose and the pages where it appears. Hudson Rock recommends keeping unneeded third-party code off pages where users trade or approve actions. Login, payment and personal data pages should ideally load only first-party code.

Lock the contents of the files you load

Subresource Integrity (SRI) makes the browser check a file’s cryptographic hash before running it. If the contents change, the browser refuses to load the file. This works well for libraries with fixed versions. Gareth Bowker of Jscrambler, quoted by Hackread, said SRI has limited value for RUM scripts because vendors update them often, and he advised organizations to monitor what third-party code does in the browser at runtime. Another middle ground is to host a specific version on your own server and update it on your own schedule. Polymarket itself said it will restore third-party scripts with a stronger Content Security Policy (CSP), pinned versions and sandboxing.

Understand the limits of Content Security Policy

CSP restricts which domains can serve scripts and where data can be sent. In this case, Bowker said the malicious script sent data to a server on DebugBear’s own domain, so a CSP that allowed the vendor’s domain would still have let that traffic through. CSP narrows the door, but it needs to be paired with other controls.

Protect your domain and prepare an emergency plan

The lesson from DebugBear’s side applies to your own domain as well. Registrar accounts should be protected with two-factor authentication, restricted access and a domain lock where the registrar offers one. Prepare an emergency procedure too: a way to pull one script from every page within minutes, purge caches and end all user sessions. Those were the steps Polymarket took to stop the losses.

If your team has not yet mapped every script running on its sites, an audit through a cybersecurity service is a practical starting point. For new sites, script loading rules are best set during web application development. Browser-side protection also connects to another flaw we covered in lessons from the ChatGPT share link flaw.

Frequently asked questions

Were other websites using DebugBear affected?

DebugBear’s preliminary findings suggest the attack targeted only one customer, and Hudson Rock found no indication that other customers were targeted. The investigation is ongoing, and DebugBear has asked RUM customers to keep the embed code removed until further notice.

Were Polymarket users’ passwords stolen?

Hudson Rock’s analysis found no code that sent passwords, seed phrases or private keys. The script used active sessions instead. Polymarket also reset all active login sessions after removing the script.

What can users of services like this do?

Bowker advised users to review their transaction history and revoke token approvals they do not recognize. Hudson Rock advised users to reject any signing request they did not expect. Bowker also said users cannot reasonably detect a malicious script on a trusted site, so the main responsibility lies with the platform operator.

Conclusion

The attack on Polymarket lasted less than an hour, yet the losses reached millions of dollars because one vendor script had full access to sensitive pages. For website owners, the first steps are to know which scripts are running, limit the pages where they load and prepare a fast way to remove them. The Merakit team can help map and organize the third-party scripts on your site.

Sources

• Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script, The Hacker News, November 1, 2026
• Polymarket Returns $3.9 Million to Traders as DebugBear Cites DNS Hijack, SecurityWeek, November 2, 2026
• $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack, SecurityWeek, October 30, 2026
• Polymarket Users Lose $2.7 Million in Third-Party Script Hack, Hackread, October 31, 2026
• DebugBear Security Incident, notice on the DebugBear website, accessed November 3, 2026
• Subresource Integrity, MDN Web Docs