Segundo golpe via fornecedor em quatro meses atinge a Polymarket

Registro corrigido. Nosso selo era 'claimed' / 'unverified', com data de 30/10 e sem ator. Não há alegação de criminoso a avaliar: quem confirma é a própria vítima. O selo correto é 'confirmed' (o comprometimento de um fornecedor, por comunicado oficial) e o veredito é 'real'. A data do incidente é 29/10/2026; 30/10 é a data da cobertura. Também não é só indisponibilidade, como o título sugere: houve saque de fundos de usuários.

O que a Polymarket admite: um fornecedor terceirizado foi comprometido, a plataforma internacional foi corrigida, o caso foi encaminhado às autoridades e todos os afetados serão ressarcidos. O que a empresa não disse: o nome do fornecedor, o valor perdido, o número de vítimas e como o reembolso funciona. A NBC News registra que a empresa não chegou a confirmar que usuários perderam dinheiro. O nome DebugBear vem de fonte anônima à CNBC e à Reuters, mas a própria DebugBear confirmou publicamente um incidente de segurança, e o Hudson Rock recuperou o script de um endereço da DebugBear usado pela Polymarket. Essa convergência sustenta a atribuição do vetor com confiança alta, embora a Polymarket nunca a tenha dito.

O mecanismo, pela análise do Hudson Rock (estática: o laboratório não conectou carteira nem executou o código): o script de 15.187 bytes procurava a sessão logada do usuário e o cliente de trading com seu signatário, e tentava vender posições e transferir ativos a um endereço fixo embutido no código. A Bitquery vê o lado on-chain: 985 saques, cada um um saque normal com aprovação válida, enviados pelo relayer da própria Polymarket, que pagava o gás. Por isso passaram nas verificações das carteiras. Houve conversão em POL e movimentação para Ethereum por bridge. Não há evidência pública de exploração dos contratos. Há divergência sobre o que o script coletava (credenciais de sessão e chaves de API do navegador): uma análise diz que o código lia entradas do armazenamento do navegador, outra diz que o Hudson Rock não achou rotina que enviasse senha, seed ou chave privada ao endpoint. Por isso deixei data_types vazio.

Os números divergem e cada um mede coisa diferente. Bitquery: US$ 2,73 mi, 737 contas, 985 saques, perda mediana de US$

171. Arkham: ~US$ 2,65 mi na carteira do atacante. GoPlus: ~US$ 2,71 mi. Hudson Rock: 710 carteiras de depósito e 731 endereços (diz que isso não equivale ao número de vítimas) e ~US$ 2,19 mi em captura de tela, que o laboratório não considera tally verificado. Uma circulação inicial falava em 995 contas e US$ 2,65 mi; 995 parece contagem de operações, não de contas, mas não consegui confirmar a origem. Um agregador cita US$ 3,46 mi 'em ativos comprometidos', dos quais US$ 2,7 mi sacados; não rastreei a origem e não uso esse número. A mediana de US$ 171 mostra pulverização: a maioria perdeu pouco. A perda de um trader (~US$ 800 mil, alegação própria no X) pode concentrar parte relevante do total, mas isso não está verificado.

A cronologia é o detalhe mais útil. Pelo metadado de build, a Polymarket removeu o script às 17:59 UTC, 49 minutos depois do primeiro POL chegar ao endereço do atacante. A DebugBear alertou clientes ~98 segundos depois do build e o status público de outage e a pausa do relayer vieram às 18:05. Houve saques depois disso (até ~18:10 pelo relato de um trader, e uma retirada de US$ 10,99 ~38 min após a correção). A janela entre o início da drenagem e a detecção foi bem maior que a janela entre detecção e contenção, e a detecção veio de relatos de usuários nas redes, segundo a própria cobertura. Isso é gap de controle: não havia, ao que se vê, alerta de velocidade ou destino novo sobre o relayer.

O ponto estrutural é que a Polymarket sofreu em junho outro comprometimento de fornecedor no frontend (~US$ 3,1 mi, 11 carteiras), com fornecedor também não nomeado. Nos dois casos, código de terceiro rodou em contexto autenticado com capacidade de induzir ou submeter assinaturas. Não há prova de que seja o mesmo ator. A Source Defense afirma que o script envenenado de junho apareceu em outros sites, e que CSP e SRI têm limites contra esse tipo de ataque; nessa análise, não houve identificação do fornecedor. A hipótese de ataque dirigido em outubro (payload específico da Polymarket) é inferência minha, de confiança baixa: o Hudson Rock não vê outros clientes da DebugBear atingidos, mas isso não prova que não houve. O vetor inicial na DebugBear, o tempo de exposição e o ator seguem desconhecidos. Ninguém reivindicou.

Sobre o reembolso: fontes secundárias, citando a CNBC e mensagens no Discord, relatam que perdas acima de US$ 10 mil exigem acordo de quitação e, para alguns, KYC. Usuários grandes reclamaram do acordo em redes sociais. Não abri o documento primário e trato isso como informação 'possivelmente verdadeira'. Se for exato, 'made whole' vem com renúncia a ação judicial para as maiores vítimas, o que importa para quem avalia a transparência da resposta.

Usuários da plataforma internacional (Polymarket.com) com sessão ativa durante a janela do ataque. Estimativas independentes indicam ~710–737 contas e US$ 2,2–2,7 mi em posições vendidas e fundos transferidos, com perda mediana de US$ 171 por conta. A Polymarket promete ressarcir todos; o prazo e os termos para perdas maiores não foram confirmados por fonte primária. A plataforma regulada nos EUA (Polymarket US) não foi, segundo a cobertura (CNBC, NBC), afetada. Ficou em aberto o risco para outros sites que carregaram o script de RUM da DebugBear, pois a DebugBear mandou todos os clientes de RUM removerem o código.