Polymarket: script de monitoramento de terceiros adulterado esvaziou carteiras, US$ 3,9 milhões reembolsados

Em 29 de outubro de 2026, um script de medição de desempenho fornecido por um prestador de serviços e carregado em polymarket.com foi substituído por código malicioso. Ele usou as sessões abertas dos usuários para vender suas posições e retirar os fundos. A Polymarket vai devolver US$ 3,9 milhões no total e reforçou o controle de seus scripts de terceiros.

O que aconteceu

Em um relatório do incidente publicado em 30 de outubro de 2026, o mercado de previsões Polymarket explica que detectou atividade não autorizada em carteiras de usuários em 29 de outubro, às 17h38 UTC. A causa não estava no próprio código da empresa: um prestador cujo script de medição de desempenho era carregado em polymarket.com havia sido comprometido, e o atacante trocou esse script por outro voltado aos usuários da Polymarket. Para parte das pessoas que estavam com o site aberto durante uma janela curta naquela tarde, o script usou a sessão ativa para vender posições e transferir fundos para fora de suas carteiras.

A Polymarket vai devolver US$ 3,9 milhões no total: US$ 2,7 milhões pelo roubo e US$ 1,2 milhão pelas perdas causadas pela pausa nas negociações. Na publicação do relatório, 95% das carteiras afetadas já tinham sido reembolsadas integralmente. A empresa não informa quantos usuários foram atingidos e encaminhou o caso às autoridades policiais.

Como os atacantes entraram

O site confiava no domínio do prestador, então os navegadores executavam tudo o que esse domínio entregava. Segundo uma análise da Hudson Rock, a Content Security Policy do site permitia esse domínio; o script malicioso lia os dados de autenticação salvos no navegador, localizava o cliente de negociação na página e depois pedia assinaturas e enviava transferências para um endereço controlado pelo atacante. Segundo o The Record, o prestador afirma que suas primeiras conclusões apontam para um comprometimento por meio de seu registrador de domínios.

O que fazer agora

  1. Faça o inventário dos scripts externos dos seus sites, por exemplo com curl -s https://www.example.com/ | grep -oE 'src=[^ >]+', e remova os que ninguém usa, começando pelas páginas de login, pagamento e área do cliente.
  2. Fixe e verifique os que restarem: hospede você mesmo uma versão fixa ou adicione Subresource Integrity aos arquivos que não mudam (hash gerado com openssl dgst -sha384 -binary arquivo.js | openssl base64 -A), para que um arquivo modificado seja recusado.
  3. Restrinja a Content Security Policy: listas script-src e connect-src precisas, com o envio de relatórios de violação ativado. Permitir um domínio não verifica o que ele entrega.
  4. Monitore as alterações: calcule regularmente o hash dos arquivos de terceiros e dispare um alerta a cada mudança.
  5. Prepare a resposta: sua equipe deve conseguir retirar um script e encerrar todas as sessões em minutos, como fez a Polymarket.
  6. Proteja seus próprios domínios: autenticação multifator e bloqueio de registrador (registrar lock) nas contas do registrador.

Nossa opinião

Um script carregado de outro domínio roda com os mesmos direitos do seu próprio código, dentro das sessões dos seus clientes. Uma tag de análise ou de monitoramento raramente é vista como crítica, mas aqui bastou para esvaziar contas. Menos scripts de terceiros, versões fixas e verificação de integridade custam pouco perto de um reembolso milionário.

Fontes

Como escolhemos, verificamos e escrevemos nossas análises →

A porta de entrada foi um terceiro. Verifique o que seus fornecedores expõem publicamente — sem intrusão, apenas informações públicas:

Verificar um fornecedor Verificar um servidor

Preocupado com a exposição dos seus servidores? Nossa equipe audita, corrige e monitora infraestruturas Linux e cloud 24/7.

Fale com um especialista Nossos serviços de gestão de servidores →