Dissecting the Polymarket Malicious Javascript Exploit Compromise - An Analysis

Dear blog readers,

This is Dancho.

I just came across to a very interesting development where real-time OSINT and malicious javascript exploit serving campaign reproduction is what I have in mind.

Long story short.

Polymarket just got compromised with a very interested third-party script loading on the front page (hxxp://cdn.debugbear.com/C7xcKKrjUnXK.js -> hxxp://api.fun.xyz/v1/checkout/quoteV2).

Here's the analysis.

1. Starts on load and checks its environment. The startdebugger name is misleading: an immediately invoked function starts the attack without a separate call. It requests configuration from hxxp://data.debugbear[.]com/metrics/init and geoblock information from hxxp://polymarket.com/api/geoblock. It exits for a blocked location. If configuration retrieval fails, it uses a hard-coded recipient, a $10 minimum portfolio value, a $10 minimum value per position, and POL as its preferred withdrawal currency. A successful configuration response can change the recipient and thresholds.

2. Finds authority in the active Polymarket page. It reads polymarket.auth.params, polymarket.auth.proxyWallet, and poly_clob_api_key_map from browser local storage. It then searches React component internals attached to page elements for a live CLOB trading client with order methods and a signer. If the client is absent, it retries and can navigate to a path based on the account address. It requires account data, CLOB credentials, and a usable client before proceeding. I found no code that sends the raw credential map, seed phrase, or private key; its method is to reuse the page’s existing signing capability.

3. Inventories and reports the account. It queries Polymarket positions and Polygon balances of pUSD and USDC.e. The positions query considers at most 200 returned positions and applies a size threshold before the later value threshold. It attempts to POST the EOA and deposit-wallet addresses, IP and country, operating system, account type, portfolio value, liquid balance, and position details to hxxp://data.debugbear[.]com/metrics/submit. Later requests to /metrics/update and /metrics/handle report intended recipients and transaction hashes.

4. Attempts to drain liquid funds. It builds a signed Polygon EIP-712 DepositWallet batch, obtains a wallet nonce, and submits the batch through Polymarket’s relayer. Its calls approve the pUSD collateral off-ramp and unwrap pUSD into USDC.e. It asks hxxp://api.fun[.]xyz/v1/checkout/quoteV2 for a swap route whose recipient address is the configured destination, preferring POL and then USDC. If both quote requests fail, it constructs a direct USDC.e ERC-20 transfer to that destination. Polymarket’s documentation confirms the roles of pUSD, USDC.e and the off-ramp.

5. Attempts to take market positions. For an eoa account, it reads the full on-chain balances of selected outcome-token IDs and builds an ERC-1155 safeBatchTransferFrom from the user’s deposit wallet to the configured recipient. For a magic account, it tries fill-and-kill SELL orders at roughly 97% of the current price, then 50%, then the market’s minimum tick, before attempting to withdraw the resulting liquid balance. It may attempt a liquid withdrawal before handling positions when liquid value exceeds position value, and tries again afterward. The Conditional Tokens and deposit-wallet contracts used here are documented Polymarket infrastructure, not attacker wallets.

Those recipient-directed swaps and transfers, coupled with automated liquidation, are why I classify this as a drainer rather than a monitoring script. The file contains no visible operating-system command execution, persistence installation, or second-stage JavaScript download.

Intent is clearer than outcome. The code treats relayer states SUBMITTED and PENDING as success, which does not prove settlement. Its balance-settlement wait has a bug: it assigns a newly read balance to the comparison variable immediately before checking whether the new balance is at least that same value, so a successful first read ends the wait. Whether signatures were granted, transactions settled, or reports reached their server requires browser or on-chain evidence.

Here are the IoCs:

Fallback Polygon recipient - 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18 — a remote configuration response can replace it

Configuration request - hxxp://data.debugbear[.]com/metrics/init?referrer=4c6b64a0-a7ef-4c0f-9c70-3a4e6f89065c

Reporting paths - hxxp://data.debugbear[.]com/metrics/submit, /metrics/update, /metrics/handle

Tracking ID - 4c6b64a0-a7ef-4c0f-9c70-3a4e6f89065c