Polymarket Hack: How a Hijacked DebugBear Script Drained $2.7 Million from 726 Wallets in Under an Hour
The October 29 supply chain attack didn't touch Polymarket's smart contracts or servers. It didn't need to. By hijacking a third-party performance monitoring script through a compromised domain registrar, attackers slipped malicious code directly into the browsers of signed-in traders—and let their own sessions do the rest.
The 60-Minute Drain
On the afternoon of October 29, 2026, something strange began happening to Polymarket traders. Without warning, positions were sold. Funds moved. No prompts appeared. No passwords were entered. The platform's international exchange was hemorrhaging money from the inside, and the attackers were already gone.
Blockchain records show that crypto worth approximately **$2.64 million** reached the hackers' wallet in under an hour. By the time Polymarket's status page acknowledged "unauthorized activity in user wallets" at 17:38 UTC, the damage was well underway. The exchange was placed in cancel-only mode at 18:05 UTC, with relayer actions paused. Trading resumed roughly an hour later.
The final tally: 726 wallets affected, with a total restitution package of $3.9 million—$2.7 million to cover directly drained assets and an additional $1.19 million to compensate roughly 5,500 wallets that suffered collateral losses during the trading pause. By the morning of October 30, 689 of the 726 affected wallets had been refunded in full, with the remaining 37 under manual verification.
The Weakest Link: A Page-Speed Script
The attack vector was not Polymarket's own code, its smart contracts, or its users' private keys. It was a Real User Monitoring (RUM) script from DebugBear, a UK-based website performance monitoring firm that Polymarket used to measure how fast its pages loaded for real visitors.
Each DebugBear customer loads its own project-specific copy of the script. Polymarket's was served from `cdn.debugbear[.]com/C7xcKKrjUnXK.js`. On October 29, Hudson Rock researchers retrieved a 15,187-byte version of that file—one that contained wallet-draining logic instead of performance measurement code.
How did the legitimate script become malicious? DebugBear confirmed that attackers compromised its DNS records through its domain registrar—not by breaching DebugBear's internal systems. Researchers at Ohey observed a different server answering for DebugBear's web addresses at 18:13 UTC, while earlier that day the normal script had been served from Google Cloud Storage. The URL on Polymarket's pages never changed. The server behind it did.
DebugBear's early findings indicate the attack **targeted one customer's website**—Polymarket's—and the company has seen no sign of a break-in to its own systems. Security firm GoPlus similarly assessed that other DebugBear clients were not targeted.
Inside the Malicious Script
Hudson Rock's static analysis of the 15,187-byte payload revealed a carefully orchestrated sequence of actions, all executed within the context of a trader's already-authenticated browser session.
Step 1: Harvest the Session
The script read three local-storage entries that Polymarket stores in the browser, including `poly_clob_api_key_map`—a map of trading API credentials—and the proxy wallet address. Critically, Hudson Rock found no routine that exfiltrates passwords, seed phrases, or private keys to the attacker's server. The script didn't need them. It reused the authority the logged-in user already possessed.
Step 2: Find the Trading Engine
The code traversed React's internal component tree to locate the live trading client, searching for methods like `postOrder` and `createOrder`. It then inspected the victim's portfolio, applying thresholds of $10 total value and $10 per position—a low bar designed to maximize the number of exploitable accounts.
Step 3: Execute the Drain
The script branched based on account type:
- For externally owned accounts (EOAs)—wallets where the user controls the private key—it built an ERC-1155 batch transfer of position tokens directly to an attacker-controlled address.
- For accounts created through an embedded wallet provider (referred to in the analysis as "magic wallets"), it submitted sell orders at progressively worse prices, then transferred the proceeds out.
In both cases, the script asked the page's existing signer to sign the requests and submitted them through Polymarket's own relayer. Because every transaction was signed from a legitimate session and processed by Polymarket's own infrastructure, the smart contracts behaved exactly as designed. In a sample of 30 drains, blockchain data firm Bitquery found each approval was used **3 to 7 seconds after creation**—a speed that points to automation, not humans clicking through accounts.
Step 4: Report Back
The script communicated with `data.debugbear.com` to receive commands and exfiltrate account information: wallet addresses, IP addresses, countries, portfolio values, and position summaries.
---
The Money Trail
The wallet hard-coded into the script received its first funds at 17:10 UTC and its last at 18:02 UTC, according to Ohey's blockchain trace. In that 52-minute window, it collected 28.6 million POL tokens and positions from 33 wallets.
By 18:19 UTC, those 28.6 million POL were worth approximately **$2.64 million** at DefiLlama's price of $0.0922, DefiPrime calculated. Between 18:28 and 18:38 UTC, the wallet sent all 28.6 million POL to three other addresses in an apparent laundering sequence.
One trader, identified on X as Car (@CarOnPolymarket), reported his account was drained of **$800,000**, with all positions sold. The address `0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18`, hard-coded in the script as its fallback recipient, showed balances of approximately **$2.19 million** at the time of capture—though Hudson Rock cautions this figure may overlap with the trader's reported loss and should not be added to it.
---
Polymarket's Response
Polymarket's incident response was swift, even if the attack itself was faster. The company removed the malicious script **"within the hour,"** cleared every cache, reset all active login sessions, and paused trading until the site was clean. It referred the matter to law enforcement, and UK authorities were notified.
Crucially, the attack did not affect **Polymarket US**, the company's federally regulated platform for users within the United States. The flagship international platform and Polymarket US operate as separate entities.
Polymarket's restitution went beyond direct losses. The **$3.9 million total package** includes compensation for traders who lost money during the trading pause or had positions taken—a recognition that operational downtime itself carries financial consequences for active traders. Traders did not need to file claims; payments were issued directly on-chain to original user addresses.
By October 30, **689 of the 726 directly affected wallets** had been fully refunded, with the remaining 37 under individual review.
---
A Pattern, Not an Anomaly
The October 29 incident was not Polymarket's first brush with front-end supply chain attacks—and it would not be the last major DeFi security event of that week.
The June 2026 Precedent
Just four months earlier, in June 2026, Polymarket suffered a nearly identical attack. A compromised third-party vendor injected malicious code into the platform's frontend, draining approximately **$3 million** from a smaller number of users. The October attack was larger in scope—hundreds of wallets versus fewer than 15—but followed the same playbook: compromise a trusted dependency, let the code run in authenticated sessions, and exploit the authority users had already granted.
The StepDrainer Wave
Two days after the Polymarket attack, on October 31, at least **12 cryptocurrency and DeFi front ends**—including Flap, Kintsu, Pickle Finance, Origami Finance, FluxBeam, Echelon, StonkFun, and StakePoint—were redirected to wallet-drainer pages serving the **StepDrainer toolkit**. Kintsu confirmed its domain had been compromised at the **registrar level**, the same root-cause pattern as the DebugBear compromise. Approximately **$138,000** was traced to attacker wallets in that coordinated campaign—smaller in dollar terms, but identical in method.
The Cloud Security Alliance's analysis drew the connection explicitly: the trust boundary of any signing page extends beyond the site operator to **every party that can change what a script URL resolves to**—the script vendor, its registrar, its DNS provider, its CDN, and its storage. These are "fourth parties that the site operator has never assessed".
---
Why CSP Didn't Save Polymarket
Polymarket, like many modern web applications, employed a Content Security Policy (CSP) —a browser security mechanism that restricts which scripts can execute on a page. The CSP did not stop the attack, and the reason is instructive.
A host-allowlist CSP says, in effect: "Scripts from these trusted domains are allowed to run." The DebugBear script came from a trusted domain. It was allowed. The malicious code **called Polymarket's own APIs, its RPC provider, and its swap service**—all destinations the CSP permitted. The policy had no mechanism to detect that the *content* of the trusted script had changed.
As the Cloud Security Alliance put it: "Host-allowlist Content Security Policies do not stop a trusted script from misusing trusted destinations".
This is where Subresource Integrity (SRI) becomes critical. SRI attaches a cryptographic hash to a script tag. If the file served from the CDN doesn't match the expected hash, the browser refuses to execute it. When an approved delivery source is compromised, URL or version pinning and CSP source allowances alone cannot prevent the attack—SRI can.
Polymarket has said it is restoring third-party scripts with **stronger CSP, pinned versions, and sandboxing**—a tacit acknowledgment that its prior controls were insufficient for the threat model it faced.
---
The Broader Takeaway: Observability Code Has No Place in Signing Contexts
Perhaps the most uncomfortable lesson from the Polymarket hack is one that extends far beyond prediction markets. The malicious script was **performance monitoring code**—observability tooling intended to measure page load times. It had no business being able to reach a transaction signer.
The Cloud Security Alliance's assessment is blunt: "**Observability, analytics, and marketing scripts do not belong on pages that hold a signer or session credential.** On those pages, any script that runs in the page's own context has the same authority as the user".
That principle has immediate practical implications for any platform where users sign transactions or interact with valuable assets:
- Inventory every third-party script that loads on authenticated or transaction pages, and remove anything that isn't strictly necessary.
- Implement SRI for all externally loaded scripts, not just CSP allowlists. A trusted CDN is not a verified CDN; the file it serves can change.
- Treat registrar-level controls as front-end security controls. Registry lock, registrar multi-factor authentication, and DNS change monitoring apply not only to your own domains but to the domains of every vendor whose code you load.
- Sandbox transaction privileges so that even a rogue script running in the page's context cannot invoke the signer without an explicit, visible user action.
- Reject unexpected signing requests. For traders, Hudson Rock's advice is simple: if a wallet prompts you to sign something you didn't initiate, refuse it.
---
What Remains Unknown
As of early November 2026, several key questions remain unanswered. DebugBear has not published a root cause for its compromise; the Cloud Security Alliance notes that "organizations should treat attribution claims as unconfirmed, including claims of DNS or registrar involvement". The exact mechanism by which attackers accessed the registrar—credential theft, social engineering, or a vulnerability in the registrar's own systems—has not been disclosed.
The number of affected users also remains a matter of some dispute. Polymarket's official figure is 726 wallets, but on-chain analytics firm Bubblemaps initially estimated around 700, and other analyses have cited figures ranging from 710 to 737 deposit wallets. The discrepancy likely reflects the difference between "affected accounts" and "addresses touched" by the drainer's automated transfers.
What is clear is that the attack represents a maturation of client-side supply chain threats. The attackers did not need zero-days, smart contract exploits, or stolen private keys. They needed a single point of failure in the delivery chain for code that every Polymarket user's browser trusted implicitly—and they found it in a domain registrar.
For Polymarket, the financial cost of the October 29 hack—$3.9 million in restitution—is significant but survivable. The reputational cost is harder to quantify, coming just four months after a similar incident and amid a period of intense scrutiny over prediction market security and insider trading. For the broader DeFi ecosystem, the lesson is starker: **the trust you place in a third-party script is the trust you place in every party that can alter what that script delivers.** In the current web architecture, that chain of trust is longer, and more fragile, than most platforms have been willing to acknowledge.
---
Polymarket's incident report and DebugBear's security updates are available through their respective status pages. Traders who believe their refund amount is incorrect can access a form linked from Polymarket's status page.