- What: On October 29, malicious code replaced the DebugBear real user monitoring script loaded by Polymarket after DebugBear's DNS records were compromised through its domain registrar.
- Impact: Polymarket is refunding about $2.7 million to 726 affected wallets, and blockchain records show about $2.64 million in POL reached the attackers' wallet in under an hour.
- Fix / mitigation: Polymarket removed the script, cleared caches, reset active sessions and paused trading, while DebugBear told RUM customers to remove its embed code from their websites.
- Who's at risk: Signed-in Polymarket traders were directly affected, and the method is relevant to any site that loads third-party scripts on pages where users trade or sign transactions.
A page-speed script cost Polymarket traders about $2.7 million on October 29. Malicious code replaced the DebugBear real user monitoring (RUM) script that the prediction market's website loaded from an outside company, then used signed-in traders' existing access to take positions and move funds to the attackers. Polymarket says it is refunding about $2.7 million to 726 affected wallets. Blockchain records show crypto worth about $2.64 million reached the attackers' wallet in under an hour.
The attack did not depend on stealing credentials. Hudson Rock reviewed the file without running it and found no code that sends trading API keys, a password, a seed phrase or a private key to the server the script reports to. The code worked from inside a trusted page, using access the trader already had.
How the Script Reached Polymarket
DebugBear said on X that its DNS records were compromised through its domain registrar. Its early findings indicate the attack targeted one customer's website, and it has seen no sign of a break-in to its own systems, though that investigation continues.
Researchers at Ohey found a different server answering for DebugBear's web addresses at 18:13 UTC, while the malicious file was still online. Earlier that day, the normal script had been served from Google Cloud Storage. Each DebugBear customer loads its own copy of the script, and the file that was swapped was Polymarket's. Hudson Rock downloaded the malicious file on October 29 from the address Polymarket's site used to load the script, and also found a change in Polymarket's site code that removed the DebugBear script.
If DebugBear's early findings hold, the attackers did not need access to the vendor's internal systems. Control over where its domain pointed was enough to put their code on the customer's page.
How the Code Took the Money
The script reads account details that Polymarket keeps in the browser, including a set of trading API keys. Those keys cannot place an order alone, because orders also need a wallet signature. So the code searches the page for the component that places orders and for the signer that approves the account's transactions. It then follows one of two paths:
- Accounts that sign in with their own crypto wallet: the code moves the trader's positions straight to the attackers' wallet.
- Accounts that sign in via email: the code sells positions at ever-worse prices, then moves the money out.
In both paths, the code asks the account's own signer to sign its requests and hands them to Polymarket's relayer, which submits them. To the downstream systems, each request arrives through the same route as a legitimate one.
Hudson Rock said a signing request alone does not prove a trader signed without seeing a prompt. The wallet provider may still ask the trader, refuse, or apply its own rules for the session. The available reporting does not establish how many signatures, if any, were completed without a prompt.
The Timeline on Chain
Ohey's blockchain trace and Polymarket's status updates give a tight sequence of events on October 29, all in UTC:
- 17:10: The wallet written into the code receives its first funds.
- 17:38: Polymarket posts its first status update about unauthorized activity in user wallets, 28 minutes after the first inflow.
- 18:02: The attackers' wallet receives its last funds, 52 minutes after the first.
- 18:05: Polymarket says its exchange is in cancel-only mode, with relayer actions paused.
- 18:13: Ohey sees a different server answering for DebugBear's web addresses, with the malicious file still online.
- 18:19: The wallet's 28.6 million POL are worth about $2.64 million at DefiLlama's price of $0.0922, according to DefiPrime's calculation.
- 18:28 to 18:38: The wallet sends all 28.6 million POL to three other addresses.
The funds sat in the collecting wallet for 26 minutes after the last inflow before they moved on. The reporting does not say what stopped the inflows, so the relayer pause cannot be credited with ending the theft on timing alone: the last inflow came 3 minutes before Polymarket announced it.
The $2.64 million figure covers only the POL tokens, not the positions the wallet also collected. Ohey's trace shows the wallet receiving POL and positions from 33 wallets, while Polymarket counts 726 affected wallets. The reporting does not reconcile those two numbers, so they should not be read as a single count.
Polymarket's Response and Refunds
Polymarket said it removed the script "within the hour," cleared every cache, reset all active login sessions and paused trading until the site was clean. It has referred the case to law enforcement.
By October 30, 689 of the 726 affected wallets had been refunded in full, about 95 percent, and the remaining 37 were being paid as they were checked. Polymarket is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken. In all, it is returning $3.9 million to traders. Traders do not need to file a claim, and the status page links a form for anyone who disputes an amount or believes they should have received a payment.
Vendor Mitigations and the Control Gap
DebugBear has told customers of its RUM product to remove its embed code from their websites. The address that served the malicious file, cdn.debugbear[.]com, had no DNS record when The Hacker News checked on November 1.
Polymarket said it is restoring third-party scripts with extra checks, including a stronger Content Security Policy (CSP), pinned versions and sandboxing. Hudson Rock's analysis explains why those specifics matter:
- A security policy that simply allows a trusted CDN does not check the files that CDN serves.
- Subresource Integrity (SRI) lets the browser reject a file if its contents change, but it applies only where a file can be pinned.
- Third-party code on a signed-in page can matter as much as first-party code when it can reach the signer, so what that code can ask the signer to do is part of the exposure.
- Unneeded third-party code on pages where users trade or sign adds risk without serving the transaction.
Hudson Rock's advice for traders is to reject any signing request they did not expect.
Why This Matters Beyond Crypto
Performance monitoring tools are often treated as low-risk additions to a website, yet this one ran on the same page as a live trading session. Its original purpose was to measure load times, and once swapped it had enough reach to find the order component and the signer.
The same exposure exists wherever an authenticated page loads outside code. The trust path here ran through a registrar and a DNS record, and neither sits inside the customer's own codebase. Some facts remain open: DebugBear's investigation is ongoing, its single-customer finding is preliminary, and neither company has publicly identified the attackers in the reporting available so far.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us