EN PT-BR
← Voltar ao feed
critical cryptocurrency financial services technology financial

Polymarket users drained via DebugBear RUM script hijack traced to registrar DNS compromise; ~$2.7M stolen, $3.9M refunds

6 fonte(s) · 6 atualização(ões) · publicado 29/10/2026 15:33 · coletado há 4 horas

Matéria consolidada. Reúne 8 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que as 6 fontes trouxeram em 02/11/2026 00:04; os links antigos trazem para cá.

Fontes: hackread.com ↗ thehackernews.com ↗ securityweek.com ↗ gbhackers.com ↗ bleepingcomputer.com ↗ infostealers.com ↗

On October 29, 2026, a supply-chain attack on the UK-based web performance monitoring vendor DebugBear caused a malicious version of its Real User Monitoring (RUM) script to be served to Polymarket users on its international platform (securityweek.com). The script hijacked authenticated trading sessions to sell positions and move assets to an attacker wallet, 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. Polymarket put the exchange in cancel-only mode at about 2:05 p.m. ET (18:05 UTC) and suspended relayer actions (securityweek.com, thehackernews.com). It declared the issue fixed at 2:37 p.m. and fully restored trading by about 3:05 p.m. (bleepingcomputer.com, gbhackers.com). DebugBear confirmed it was "impacted by an ongoing security incident", engaged specialist incident responders and told customers to remove its RUM embed code (bleepingcomputer.com, securityweek.com). Newer reporting says DebugBear attributes the incident to a compromise of its DNS records through its domain registrar. It has seen no sign of a break-in to its own systems and early findings suggest a single customer was targeted (thehackernews.com). Hudson Rock analyzed the payload, a 15,187-byte file served from cdn.debugbear[.]com/C7xcKKrjUnXK.js (infostealers.com). Losses are put at about $2.7 million (hackread.com, thehackernews.com), and Polymarket says it is returning $3.9 million in total ($2.7M stolen plus about $1.19M for pause-related losses) and referred the matter to law enforcement, described as UK law enforcement by hackread.com. The US platform was reportedly unaffected (securityweek.com, hackread.com). The exact victim count (710 to 726 wallets by different counts), the attacker's identity and DebugBear's investigation into the DNS compromise remain open.

