Polymarket paused trading an hour; Hudson Rock links a DebugBear script to wallet draining, losses unverified

The file was still being served 12 minutes 46 seconds after Polymarket's build dropped it

Hudson Rock downloaded the same 15,187 byte JavaScript file from a DebugBear address at 18:12:06 UTC on 29 October 2026, and again at 18:13:04 UTC. Polymarket's production build that removed its DebugBear monitoring script carries the timestamp 17:59:20 UTC, and the exchange's status page opened its incident at 18:05:18 UTC. So the file was still answering 12 minutes 46 seconds after the build that dropped it, and 6 minutes 48 seconds after the exchange went to cancel only mode (all derived from Hudson Rock's and Polymarket's own timestamps). Hudson Rock's homepage capture at 18:12:06 contained no reference to the file, so Polymarket's pages had stopped asking for it. That is not the same as the file being harmless, and it is not the same as the damage having stopped.

That ordering is close to all the record fixes. It does not say when the file first ran on Polymarket pages, how many sessions loaded it, how it came to hold wallet draining logic, or who put it there. Nor does it fix the loss. Five figures are in circulation, from $2.19 million to $2.71 million (a gap of $0.52 million, so the top figure is 24 per cent above the bottom, derived), and none of them is a verified count of what victims lost. Polymarket has published no amount and no number of affected users in anything read for this briefing.

This briefing reads Polymarket's status page and Hudson Rock's technical post as the primary records, with BleepingComputer, SecurityWeek and Decrypt as secondary reporting, all read from 09:49 UTC on Friday 30 October 2026. Polymarket's and DebugBear's own posts on X could not be read: X's robots file disallows automated access, so those posts appear here only as the three news sites quote them, and Polymarket's post as a screenshot on Hudson Rock's page. DebugBear's own website did not answer when requested (a Cloudflare error code, then a server error), so nothing here comes from DebugBear's own pages. The interests are plain. Polymarket is the victim and the source of the statement, and wants users reassured. Hudson Rock sells cybercrime intelligence, its page carries offers for its own exposure checks, and it labels the post a developing investigation. Everything below is an allegation or a measurement by a named party, and the briefing says which.

Whose number is whose

BleepingComputer's headline says $2.5 million traced, SecurityWeek's says $2 million drained, and Hudson Rock's page says $2.19 million. They are not the same quantity. The table sets out what each one measured, using only what each source prints.

The honest summary is a range, not a number: between about $2.2 million and $2.7 million sat in or passed through the attacker's address by the sources' own measures, and the first thing a reimbursement needs, a list of affected accounts, has not been published. The 710 and 731 counts are a reminder that the unit matters: deposit wallets, addresses and people are three different counts.

What can be dated, and what cannot

Polymarket's status page carries four timestamps, and Hudson Rock's post adds its own. Put on one clock (UTC, with the Eastern times in BleepingComputer converted by this site because US clocks were on summer time), they give this sequence. The exchange was in cancel only mode and relayer actions were paused from 18:05:18 to 19:05:22, which is 1 hour 0 minutes 4 seconds (derived). Decrypt explains the relayer as the service that submits users' signed transactions to the blockchain.

Zoom

Two cautions from Hudson Rock apply to this table. Hudson Rock calls its build timestamp "not a verified containment time", and says the file's Last Modified date should not be used to infer when an attack began. The scanner's dates are also soft: its pages give times in CET, which this site converted by subtracting one hour, and the scanner's records were not authenticated. What the table can support is narrow. The integration was present in a public scan on the afternoon of 29 October, was removed from Polymarket's build before the exchange paused, and the vendor's file still carried the payload after both.

What the script did, as Hudson Rock reads it

Hudson Rock downloaded the file as text, reviewed it statically and did not run it, connect a wallet or sign anything. Its central finding is that the script reuses authority already available in the authenticated application: it looks for the trading machinery the logged in user has already authorised, and tries to use it. BleepingComputer's own analysis of a copy of the file reaches the same description: it checks whether the visitor is logged in, then uses the existing trading session and the platform's trading functions.

Zoom

In Hudson Rock's reading the sequence is this. The script reads three local storage entries, which give authorisation context, the deposit wallet address and a map of API credentials for its order book interface. It then searches the page's internal React structures for an object that can place orders. It queries balances and positions and applies thresholds (the fallback settings use 10 for total value and 10 per position), and it exits if Polymarket's geoblock response marks the visitor as blocked. For accounts it classes as EOA, it builds a batch transfer of position tokens to the configured recipient. For Magic or other accounts it submits SELL orders at increasingly aggressive prices and then attempts to move the proceeds. It builds signed batch messages for the deposit wallet and asks the existing signer for signatures before submitting them to Polymarket's relayer. Finally it sends wallet addresses, IP and country, operating system, account type, portfolio values and transfer results to a data host on the vendor's domain.

