Script sequestrado do DebugBear no site da Polymarket leva a roubo de cerca de US$ 2,7 milhões de traders

O ataque de 29 de outubro não envolveu invasão direta à Polymarket. O código malicioso entrou no lugar de um script de monitoramento de desempenho (RUM) do DebugBear, carregado pelo site. Segundo a empresa, os registros DNS foram comprometidos via registrador de domínio, e ela diz não ter visto sinal de invasão aos próprios sistemas, embora siga investigando. Pesquisadores da Ohey viram um servidor diferente respondendo pelos endereços do DebugBear às 18:13 UTC, quando o arquivo malicioso ainda estava no ar. Cada cliente carrega sua própria cópia do script, e o arquivo trocado foi o da Polymarket.

A análise da Hudson Rock, feita sem executar o arquivo, mostra que o código aproveita a sessão de quem já estava logado. Ele lê dados da conta no navegador, incluindo chaves de API de trading, mas essas chaves sozinhas não criam ordens, que exigem assinatura da carteira. A Hudson Rock não achou envio de chaves, senha, seed phrase ou chave privada ao servidor do atacante. O código localiza o trecho do site que envia ordens e o signer da conta. Quem entra com carteira própria teve posições movidas direto para a carteira dos atacantes. Quem entra por e-mail teve posições vendidas a preços cada vez piores e o dinheiro retirado. A Hudson Rock ressalva que o pedido de assinatura não prova que o trader assinou sem ver um aviso, pois o provedor da carteira pode perguntar, recusar ou aplicar regras próprias.

Pela rastreabilidade da Ohey, a carteira recebeu fundos entre 17:10 e 18:02 UTC: 28,6 milhões de POL (cerca de US$ 2,64 milhões) e posições de 33 carteiras. Entre 18:28 e 18:38 UTC, tudo foi enviado a outros três endereços. A Polymarket reembolsa US$ 3,9 milhões no total: cerca de US$ 2,7 milhões a 726 carteiras afetadas e US$ 1,19 milhão a cerca de 5.500 carteiras que perderam dinheiro na pausa ou tiveram posições tomadas. Em 30 de outubro, 689 das 726 já tinham sido pagas. O caso foi levado às autoridades.

Como mitigação, o DebugBear pediu que clientes do RUM removam o código de embed. A Polymarket recoloca scripts de terceiros com CSP mais forte, versões fixadas e sandboxing. A Hudson Rock recomenda tirar código de terceiros de páginas de trade ou assinatura, usar Subresource Integrity (SRI) quando possível e revisar o que o código numa página logada pode pedir ao signer. Uma política que apenas libera um CDN confiável não verifica o conteúdo servido por ele.

Em 30 de outubro de 2026, o CEVIU noticiou "Polymarket retoma negociações após exploit de US$ 2,65 milhões e atribui incidente a provedor terceirizado comprometido". Naquele momento, o ponto central era a perda, o modo cancel-only e o compromisso de reembolso. Agora há o vetor detalhado: script do DebugBear trocado após comprometimento do registrador de domínio, o mecanismo do código e o total de US$ 3,9 milhões em reembolsos.

Em 26 de junho de 2026, o CEVIU já havia publicado "Polymarket sofre ataque em seu frontend e usuários perdem 3 milhões de dólares", com um fornecedor terceirizado comprometido e script malicioso no frontend. A cobertura não permite afirmar que seja o mesmo incidente nem o mesmo fornecedor, mas mostra que a plataforma já tinha sido alvo de ataque pela via do frontend.

Para quem opera aplicações em que o usuário assina transações, o caso indica que um script de monitoramento é código com acesso à sessão e pode virar vetor de roubo. Na leitura editorial, o risco também passa pelo DNS e pelo registrador do fornecedor, e não só pelo código dele. Controles como SRI e CSP restritiva, citados pela Hudson Rock, entram na revisão de qualquer página logada com terceiros.