Polymarket Breach Alert: Wallet-Draining Code Found in a Third-Party Script

The supplied screenshot shows substantial holdings at the payload’s fallback recipient address. Aggregate losses remain unverified.

A performance-monitoring integration should measure how quickly a page loads. The JavaScript Hudson Rock retrieved from a DebugBear URL associated with Polymarket does something far more consequential: it searches for a logged-in user’s trading client, inspects their portfolio, and attempts to sell or transfer their assets. [1]

On October 29, 2026, we independently downloaded the file identified in a community warning and reviewed it as text. Two downloads returned the same 15,187-byte payload. We also found a separate artifact in Polymarket’s published application code: production build metadata containing the change message “chore(polymarket): remove debugbear rum script (#15337)” , with a build timestamp of 17:59:20 UTC that evening. [1] [2]

A supplied PolygonScan screenshot shows more than $2 million in holdings at the address embedded in the payload as its fallback recipient. The matching address links the screenshot to the script, but the balance is not a verified total of stolen funds. The number of affected users, aggregate losses attributable to this incident, and the initial compromise mechanism remain unresolved. [11]

The warning that led to the payload

The evidence supplied to Hudson Rock includes a screenshot of a message attributed to a user named Vivian. It identifies cdn.debugbear[.]com/C7xcKKrjUnXK.js and alleges that the file accesses login credentials, triggers wallet signatures, sells holdings, and transfers assets. The message also says its author retrieved the same content and hash more than once. [3]

We tested the central technical allegation by retrieving that exact URL. At 18:12:06 UTC , it returned JavaScript containing the behavior described below. A repeat retrieval at 18:13:04 UTC returned identical bytes. This establishes repeatability for our captures; it cannot establish that our copy matches the unseen hash referenced in the screenshot. [1]

A separately published WhoGetsMyData scan dated October 29 records Polymarket loading the same script URL and permitting its host in the page’s Content Security Policy. We could review the publicly indexed report, but could not retrieve its underlying evidence files. It corroborates the integration’s presence; we cannot compare the script bytes it received with our captured sample. [4]

The financial evidence: millions at the recipient address

The supplied PolygonScan screenshot identifies 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18 . This is the same address hard-coded into the retrieved script as its fallback recipient. At the time of the screenshot, its overview shows $2,178,191.78 in POL and a separate $16,170.39 in token holdings . Those two displayed values sum to approximately $2.19 million . [1] [11]

This is evidence of substantial holdings at an address explicitly selected by the payload. It is not a verified accounting of the proceeds of this incident: establishing that would require tracing the source and timing of individual transfers.

It reaches for the trading session already inside the page

The most revealing feature is the way the payload looks for authority. It searches the application already running in the browser for the objects needed to place orders and request signatures. Its target is the user’s active Polymarket session. [1]

1. Read the account’s authentication context

The script reads three local-storage entries: polymarket.auth.params , polymarket.auth.proxyWallet , and poly_clob_api_key_map . These provide authorization context, the deposit-wallet address, and a map of CLOB API credentials. The code distinguishes between eoa and magic account types and checks for account and credential data before continuing. [1]

The distinction between access and exfiltration matters here. The sample reads credential-related material, but our review did not identify a routine that sends the credential map, a password, a seed phrase, or a private key to its reporting endpoint. Its central approach is to reuse authority already available in the authenticated application.

2. Find the live trading client

The code traverses React’s internal component structures, looking through component properties and hook state for an object with trading methods such as postOrder and createOrder or createMarketOrder . Once found, it attempts to use that object and its signer. This is application-specific logic aimed directly at Polymarket’s trading workflow. [1]

The payload searches for the trading machinery the user has already authorized and tries to use it to move their assets.

The payload searches for the trading machinery the user has already authorized and tries to use it to move their assets.

Polymarket’s documentation distinguishes API-request authentication from wallet authorization: CLOB API credentials authenticate private requests, while placing an order also requires a wallet signature. The payload’s for the live client and signer is therefore a significant part of its design. [6]

3. Inspect the portfolio and choose a path

The script queries balances and positions, calculates a portfolio value, and applies configurable thresholds. Its fallback configuration uses a total-value threshold of 10 and a per-position threshold of 10. It also checks Polymarket’s geoblock response and exits if the response marks the visitor as blocked. These are selection conditions visible in the code, not measurements of the affected population. [1]

Transfer position tokens

For eligible positions, the code builds an ERC-1155 batch transfer to the configured recipient.

Magic / non-EOA branch

Attempt sales, then move balances

The code submits SELL orders at increasingly aggressive prices and then attempts to transfer available proceeds.

This branching means that “the script sells everyone’s holdings” would be inaccurate. One path attempts to move the position tokens themselves. Both paths are designed to redirect value, but their success depends on the account state, signer, trading responses, and transaction execution.

4. Request signatures and submit transfers

The payload constructs EIP-712 DepositWallet batch messages for Polygon, requests signatures through the existing signer, and attempts to submit the signed batches to Polymarket’s relayer. Balance handling includes conversion and swap routes, with a direct token-transfer fallback. [1] Polymarket documents signed batches as a normal mechanism for authorizing deposit-wallet actions; the dangerous element here is the untrusted code selecting the actions and recipient. [7]

A signing request is not proof of a silent signature or a completed theft. A provider may prompt, reject, or apply session-specific authorization rules. We did not connect a wallet or execute the sample. The payload’s own success checks also accept some pending relayer states, which cannot independently establish blockchain settlement.

5. Report wallet data and attempted outcomes

The sample constructs requests to data.debugbear[.]com containing wallet addresses, IP and country information, operating system, account type, portfolio values, position summaries, and transfer-result fields. Its paths include /metrics/submit , /metrics/update , and /metrics/handle . [1]

DebugBear’s own documentation identifies its CDN and data host as parts of legitimate monitoring infrastructure. Their names alone are not evidence of malice. The decisive evidence is the retrieved file’s trading, signing, recipient-selection, and transfer logic. That behavior does not belong in a page-performance measurement script. [5]

Polymarket’s own build records the removal

Our unauthenticated homepage capture at 18:12:06 UTC did not contain the DebugBear filename or a DebugBear allowance in the returned Content Security Policy. We then inspected all 102 first-party JavaScript files explicitly listed in that response, as inert text. The only DebugBear match was production build metadata describing its removal. [1] [2]

This is corroborating technical evidence, rather than a formal incident statement. A build timestamp does not establish the exact moment of deployment or complete containment. Previously opened tabs, cached responses, authenticated pages, and dynamically imported code are outside the scope of this homepage snapshot.

A timeline of what can actually be dated

All times below are UTC on October 29, 2026 . The screenshot’s undated 7:57 PM display and the script server’s Last-Modified header are not used to infer when an attack began.

17:59:20 Timestamp embedded in Polymarket’s production build metadata for the change removing the DebugBear RUM script. This is a build time, not a verified containment time. [2]

Timestamp embedded in Polymarket’s production build metadata for the change removing the DebugBear RUM script. This is a build time, not a verified containment time. [2]

18:12:06 Our first retrieval of the named CDN file returns the 15,187-byte payload. A separate homepage retrieval shows no direct DebugBear script reference. [1]

Our first retrieval of the named CDN file returns the 15,187-byte payload. A separate homepage retrieval shows no direct DebugBear script reference. [1]

18:13:04 A second download returns byte-for-byte identical JavaScript and the same SHA-256 hash. [1]

A second download returns byte-for-byte identical JavaScript and the same SHA-256 hash. [1]

18:13:43 We retrieve the first-party application asset containing the removal message and production build timestamp. [2]

We retrieve the first-party application asset containing the removal message and production build timestamp. [2]

The retrieved sample supports describing the file as wallet-draining code . Its author implemented account discovery, asset selection, signing requests, and transfers to a designated recipient. However, static analysis does not establish the effectiveness of every code path. We also found a balance-polling comparison that compares a newly assigned value with itself, illustrating why an intended workflow cannot be treated as a successful one. [1]

The additional screenshots show withdrawal activity and a substantial balance at the matching recipient address. We have not independently established the number of affected users, the total losses attributable to this incident, a transaction-by-transaction victim-to-recipient flow, the first malicious delivery, or the initial compromise mechanism. The evidence does not identify an attacker or demonstrate a wider compromise affecting other DebugBear customers. No current incident statement from Polymarket or DebugBear was independently verified during this review.

What users and defenders should do

For potentially exposed users

Reject unexpected signing and approval requests. Do not approve a message or transaction merely because it appears while a familiar site is open.

Close potentially exposed tabs and review activity through a trusted route. Check recent orders, position movements, and wallet transactions using a clean session or independently accessed explorer. Retain timestamps and transaction hashes for any anomaly.

Review sessions, API credentials, and permissions with the platform’s support guidance. Disconnecting a wallet does not reverse completed transfers or automatically revoke on-chain approvals. Avoid “recovery” links sent by unsolicited accounts, and never provide a seed phrase.

For application and incident-response teams

Preserve the delivery evidence. Capture the exact response bytes, hashes, HTTP metadata, loader references, and browser request history before a changing CDN response obscures the exposure window.

Review third-party execution on sensitive pages. Remove unnecessary integrations from authenticated trading and signing flows. Investigate exact payloads and request paths; a legitimate vendor hostname alone is an unreliable maliciousness test.

Constrain and verify executable dependencies. Where assets can be pinned, Subresource Integrity lets the browser reject unexpected file contents. Pair it with a restrictive Content Security Policy and a controlled update process; simply allowing a trusted CDN does not verify the bytes it serves. [9]

Audit the signer boundary. Review what an authenticated page can request, which actions demand fresh user confirmation, and whether untrusted page code can reach the signing interface. Tie remediation to the affected sessions and authorizations actually established by the investigation.

Indicators and evidence for defenders

These indicators describe the captured sample. The domains are genuine service infrastructure; the file hash, precise paths, and associated behavior provide the stronger detection context. No address below is presented as proof of a quantified theft.

Methodology and scope. This investigation combined the three supplied screenshots, timestamped HTTP retrievals, SHA-256 comparison, static review of the suspect file, inspection of the public homepage and its 102 directly listed first-party script assets, and review of public documentation and reporting. All three hosted images were retrieved on October 29, 2026, at approximately 18:26 UTC. No downloaded script was executed, no wallet was connected, and no transaction was signed or broadcast. Direct explorer and RPC retrievals did not yield verifiable transaction evidence; the balance and withdrawal figures above were read from the supplied images. Aggregate incident losses and initial access remain unresolved.

Direct acquisition and static analysis. The exact script identified above returned HTTP 200 at 18:12:06 and 18:13:04 UTC on October 29, 2026, with identical bytes and the SHA-256 listed in the indicators table. The public homepage was captured at 18:12:06 UTC. The CDN response’s Last-Modified header reported October 27, 2026, at 12:50:43 GMT; that server-supplied field is not treated as the attack’s start. The malicious script is displayed as a defanged indicator rather than embedded or loaded by this article.

Polymarket production build metadata. First-party application asset containing the removal message , retrieved at 18:13:43 UTC. Asset SHA-256: 01c5bc78c4118115bd849ad34e3c42d7ff39479a0feb5b216b1e1ffdc02f853d . The embedded build timestamp and commit message are evidence of the served build’s metadata, not a formal incident disclosure or an independently verified deployment time.

Supplied script-warning screenshot. Hosted image of the Polymarket script warning . The media filename says “polygon_script”; the warning concerns the Polymarket script. The visible message attributes the warning to Vivian; its original platform context and posting date were not independently authenticated. Technical claims were checked against the separately retrieved script.

WhoGetsMyData. Public Polymarket privacy scan, dated October 29, 2026 . The indexed report records the exact script URL, browser requests, and CSP allowances. We did not obtain or authenticate the scanner’s archived script bytes, and do not claim its sample matches our captured payload.

DebugBear documentation. RUM installation , snippet delivery and performance , and RUM data proxy configuration . These establish the normal monitoring purpose and legitimate infrastructure context, not a vendor admission concerning this sample.

Polymarket API documentation. L1 and L2 authentication . Describes wallet-signature authorization and API-request authentication as distinct parts of trading.

Polymarket wallet documentation. Wallets and Authentication . Describes signed Deposit Wallet batches and relayer submission.

Mozilla Developer Network. Privacy on the web: third-party resources . Explains the privileges of a third-party script included directly in a page.

Mozilla Developer Network. Subresource Integrity . Describes cryptographic content verification for fetched resources and its deployment requirements.

Historical context only. Polymarket Traders announcement , published June 25, 2026, at 14:43:18 UTC according to X’s retrieved public embed metadata; and Decrypt’s June 25 coverage . Neither establishes the losses, scope, or response to the October 29 sample.

Supplied recipient-address screenshot. PolygonScan balance image for the script’s fallback recipient address . Visible figures: $2,178,191.78 POL value and $16,170.39 token holdings; the separate multichain widget shows $2,163,862.69. These are screenshot values, not an independently retrieved live balance or a verified total of stolen funds.