Three limits in Hudson Rock's own text matter more than the sequence. First, it says its review "did not identify a routine" that sends a credential map, password, seed phrase or private key to the reporting endpoint, so the risk it describes is borrowed authority, not stolen keys. Second, it says the claim that the script sells everyone's holdings would be inaccurate: one branch moves position tokens and the other sells, and success depends on account state, signer, trading responses and transaction execution. Third, it says a signing request is not proof of a silent signature or a completed theft, and it found a balance polling comparison that compares a value with itself, which shows why intended behaviour is not outcome. BleepingComputer adds that the file contacted the vendor's data host to receive instructions as well as to send data; Hudson Rock reports that its read only request to the configuration path returned a 404 and that the sample falls back to built in settings in that case. The two readings are consistent with remote configuration being possible but not needed.

Zoom

The screenshot is the source figure behind the $2.19 million number. It shows what Hudson Rock says it shows: a balance at the address hard coded in the script, and a run of outgoing transfers to a Polymarket contract. It does not show where the funds came from, how many accounts they came from, or whether any were later returned. Polymarket's own documentation, which Hudson Rock cites, says a deposit wallet is the default wallet type for accounts deployed on or after 4 May 2026, and that Magic and Safe wallets are older types. That is why a single script needed branches.

What the record states, and what it leaves open

The vendor's own advice is the strongest sign of how wide the doubt runs. As quoted by BleepingComputer and SecurityWeek, DebugBear told every user of its real user monitoring product to remove the embed code from their websites. That reads as a precaution for every customer, which suggests the vendor could not yet rule out wider exposure (inference). Hudson Rock found no sign that other customers were targeted, which is a finding about what it saw, not a guarantee.

Two friendly names doing the work of controls

The first is "monitoring". A real user monitoring snippet is sold as a way to measure how fast pages load, and Hudson Rock's opening line says a performance monitoring integration should measure how quickly a page loads. But a script included directly in a page runs with the page's privileges. The Mozilla Developer Network says such a script "would have access to your other scripts and data", and that a malicious one could secretly send user data to a third party server. On a trading page, the data and the scripts include the signer. The name of the tool describes what it is for. It says nothing about what it can reach.

The second is "third party". It describes the contract, not the privilege. Once the script tag is in the page, the vendor is inside the trust boundary, and so is anyone who can change the vendor's file. Polymarket's statement uses the phrase for the party that was breached, which is accurate about who was breached and silent about whose page ran the code. The same applies to "allowed" hosts: Hudson Rock reports that the public scan showed Polymarket's Content Security Policy permitting the vendor host, and says that allowing a trusted CDN does not verify the bytes it serves. That scan detail was reported by Hudson Rock and was not independently confirmed for this briefing.

Zoom

The second vendor script incident in 126 days, and what "new" means

SecurityWeek's headline calls this a new supply chain attack, and its text points to an earlier Polymarket disclosure. On 25 June 2026 Polymarket said, in a post quoted by SecurityWeek: "This morning we discovered a 3rd party vendor had been compromised, injecting a malicious script into our frontend for some users." The interval from 25 June to 29 October is 126 days (derived). SecurityWeek reported losses of about $3 million then, from at least 11 victims according to a blockchain analyst, and PeckShield's account of a phishing campaign that took roughly $3 million of pUSD. Decrypt, citing Bubblemaps, put the affected accounts at fewer than 15. Neither report named the vendor, and Polymarket declined further comment to both.

Hudson Rock says plainly that the June figures and reimbursement promise concern the June incident and do not establish anything about 29 October. No source read says the two vendors are the same, that the same actor is involved, or that the June vendor was DebugBear. What the two events share is a mechanism: a script from a supplier ran in Polymarket's own frontend. Decrypt also reports a separate May incident, a private key compromise of an internal top up wallet worth roughly $700,000, which is a different failure and is mentioned here only so readers do not count it as a third script incident.

The pattern is not unique to this platform. This site has already covered Sansec's report of a card skimmer hidden in Convertr's analytics script, where a tracker file on a supplier's own server reached every checkout that loaded it. The common thread is that a script added for measurement, not for payment, ended up beside the thing of value. It is a pattern, not the same incident, and the Polymarket record does not say how DebugBear's file was changed.