Detalhes técnicos

  • The payload was served from DebugBear's CDN. The CDN Last-Modified header showed October 27, 2026 12:50:43 GMT, and two retrievals minutes apart returned byte-identical content (infostealers.com). A WhoGetsMyData scan dated October 29 recorded Polymarket loading the URL and allowing the host in its CSP (infostealers.com).
  • Delivery vector: DebugBear says its DNS records were compromised via its domain registrar (thehackernews.com). 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, and the swapped file was Polymarket's (thehackernews.com). No smart contract breach was reported (hackread.com).
  • The script read the local-storage keys polymarket.auth.params, polymarket.auth.proxyWallet and poly_clob_api_key_map, and distinguished eoa from magic account types (infostealers.com). No routine was found exfiltrating credential maps, passwords, seed phrases or private keys. The core technique is abusing authority already present in the authenticated session (infostealers.com, securityweek.com, thehackernews.com).
  • It walked React component properties and hook state to find objects exposing postOrder, createOrder or createMarketOrder, plus the associated signer. This is logic specific to Polymarket's trading workflow (infostealers.com).
  • It queried balances and positions and computed portfolio value. It applied thresholds (fallback total-value threshold 10, per-position threshold 10) and checked Polymarket's geoblock response, exiting if the user was blocked (infostealers.com).
  • Value was redirected in one of two ways. Accounts using their own crypto wallet had positions moved directly to the attacker wallet (an ERC-1155 batch transfer of position tokens). Email-login accounts had SELL orders submitted at increasingly aggressive prices and the proceeds moved out (infostealers.com, thehackernews.com). Depending on the authentication method, it could also convert holdings into transferable assets using Polymarket's own transaction functionality (bleepingcomputer.com). Hudson Rock noted that a signing request alone does not prove a trader signed without a prompt, since the wallet provider may still ask, refuse or apply its own session rules (thehackernews.com).
  • It built EIP-712 DepositWallet batch messages for Polygon, requested signatures through the existing signer and submitted signed batches to Polymarket's relayer, with conversion/swap routes and a direct token-transfer fallback (infostealers.com).
  • It beaconed wallet addresses, IP/country, OS, account type, portfolio values, position summaries and transfer results to data.debugbear[.]com via /metrics/submit, /metrics/update and /metrics/handle (infostealers.com). BleepingComputer notes that this C2/exfiltration channel suggests deep attacker access to DebugBear infrastructure (bleepingcomputer.com). Because the malicious script talked to DebugBear's own domain, a CSP allowing the vendor domain would have permitted the traffic (hackread.com).
  • GoPlus on-chain analysis traced the main attack path through 710 deposit wallets and 731 addresses. The hard-coded fallback recipient address matches the suspected attacker wallet seen by Arkham (securityweek.com). Betting Intelligence and Polysights also estimated about $2.7 million drained from 710 wallets (hackread.com).
  • Per Ohey's blockchain trace, the attacker wallet received funds between 17:10 and 18:02 UTC, collecting 28.6 million POL (about $2.64 million at $0.0922) and positions from 33 wallets. It forwarded all the POL to three other addresses between 18:28 and 18:38 UTC (thehackernews.com). BleepingComputer separately observed attacker wallet activity against Polymarket's token contract between 1:50 and 1:56 p.m. ET (bleepingcomputer.com).
  • Polymarket posted its first status update at 17:38 UTC (thehackernews.com). Its production build metadata, retrieved at 18:13:43 UTC, contains the commit message chore(polymarket): remove debugbear rum script (#15337). Its build timestamp is 17:59:20 UTC, equivalent to 1:59 p.m. ET and just before public disclosure (infostealers.com, bleepingcomputer.com, securityweek.com).
  • Polymarket removed the script, cleared caches, reset all active login sessions, paused trading and relayer actions, and referred the case to law enforcement (thehackernews.com, hackread.com).
  • Users reported unauthorized withdrawals and zero balances (gbhackers.com, hackread.com).
  • Context: this is Polymarket's second reported third-party compromise this year. In June, malicious code injected via a vendor was used to steal about $3M (securityweek.com, hackread.com). In April, the platform rejected a claim of 300,000 stolen user records (hackread.com).

Remediação

  • DebugBear customers: immediately remove the DebugBear RUM embed code from all sites, per DebugBear's advisory (bleepingcomputer.com, securityweek.com, hackread.com). cdn.debugbear[.]com had no DNS record when checked on November 1 (thehackernews.com).
  • Site operators: review third-party script inclusions and apply a strict CSP where possible. Monitor third-party code behavior at runtime and watch for unexpected build or script changes. Audit wallet activity for users who visited affected sites during the window (bleepingcomputer.com, securityweek.com, hackread.com). Subresource Integrity (SRI) has limits because RUM vendors update scripts frequently (Jscrambler's Gareth Bowker, via hackread.com). Hudson Rock advises keeping unneeded third-party code off pages where users trade or sign, and using SRI where files can be pinned (thehackernews.com).
  • Polymarket: is reintroducing third-party scripts with a stronger CSP, pinned versions and sandboxing (thehackernews.com).
  • Polymarket users: reject unexpected signing or approval prompts and close exposed tabs. Review recent orders, positions and on-chain transactions from a clean session, particularly those from October 29. Revoke unrecognized token approvals and unnecessary wallet permissions (infostealers.com, bleepingcomputer.com, hackread.com).
  • Reimbursement: Polymarket is returning $3.9M in total: about $2.7M to 726 affected wallets plus about $1.19M to roughly 5,500 wallets that lost money during the trading pause or had positions taken (thehackernews.com, hackread.com). By October 30, 689 of the 726 wallets had been refunded, with the remaining 37 being paid as they were checked (thehackernews.com). Hackread.com reports 95% of affected wallets refunded by Friday, losses under $10,000 refunded by October 30, and larger losses requiring a release form. This supersedes gbhackers.com's earlier note that no claims process had been published.

Relatos divergentes

  • Amount at risk: infostealers.com cites a PolygonScan screenshot showing roughly $2.19 million in holdings at the attacker address and stresses this is not a verified accounting of stolen funds. bleepingcomputer.com reports about 28.6 million POL (~$2.57 million) moved from that wallet to three others. securityweek.com reports estimates from roughly $2.19 million (Hudson Rock) to $2.71 million (GoPlus), with Arkham data showing a suspected attacker wallet holding about $2.65 million. thehackernews.com (Ohey trace) gives about $2.64 million in POL, and hackread.com about $2.7 million. Polymarket's refund of about $2.7 million (reported by thehackernews.com and hackread.com), which is the most recent figure, aligns with the upper estimates.
  • Number of victims: hackread.com (Betting Intelligence and Polysights) and GoPlus via securityweek.com cite 710 wallets. thehackernews.com, citing Polymarket, reports 726 affected wallets refunded, plus about 5,500 wallets compensated for pause-related losses. Ohey's trace counted positions collected from 33 wallets (thehackernews.com). The counts reflect different methods and the full scope is not confirmed. Polymarket's refund count is the most authoritative.
  • Cause and vendor confirmation: infostealers.com, the earliest source, said the initial compromise mechanism was unresolved. bleepingcomputer.com suggested deep attacker access to DebugBear infrastructure. thehackernews.com, the most recent source, reports DebugBear's statement that its DNS records were compromised through its domain registrar, with no sign of a break-in to its own systems and an investigation still ongoing. This is DebugBear's own account and is not independently verified.
  • Scope of targeting: securityweek.com said there was no indication other DebugBear customers were targeted. thehackernews.com reports DebugBear's early findings that the attack targeted a single customer, which is still preliminary.
  • Timing: hackread.com puts cancel-only mode at around 2:00 p.m. ET and resumption at 3:00 p.m. ET, while securityweek.com and thehackernews.com give 2:05 p.m. ET (18:05 UTC). Attacker wallet activity is placed at 1:50 to 1:56 p.m. ET by bleepingcomputer.com and 17:10 to 18:02 UTC (1:10 to 2:02 p.m. ET) by thehackernews.com.
  • Provider identity and IOCs: gbhackers.com (October 30, early) said no provider identity, malicious wallet addresses or other IOCs had been published. This is outdated: securityweek.com, later, names DebugBear as the compromised provider and the other sources give the attacker wallet and payload details.

Linha do tempo

  1. hackread.com ↗ · pub. 31/10/2026 11:05 · coletado 01/11 22:21

    Polymarket users lose $2.7M after DebugBear third-party monitoring script is replaced with malicious code

    ler a análise desta fonte

    Prediction market platform Polymarket halted trading on its international exchange on October 29 after users reported unauthorized withdrawals. Analytics firms Betting Intelligence and Polysights estimated about $2.7 million was drained from 710 wallets. The attacker replaced the monitoring script supplied by UK vendor DebugBear with malicious code that abused users' active sessions. Polymarket says it will return $3.9M in total and referred the incident to UK law enforcement.

    Technical Details

    • The compromised DebugBear real-user monitoring (RUM) script ran on Polymarket.com. The attacker swapped it for malicious code targeting Polymarket users.
    • For users with Polymarket open during a short window, the script used active sessions to sell trading positions and move funds out of their wallets.
    • No smart contract breach was reported.
    • The malicious script exchanged data with a server on DebugBear's own domain, so a CSP allowing the vendor domain would have permitted the traffic. Subresource integrity is of limited use because vendors update RUM scripts frequently (Jscrambler's Gareth Bowker).
    • This is Polymarket's second reported third-party compromise this year. In June, malicious code injected via a vendor was used to steal about $3M. In April, the platform rejected a claim of 300,000 stolen user records.

    Remediation

    • Polymarket removed the compromised code, cleared caches, paused trading and relayer actions, and reset active login sessions. It entered cancel-only mode around 2:00 p.m. ET and resumed trading at 3:00 p.m. ET. The US platform was not affected.
    • DebugBear asked RUM customers to remove the embedded code.
    • Polymarket is returning $3.9M ($2.7M stolen plus $1.2M for pause-related losses). 95% of affected wallets were refunded by Friday. Losses under $10,000 were refunded by October 30, and larger losses require a release form.
    • Users should review transaction history and revoke unrecognized token approvals. Organizations should monitor third-party code behavior at runtime.
  2. thehackernews.com ↗ · pub. 01/11/2026 04:25 · coletado 01/11 05:00

    Polymarket traders lose ~$2.7M after DebugBear script hijacked via registrar DNS compromise

    ler a análise desta fonte

    On October 29, malicious code replaced a page-speed script that Polymarket loaded from DebugBear's real user monitoring (RUM) service. It sold or moved the positions of signed-in traders to an attacker wallet. Polymarket says it is refunding about $2.7 million to 726 affected wallets, and about $2.64 million in POL reached the attacker wallet in under an hour. DebugBear says its DNS records were compromised through its domain registrar, and early findings suggest the attack targeted a single customer. It has seen no sign of a break-in to its own systems, though its investigation continues.

    Technical Details

    • Hudson Rock analyzed the malicious file without running it. The code reuses the access a signed-in trader already has in an open Polymarket page and reads account data stored in the browser, including trading API keys. It found no code that exfiltrates keys, passwords, seed phrases or private keys.
    • The code locates the site's order-placing component and the account's signer, then asks that signer to sign requests and passes them to Polymarket's relayer. Accounts using their own crypto wallet had positions moved directly to the attacker wallet. Email-login accounts had positions sold at ever-worse prices and the proceeds moved out. Hudson Rock noted that a signing request alone does not prove a trader signed without a prompt, since the wallet provider may still ask, refuse or apply its own session rules.
    • 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, and the swapped file was Polymarket's.
    • Per Ohey's blockchain trace, the attacker wallet received funds between 17:10 and 18:02 UTC, collecting 28.6 million POL (about $2.64 million at $0.0922) and positions from 33 wallets. It forwarded all the POL to three other addresses between 18:28 and 18:38 UTC.
    • Polymarket posted its first status update at 17:38 UTC and put the exchange in cancel-only mode with relayer actions paused at 18:05 UTC. It removed the script, cleared caches, reset all login sessions, paused trading and referred the case to law enforcement.
    • By October 30, 689 of the 726 affected wallets had been refunded, with the remaining 37 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, for $3.9 million returned in total.

    Remediation

    • DebugBear told RUM customers to remove its embed code. cdn.debugbear[.]com had no DNS record when checked on November 1.
    • Polymarket is reintroducing third-party scripts with a stronger Content Security Policy (CSP), pinned versions and sandboxing.
    • Hudson Rock advises keeping unneeded third-party code off pages where users trade or sign, and using Subresource Integrity (SRI) where files can be pinned, since a CSP that allows a trusted CDN does not verify the files it serves. It also advises reviewing what code on a signed-in page can ask the signer to do, and telling traders to reject unexpected signing requests.
  3. securityweek.com ↗ · pub. 30/10/2026 06:41 · coletado 30/10 07:00

    Polymarket traders lose $2M+ after supply chain compromise of DebugBear RUM script

    ler a análise desta fonte

    Polymarket halted trading on its international platform (Polymarket.com) on October 29 after users reported unauthorized withdrawals, switching the exchange to cancel-only mode and suspending relayer actions. The company confirmed that a third-party provider was compromised, referred the matter to law enforcement, and pledged to make all affected traders whole. Researchers attributed the theft to malicious JavaScript served from DebugBear, a UK-based website performance monitoring firm, via its real user monitoring (RUM) snippet. Loss estimates range from roughly $2.19 million (Hudson Rock) to $2.71 million (GoPlus), with Arkham data showing a suspected attacker wallet holding about $2.65 million. Polymarket's US platform was reportedly unaffected, and there is no indication other DebugBear customers were targeted.

    Technical Details

    Hudson Rock obtained the malicious JavaScript from a DebugBear address used by Polymarket. The code enumerated a logged-in user's trading tools and portfolio and, depending on account type, either sold positions and moved the proceeds or sent position tokens directly to an attacker-controlled address. Hudson Rock noted the sample read credential-related material but found no routine exfiltrating credential maps, passwords, seed phrases or private keys — the core technique was abusing authority already present in the authenticated session. A Polymarket production build timestamped 17:59 UTC carried a change note removing the DebugBear script. GoPlus on-chain analysis traced the main attack path through 710 deposit wallets and 731 addresses. The hard-coded fallback recipient address matches the suspected attacker wallet seen by Arkham. How the script was tampered with, and how many users were hit, remain undetermined.

    Remediation

    DebugBear confirmed it was "impacted by an ongoing security incident", engaged specialist incident responders, and urged customers to remove its RUM snippet from their websites. Organizations embedding third-party JavaScript should audit externally hosted scripts, apply Subresource Integrity and CSP controls, and monitor for unexpected build or script changes. Polymarket previously suffered a similar third-party frontend script injection in June with around $3 million in losses.

  4. gbhackers.com ↗ · pub. 30/10/2026 03:06 · coletado 30/10 04:00

    Polymarket halts trading after third-party provider compromise; users report drained balances

    ler a análise desta fonte

    Polymarket temporarily suspended trading on its international platform, Polymarket.com, after disclosing that one of its third-party providers was compromised. Users reported unauthorized withdrawals and zero balances following the incident, though these remain individual claims rather than verified loss assessments. The company said it identified and fixed the issue, referred the matter to law enforcement, and committed to fully reimbursing affected traders. Trading was restored later the same day. No provider identity, exploit chain, loss total, or affected-user count has been published.

    Technical Details

    The disclosure confirms a supply-chain/third-party compromise but does not specify whether attackers reached authentication infrastructure, wallet services, application code, or another integration. No malicious wallet addresses, transaction hashes, or other IOCs were released, and no threat actor attribution is supported by the available evidence. The article notes that separate Web3 supply-chain investigations have documented malicious dependencies harvesting private keys and recovery phrases, but presents this as context only.

    Remediation

    Polymarket states the issue is fixed and trading resumed. Reimbursement remains a commitment with no published deadline, eligibility criteria, or claims process. Open questions include the provider's identity, scope of unauthorized access, and whether exposed credentials or wallet permissions still require remediation; users should review account activity and revoke unnecessary wallet permissions.

  5. bleepingcomputer.com ↗ · pub. 29/10/2026 18:47 · coletado 29/10 19:00

    Polymarket halts trading after DebugBear supply-chain compromise delivers crypto-draining JavaScript; ~$2.5M traced

    ler a análise desta fonte

    Polymarket temporarily suspended trading on October 29, 2026 after attackers compromised third-party web performance monitoring provider DebugBear and used its Real User Monitoring (RUM) JavaScript to distribute a cryptocurrency-draining script to Polymarket users. Hudson Rock researchers identified the malicious script at cdn.debugbear[.]com/C7xcKKrjUnXK.js and an attacker-controlled wallet 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. BleepingComputer's blockchain analysis found roughly 28.6 million POL (~$2.57 million) moved from that wallet to three others. Polymarket placed the exchange in cancel-only mode at 2:05 p.m. ET, declared the issue fixed at 2:37 p.m., and fully restored trading by 3:05 p.m., pledging to reimburse affected traders and referring the matter to law enforcement. DebugBear confirmed an ongoing security incident and told customers to remove its RUM embed code.

    Technical Details

    The malicious JavaScript was served from DebugBear's CDN and also used data.debugbear.com as a command-and-control and exfiltration channel, suggesting deep attacker access to DebugBear infrastructure. The script checked whether a visitor was authenticated to Polymarket, then hijacked the existing trading session: it enumerated crypto balances and prediction-market positions, and depending on the authentication method either auto-sold positions, transferred prediction-market tokens directly to the attacker wallet, or converted holdings into transferable assets using Polymarket's own transaction functionality. It reported targeted accounts, wallet addresses, balances and transaction results back to the C2. Hudson Rock also found Polymarket build metadata with the commit message "chore(polymarket): remove debugbear rum script (#15337)" timestamped 1:59 p.m. ET, just before public disclosure. Attacker wallet activity against Polymarket's token contract was observed between 1:50 and 1:56 p.m. ET.

    Remediation

    Any organization using DebugBear RUM should immediately remove the embed code from their sites, per DebugBear's advisory. Review third-party script inclusions, apply Subresource Integrity and strict CSP where possible, and audit wallet activity for users who visited affected sites during the window. Polymarket users should review transactions and positions from October 29 and monitor for reimbursement guidance.

  6. infostealers.com ↗ · pub. 29/10/2026 15:33 · coletado 29/10 17:01 primeiro registro

    Polymarket supply-chain compromise: wallet-draining JavaScript served from DebugBear RUM script

    ler a análise desta fonte

    Hudson Rock independently retrieved and statically analyzed a 15,187-byte JavaScript payload served from cdn.debugbear[.]com/C7xcKKrjUnXK.js, a third-party RUM (real user monitoring) asset loaded by Polymarket. Instead of measuring page performance, the script reads Polymarket authentication data from local storage, traverses React internals to locate the live trading client and signer, inspects the user's portfolio, then attempts to sell positions and transfer assets to a hard-coded fallback recipient address 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. A supplied PolygonScan screenshot shows roughly $2.19 million in holdings at that address, though this is not a verified accounting of stolen funds. Polymarket's production build metadata retrieved at 18:13:43 UTC on October 29, 2026 contains the commit message chore(polymarket): remove debugbear rum script (#15337) with a build timestamp of 17:59:20 UTC, corroborating removal. The number of victims, aggregate losses, attacker identity, and the initial compromise mechanism remain unresolved; no verified incident statement from Polymarket or DebugBear was obtained.

    Technical Details

    • Reads local-storage keys polymarket.auth.params, polymarket.auth.proxyWallet, and poly_clob_api_key_map; distinguishes eoa vs magic account types. No routine was found exfiltrating seed phrases or private keys — the design reuses authority already present in the authenticated session.
    • Walks React component properties and hook state searching for objects exposing postOrder, createOrder, or createMarketOrder, plus the associated signer — application-specific logic targeting Polymarket's trading workflow.
    • Queries balances/positions, computes portfolio value, applies thresholds (fallback total-value threshold 10, per-position threshold 10), and checks Polymarket's geoblock response, exiting if blocked.
    • Two paths to redirect value: submitting SELL orders at increasingly aggressive prices then transferring proceeds, or building an ERC-1155 batch transfer of position tokens to the configured recipient.
    • Constructs EIP-712 DepositWallet batch messages for Polygon, requests signatures through the existing signer, and submits signed batches to Polymarket's relayer, with conversion/swap routes and a direct token-transfer fallback.
    • Beacons wallet addresses, IP/country, OS, account type, portfolio values, position summaries and transfer results to data.debugbear[.]com via /metrics/submit, /metrics/update, /metrics/handle.
    • CDN Last-Modified header reported October 27, 2026 12:50:43 GMT; two retrievals (18:12:06 and 18:13:04 UTC) returned byte-identical content. A WhoGetsMyData scan dated October 29 independently records Polymarket loading the URL and allowing the host in its CSP.

    Remediation

    • Users: reject unexpected signing/approval prompts; close exposed tabs; review recent orders, positions and on-chain transactions from a clean session; retain timestamps and transaction hashes; review sessions, API credentials and on-chain approvals (disconnecting a wallet does not revoke approvals or reverse transfers); never share a seed phrase and avoid unsolicited "recovery" links.
    • Defenders: preserve exact response bytes, hashes, HTTP metadata and loader references before CDN content changes; remove unnecessary third-party integrations from authenticated trading and signing flows; pin assets with Subresource Integrity alongside a restrictive Content Security Policy; audit the signer boundary so untrusted page code cannot reach the signing interface without fresh user confirmation.