Resumo
A DebugBear mandou clientes removerem o script de monitoramento depois que atacantes comprometeram seus registros DNS pelo registrador, fato descoberto em 29 de outubro de 2026. O endereço do script serviu JavaScript malicioso contra usuários de um cliente, a Polymarket, que confirmou retirada de fundos de carteiras. A investigação segue aberta e ainda não se sabe se outros sites receberam o código.
DebugBear manda clientes removerem o script de monitoramento depois que atacantes sequestraram os registros DNS da empresa e serviram código malicioso, caso descoberto em 29 de outubro de 2026. Para quem mede Core Web Vitals com a ferramenta, a orientação é tirar o código das páginas e investigar acessos indevidos.
Script do DebugBear carregou código que agia dentro da sessão
O código malicioso apareceu em um endereço de script da DebugBear usado pela Polymarket. A empresa disse que invasores comprometeram seus registros DNS pelo registrador de domínio e que, na investigação inicial, o ataque mirou o site de um único cliente. Segundo a DebugBear, não há sinal de invasão dos sistemas internos.
A análise da Hudson Rock, que obteve o arquivo de 15.187 bytes, descreve um código que lia dados de sessão guardados no navegador, localizava o cliente de negociação já aberto e tentava mover ativos sem pedir senha. A Polymarket confirmou que o script vendeu posições e retirou fundos de carteiras de alguns usuários que estavam com a página aberta.
“Um fornecedor terceirizado, cujo script de monitoramento de desempenho carregava em polymarket.com, foi comprometido”, disse a Polymarket em seu relatório do incidente.
Remover o script não desfaz o que já foi executado
A DebugBear também contou que ficou sem receber e-mails enviados ao próprio domínio. Segundo o Search Engine Journal, ainda não está claro se outros clientes receberam o código malicioso. A orientação é procurar o embed do Real User Monitoring em modelos, plugins e gerenciadores de tags, limpar o cache das páginas e confirmar que o arquivo deixou de carregar.
Tirar o script impede novos carregamentos, mas não revoga sessões nem apaga alterações já feitas. Administradores que abriram páginas afetadas precisam encerrar sessões e revogar chaves de API, porque trocar a senha pode não bastar. A Hudson Rock recomenda ainda Subresource Integrity e uma Content Security Policy restritiva. A Polymarket removeu o script, limpou o cache e reiniciou as sessões de login.
O que você acha? Você revisa os scripts de terceiros carregados nas suas páginas? Para acompanhar mais, acesse nossa editoria de SEO e Otimização e os vídeos do canal no YouTube.
Perguntas Frequentes
O que aconteceu com o script de monitoramento da DebugBear?
DebugBear teve os registros DNS comprometidos pelo registrador de domínio, e o endereço do script de monitoramento passou a servir JavaScript malicioso, achado em 29 de outubro de 2026. A empresa orientou os clientes a remover o embed do Real User Monitoring e a checar acessos indevidos. O alcance total segue em apuração.
Como remover o script do DebugBear de um site WordPress?
DebugBear usa um embed de Real User Monitoring que pode estar no tema, em plugin de cabeçalho ou em gerenciador de tags. O dono do site deve localizar a linha que carrega o arquivo, apagá-la, limpar os caches de página e de CDN e conferir no código-fonte que o endereço sumiu. Depois, convém revisar usuários, plugins e arquivos alterados.
Subresource Integrity protege contra script de terceiros invadido?
Subresource Integrity compara o arquivo carregado com um hash fixado no HTML e bloqueia o código se o conteúdo mudar. A Hudson Rock recomenda o recurso, junto com uma Content Security Policy restritiva, nos casos em que o arquivo possa ser fixado. O relatório também sugere remover scripts de terceiros desnecessários das páginas com área logada.