What to do, in the order worth doing it

On approvals: Hudson Rock's description is of a script that used the session's existing signing ability, not of new token approvals being created, so revoking approvals is a general hygiene step here rather than a fix for what this script did. Which step helps a particular user depends on what the platform's own investigation finds, and Polymarket has not published it.

Technical details

Everything in the first four code blocks is copied from Hudson Rock's post of 29 October 2026, read 30 October 2026, where it is printed as indicators of the captured sample, or from Polymarket's status page. The domains are real service infrastructure of a legitimate vendor, so the file hash, the exact path and the behaviour are the stronger detection context. Hudson Rock states that no address is presented as proof of a quantified theft. Hostnames are defanged here; a defender searches proxy, DNS and browser logs for the plain forms.

Captured script: cdn.debugbear[.]com/C7xcKKrjUnXK.js
File size: 15,187 bytes in both captured responses
SHA-256: 0755e767504d8103f6c27b9e765a1026507a17c04513242adb503df7777879e5
Fallback recipient: 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18
Tracking identifier: 4c6b64a0-a7ef-4c0f-9c70-3a4e6f89065c
Reporting paths: data.debugbear[.]com/metrics/submit
                 data.debugbear[.]com/metrics/update
                 data.debugbear[.]com/metrics/handle

The three browser storage entries the script reads, as named by Hudson Rock. A site owner can check whether any third party script on a signed in page can read these keys, and a user cannot see them without developer tools. Hudson Rock says the script reads them but found no routine that sends the credential map out.

polymarket.auth.params
polymarket.auth.proxyWallet
poly_clob_api_key_map

The production build metadata that Hudson Rock found in a first party Polymarket asset, which is the record of the removal. A build timestamp is not a deployment time. This is the only place in the sources where the integration's removal is dated.

Environment: production
Change message: chore(polymarket): remove debugbear rum script (#15337)
Build timestamp: 2026-10-29T17:59:20.443Z
Commit identifier: f908fe564ea73067b09ab1f0c5d683970020fbca
Asset SHA-256: 01c5bc78c4118115bd849ad34e3c42d7ff39479a0feb5b216b1e1ffdc02f853d

Polymarket's own words on its status page, the nearest thing to a primary statement the sources offer. The page stores the incident as a notice with four updates. The text below is the second update, posted at 18:37:02 UTC (the status page's own timestamp).

We have identified and fixed the issue impacting our international platform, Polymarket.com. One of our third party providers was compromised, and we have referred this to relevant law enforcement. Anyone who has been impacted will be made whole. Out of an abundance of caution, we have temporarily halted trading and are working to bring the platform back online.

What a page owner can set. The Mozilla Developer Network's page on Subresource Integrity says to add the integrity attribute to the script element, with a hash prefixed sha256, sha384 or sha512, and the crossorigin attribute, because a cross origin request with an integrity value must use CORS. The page prints only a placeholder example on an example domain, which this briefing does not reproduce as a code block. A real value is a base64 hash of the file you reviewed, and it protects only a file that does not change.

What to hunt for, derived by this site from the indicators above and not printed by any primary. Search proxy, DNS, CSP report and browser telemetry logs from at least 27 October 2026 (the file's Last Modified date) for the strings in the first block, and compare the bytes any of your own pages received from that address with the SHA-256 above. A match on the hostname alone is weak, as Hudson Rock says the hostnames are genuine service infrastructure.

cdn.debugbear[.]com/C7xcKKrjUnXK.js
data.debugbear[.]com/metrics/
SHA-256 of the response body equal to 0755e767504d8103f6c27b9e765a1026507a17c04513242adb503df7777879e5
any request to a new third party host from a page that holds a wallet session

What the primary sources do not print: no deobfuscated source, no list of affected account identifiers, no transaction hashes for victim transfers (Hudson Rock says direct explorer retrievals did not yield verifiable transaction evidence), and nothing from DebugBear about how its file was changed. This briefing therefore prints none of those, and does not reproduce any part of the script.

The question that exposes the gap

Polymarket pulled the script from its build, paused trading, and promised to make users whole. All three can be true, and the file can still have answered requests afterwards, and the list of who was hit can still be unpublished. As of 10:05 UTC on 30 October 2026, none of the sources read gave a number of affected users, a verified loss, the route into DebugBear or an attacker. Treat any of those that appears later as new and check who measured it.

So the question for anyone who runs a page that holds a session, a signer or a card: which scripts run on that page today, who can change their bytes without telling you, and how would you know within the hour?

Key facts