We manage your security to weather the AI storm →

← Resource Hub

The Polymarket Hack Explained: A Third-Party Script

By Owen Thurm Published 4 min read

The Polymarket Hack Explained: A Third-Party Script

Quick answer. On October 29, 2026, a replaced third-party script on polymarket.com used logged-in sessions to sell positions and move funds. Polymarket is returning $3.9M. Its fixes, script pinning and monitoring, are how such a swap gets blocked or caught.

Watch: The Polymarket Hack Explained: A Third-Party Script 1:42
Video transcript

Polymarket has reported no flaw in its contracts. Instead, a replaced third-party script on its website used logged-in sessions to drain users.

Polymarket's site loaded a performance script from a vendor Hudson Rock identified as DebugBear. On a logged-in page, it could call what the app calls.

Hudson Rock reviewed the file without running it. The script read authentication data, found the trading client, valued positions, sold or moved them, and requested signatures through the page's signer.

Polymarket reported unauthorized activity at seventeen thirty-eight UTC. A build removed the script at seventeen fifty-nine, though Hudson Rock says that is not verified containment.

The Block reported over 2.6 million dollars lost within minutes. Polymarket is returning 3.9 million dollars, including losses during the trading pause.

Every script a page loads is part of the trusted code. A monitoring tag on a trading page can trade.

Vendors inherit the session, and their domains are attack surface. Polymarket is redeploying scripts with pinning and sandboxing, and adding continuous monitoring. Keep tags off money pages, and plan the shutdown.

Guardian's Managed Security covers frontends, domains and DNS around the clock. Shield runs reconnaissance and pentesting on internet-facing assets, Sentry watches domains and DNS, and a WebApp Pentest tests the client side.

Read the full article for the payload details and defenses, or talk to Guardian at guardian.security.

Polymarket has not reported a flaw in its contracts. The attacker went after a script the website loaded from an outside vendor.

It was the second such incident of 2026. In June, Polymarket said a compromised vendor let attackers inject code into its site "for some users," TechCrunch reported.

This explainer follows Polymarket's post-mortem, the vendor's statement and Hudson Rock's analysis of the script. All times are UTC.

What Happened

polymarket.com loaded a performance-monitoring script from a third-party vendor. Polymarket says the vendor was compromised and the attacker replaced the script with one built to target its users.

For some users with the site open during a short window on October 29, the script "used their active session to sell positions and move funds out of their wallet," Polymarket says.

Polymarket put its exchange in cancel-only mode and paused relayer actions, The Block reported. It said one of its third-party providers was compromised and referred the case to law enforcement.

Polymarket did not name the vendor. Hudson Rock identified it as DebugBear, a website performance company, The Record reported.

Polymarket says the vendor has confirmed the compromise publicly.

How the Attack Worked

A script with the user's session

A third-party script runs with the same rights as the site's own code. On a logged-in page, it can read what the app stores and call what the app calls.

A performance tag needs none of that power, but it gets it anyway.

What the payload did

Hudson Rock retrieved the 15,187-byte file from a DebugBear script address and reviewed it without running it. It describes these steps:

  1. Read the account's authentication data from the browser's local storage.
  2. Find the live trading client inside the page's React components.
  3. Value the user's balances and positions, and exit for geoblocked visitors.
  4. For externally owned wallets, batch-transfer position tokens to a set recipient.
  5. For other accounts, submit sell orders at ever lower prices, then move the proceeds.
  6. Request signatures through the page's own signer and submit them to Polymarket's relayer.
  7. Report wallets, positions and results to an endpoint on a DebugBear domain.

Hudson Rock cautions that a signing request is not a completed theft. It did not establish total losses, victims or how the script was first altered.

The vendor's side

On October 30, DebugBear said its DNS server records "were compromised through our domain registrar." It could not receive email sent to its domain.

It said the attack "targeted the website of a specific customer." It had seen no sign that its internal systems were compromised and was still investigating.

Timeline and Loss

When (UTC)Event
Oct 29, 17:38Polymarket reports unauthorized activity affecting user wallets
Oct 29, 17:59Build removing the DebugBear script, per Hudson Rock
Oct 29, 18:06Status page marks the incident resolved
Oct 30, 20:07Polymarket publishes its post-mortem
Oct 30, 23:11DebugBear points to its domain registrar

Hudson Rock notes the 17:59 time is a build time, not a verified containment time. Polymarket has not published when the script was first replaced.

The Block reported that over $2.6M was lost within minutes. Arkham data showed a suspected attacker wallet holding about $2.65M in POL.

Polymarket is returning $3.9M to traders: $2.7M to cover the theft's initial losses and $1.2M for losses during the trading pause.

The refunds include positions the script moved or force-sold, at their value when taken. No claims were needed: Polymarket found eligible wallets from onchain and trading data.

Polymarket's post-mortem says 95% of affected wallets have been refunded in full.

What It Shows

A prediction market's contracts can hold while its website drains users. Every script the page loads is part of the trusted code.

  • Vendors inherit the session. A monitoring tag on a trading page can trade.
  • The vendor's domain is attack surface. DebugBear points to its registrar.
  • Integrity controls matter. Polymarket is redeploying vendor scripts with stronger CSP, version pinning and sandboxing.
  • Watch what the site serves. Polymarket is adding continuous monitoring and verification of its scripts.
  • Keep tags off money pages. Hudson Rock advises removing unneeded scripts from trading and signing flows.
  • Plan the shutdown. Polymarket paused trading and the relayer, and reset every login session.

Our guide to dApp frontend supply chain security covers these controls. For the sector's other risks, read prediction market security.

A registrar was also part of the CoW Swap DNS hijack in April.

How Guardian Covers This Surface

Guardian's Managed Security lists frontends, and domains and DNS, among the surfaces it covers around the clock.

Within it, Shield is Guardian's continuous coverage of everything facing the internet: hosts, ports, services, storage, certificates, edge rules and the names that lead users to you.

Shield runs reconnaissance and penetration testing around the clock to see how deep an adversary can go. A Guardian researcher verifies what it finds.

Offchain, Guardian's Sentry watches domains, DNS, certificates, cloud and code host. When something fires, a Guardian engineer responds.

A WebApp Pentest tests the client-side surface directly: XSS, injection, CSRF, bundle supply chain, and what the frontend trusts from the API.

Frequently Asked Questions

Was Polymarket hacked?

Its website was. An attacker replaced a third-party performance-monitoring script loaded on polymarket.com, and the script used logged-in sessions to sell positions and move funds. Polymarket has not reported a flaw in its contracts.

How much was stolen in the Polymarket hack?

The Block reported over $2.6M lost within minutes. Polymarket is returning $3.9M: $2.7M to cover the theft's initial losses and $1.2M for losses during the trading pause.

Which vendor was involved?

Polymarket did not name it. Hudson Rock identified it as DebugBear, a website performance company. DebugBear said its DNS server records were compromised through its domain registrar, in an attack that targeted one customer's website.

How can teams defend against third-party script attacks?

Load as few third-party scripts as possible on logged-in pages, pin versions with Subresource Integrity, enforce a strict Content Security Policy, and monitor the scripts your site serves for unexpected changes.

Sources

Know every script your users load

Guardian's Managed Security covers your frontends and domains around the clock, with Shield testing everything you expose.