- Hudson Rock says a script served from a DebugBear address used by Polymarket tried to sell or move signed-in traders' assets.
- GoPlus puts losses near $2.71 million. A balance at the script's recipient address was about $2.19 million. Neither is a verified total.
- Audit third-party scripts on login, payment and signing pages. Use Subresource Integrity so browsers can reject files that change.
A page-speed tool should measure how fast a page loads. How closely does your team review one after installing it? On October 29, 2026, Hudson Rock reported that a script from a DebugBear address used by Polymarket did far more. It hunted for a signed-in trader's account and tried to move their assets.
What happened
Users of Polymarket's international platform reported withdrawals they had not authorized on October 29, SecurityWeek reported. The company halted trading there. It first switched the exchange to cancel-only mode. Trading resumed about an hour later.
Polymarket blamed a compromised third-party provider and promised to compensate affected users. SecurityWeek says the company has named neither the vendor nor a loss figure. DebugBear, a UK performance-monitoring firm, said it was hit by an ongoing security incident. It asked customers of its real user monitoring product to remove its snippet.
The losses are still unsettled
Three figures are in circulation, and none is a verified total. Hudson Rock read a screenshot of the address built into the script as its backup recipient. It showed $2,178,191.78 in POL and $16,170.39 in other tokens, about $2.19 million combined. Hudson Rock cautions that this does not account for stolen funds.
GoPlus, a blockchain security firm, estimates losses at roughly $2.71 million, SecurityWeek reported. GoPlus traced the main attack path through 710 deposit wallets and 731 addresses. Addresses are not people, so that count is not a victim total. SecurityWeek adds that Arkham's data places roughly $2.65 million in a wallet it suspects belongs to the attacker, the same address the script names as its fallback recipient.
Hudson Rock has not found evidence that other DebugBear customers were targeted. It also has not established how the script was altered or how many users lost money.
How the script worked
Hudson Rock fetched the file twice on October 29. Both copies were 15,187 bytes and identical. The team read the code as text and did not run it.
The script reads three items from the browser's local storage. These give it login context, the deposit-wallet address and a lookup of API credentials. It then searches the page's React components, the building blocks of the screen, for an object with trading functions such as postOrder and createOrder. That object is the trading client the user's session already uses.
Next, the script checks the portfolio against value thresholds. It stops if Polymarket's geoblock check flags the visitor. Then it picks one of two routes by account type. One batch-transfers the position tokens. The other places sell orders at ever more aggressive prices and tries to move the proceeds.
The script also builds signed messages for Polymarket's relayer, using the signer already on the page. The script sends data about wallets, countries, portfolio values and transfer results to data.debugbear[.]com, Hudson Rock found.
Hudson Rock lists its limits. It did not connect a wallet or run the sample. A signing request does not prove that a signature went through silently. A wallet provider may prompt the user, refuse, or apply session rules. The researchers also found a balance check that compares a value with itself, so some paths may fail.
The idea: a script inherits the page's trust
Much security thinking centres on passwords and seed phrases. This case points elsewhere. Hudson Rock found no code that ships a password, seed phrase, private key or credential map to the reporting address. The script's approach, it says, is to "reuse authority already available in the authenticated application."
The lesson here is that a third-party script is a tenant in your most trusted room. This one tries to use whatever the signed-in user can use. Whether the user sees a prompt depends on the wallet provider and session rules. Hudson Rock did not test that. The risk sits in code the trader did not choose and cannot easily see.
Names do not settle trust either. Hudson Rock notes that DebugBear's documentation describes its hosts as real monitoring infrastructure. What marks the file as harmful is its trading, signing and transfer logic. A trusted hostname says little about what a file does.
Polymarket's published code holds a trace of the cleanup. Hudson Rock found a build note reading "chore(polymarket): remove debugbear rum script (#15337)", stamped 17:59:20 UTC. That marks when the build was made, not when the threat was contained. SecurityWeek adds that Polymarket disclosed another third-party compromise in June, with reported losses near $3 million. That is a second incident, not a trend.
What leaders should ask their teams
Hudson Rock offers guidance for application teams. Four questions follow from it.
First: which third-party scripts run on pages where users log in, pay or sign? Hudson Rock advises dropping integrations that those flows do not need.
Second: can the browser check what it loads? Subresource Integrity lets a browser reject a file whose contents changed. Hudson Rock recommends combining it with a tight Content Security Policy, which limits what a page may load, and with tested, deliberate updates. Its point is that whitelisting a trusted CDN by name says nothing about the actual file contents that arrive.
Third: what can untrusted page code reach? Hudson Rock suggests auditing the signer boundary, meaning which actions need fresh user confirmation.
Fourth: could you preserve evidence quickly? Hudson Rock advises saving exact response bytes, hashes and loader references before a changing CDN response hides the exposure window.
For individual users, Hudson Rock says to reject unexpected signing requests and check recent activity from a clean session. A page-speed tool should measure speed. Treat any script that can also act as the user as part of your security perimeter.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Hudson Rock.
