Polymarket loses $2.7m after DebugBear script hijack via DNS compromise

On October 29, 2026, hackers exploited a supply chain vulnerability in the prediction market platform Polymarket to steal approximately $2.7 million from user wallets. The attack leveraged a compromised third-party script from performance monitoring provider DebugBear, allowing malicious code to execute within the browsers of signed-in traders. Polymarket has since initiated refunds for affected users and paused trading to secure its infrastructure.

What happened

The incident began when attackers compromised the DNS records of DebugBear through its domain registrar. This allowed them to redirect requests for a specific JavaScript file used by Polymarket to a server under their control. Instead of serving the legitimate real user monitoring (RUM) script that measures page load speeds, the attackers served a malicious version tailored to target Polymarket’s specific implementation. Researchers at Hudson Rock identified the swapped file, noting that while DebugBear serves unique scripts to each customer, only Polymarket’s copy was replaced in this instance.

Once the malicious script loaded in users' browsers, it actively scanned for account details and trading API keys stored in the session. The code did not exfiltrate private keys or passwords directly. Instead, it manipulated the existing authenticated session to place unauthorized trades. For users logged in via crypto wallets, the script moved positions directly to attacker-controlled addresses. For email-based accounts, it sold positions at increasingly unfavorable prices before draining the resulting funds. Blockchain analysis by Ohey showed that 28.6 million POL tokens, valued at roughly $2.64 million, were transferred to a hacker wallet between 17:10 and 18:02 UTC.

Polymarket detected the anomaly and posted a status update at 17:38 UTC. By 18:05 UTC, the platform had switched to cancel-only mode, paused all relayer actions, and removed the malicious script. The company cleared all caches, reset active login sessions, and referred the case to law enforcement. As of October 30, Polymarket had fully refunded 689 of the 726 affected wallets, with the remaining 37 being processed. The company is also distributing an additional $1.19 million to approximately 5,500 wallets that incurred losses during the trading pause or due to position liquidations, bringing the total restitution to $3.9 million.

How it works

The attack relied on abusing the trust relationship between the browser, the website, and the user’s wallet signer. The malicious script operated entirely within the context of the victim’s open Polymarket tab. It accessed trading API keys stored in the browser memory but could not use them alone to execute trades, as Polymarket requires a cryptographic signature from the user’s wallet for every order.

To bypass this, the script interacted with the Polymarket interface elements responsible for placing orders and the signer object that approves transactions. It effectively automated the signing process by triggering requests that the wallet provider might present to the user. However, the speed and automation suggest that some signatures may have been approved without explicit user awareness, or the wallet provider’s session rules allowed the batched requests. The script then handed these signed requests to Polymarket’s relayer, which submitted them to the blockchain. This method allowed the attackers to move funds without ever possessing the user’s private key or seed phrase.

Key details

• Attack vector: Compromised DNS records at DebugBear’s domain registrar redirected a specific customer script to a malicious server.
• Financial impact: Approximately $2.64 million in POL tokens was stolen from 33 wallets in under an hour; total refunds amount to $3.9 million.
• Target scope: Early findings indicate the attack targeted only Polymarket’s specific DebugBear script, not the entire DebugBear customer base.
• Technical method: The script reused existing session API keys and triggered wallet signatures for unauthorized trades rather than stealing credentials.
• Response time: Polymarket identified the issue and paused trading within roughly 30 minutes of the first unauthorized transfers.
• Current status: DebugBear has advised customers to remove its embed code, and its CDN address had no DNS record as of November 1.

Why it matters

This incident highlights the critical risk inherent in loading third-party JavaScript on pages that handle sensitive financial operations. Even reputable vendors like DebugBear can become entry points if their infrastructure, such as DNS records, is compromised. For developers building fintech or crypto applications, relying solely on a vendor’s reputation is insufficient. The attack demonstrates that a supply chain compromise can bypass traditional perimeter security because the malicious code executes with the same privileges as the application itself.

Furthermore, the mechanism of abuse shows that protecting private keys is not enough. If an attacker can manipulate the frontend logic to trigger valid signatures from a user’s wallet, they can drain funds without ever accessing the key material. This shifts the security focus from just credential protection to rigorous integrity checks for all client-side code. It underscores the need for defensive coding practices that limit what third-party scripts can access and do within an authenticated session.

What you can do

• Implement Subresource Integrity (SRI) hashes for all third-party scripts to ensure the browser rejects files if their content changes unexpectedly.
• Enforce a strict Content Security Policy (CSP) that limits which domains can execute scripts and restricts inline code execution.
• Remove unnecessary third-party scripts from pages where users perform sensitive actions like trading, signing, or entering payment details.
• Monitor DNS records for your third-party providers and consider using pinned versions of scripts rather than dynamic endpoints.
• Educate users to reject any wallet signing requests they did not explicitly initiate, especially if they appear in rapid succession.
• Sandbox third-party code where possible to limit its access to the main page’s DOM and sensitive API objects.