O DebugBear, ferramenta de monitoramento de velocidade de sites usada por profissionais de SEO, confirmou que teve os registros de DNS comprometidos por meio do seu registrador de domínio e que o ataque parece ter mirado o site de um cliente. Segundo a Search Engine Journal, o código malicioso foi identificado em 29 de outubro de 2026 no script de Real User Monitoring (RUM) da empresa, que orientou os clientes a remover o script no mesmo dia. Segundo a SEJ, remover a tag impede novos carregamentos, mas não desfaz ações não autorizadas nem remove o que o invasor já tenha plantado; por isso há sessões, contas e alterações a conferir.
Resumo: Prazo: imediato (orientação de remoção de 29/10). Quem: sites com o script de RUM do DebugBear (cdn.debugbear.com). O quê: remover o script, encerrar sessões, trocar senhas, procurar alterações e, com invasão confirmada, tirar o site do ar para limpeza. Onde: templates, plugins, gerenciador de tags, painel de usuários e logs.
Neste artigo
O que aconteceu
Em post no LinkedIn, sem data e sem orientação a clientes, o DebugBear afirma que continua investigando o incidente, que os registros do seu servidor de DNS foram comprometidos por meio do registrador de domínio e que, por isso, não consegue receber e-mails enviados ao seu domínio. Pela investigação inicial, o ataque parece ter visado o site de um cliente específico. A empresa diz não ter visto indício de comprometimento dos seus sistemas internos. Em 1º de novembro, às 08:14, o site debugbear.com devolveu erro HTTP 530 à redação.
Segundo a Search Engine Journal, a empresa de segurança Hudson Rock identificou em 29 de outubro código malicioso em uma URL de script do DebugBear usada pela Polymarket. O código aproveitava o cliente de negociação já carregado no navegador de quem estava logado, e um relatório da Polymarket de 30 de outubro, não aberto pela redação, confirma a venda de posições e a movimentação de fundos de alguns usuários. Nenhuma fonte informa valor perdido.
Quem é afetado
O alerta da SEJ é dirigido a donos de sites que usam o script de RUM do DebugBear, que mede os Core Web Vitals de visitantes reais e é instalado como uma tag <script async> apontando para cdn.debugbear.com, com um identificador por site. Segundo a publicação, outros sites de alto valor podem ter sido alvo, mas não está claro se outros clientes receberam o código malicioso. A SEJ recomenda começar a resposta por administradores e usuários com privilégio que carregaram páginas com o script; no caso relatado, o código usou a sessão de quem já estava autenticado.
Outros incidentes que atingem quem mantém sites e ferramentas de desenvolvimento foram cobertos pelo Cientistas Digitais, como a extensão falsa do Claude Code no Cursor e as invasões confirmadas do PHP2Shell.
O que fazer
Os passos abaixo são os da Search Engine Journal para quem usa o script; o post do DebugBear não traz orientação. São verificações, não achados confirmados em outros clientes.
- Remover o script. Procurar a tag nos templates, nos plugins e no gerenciador de tags, limpar o cache e confirmar que o script não carrega mais.
- Encerrar sessões e trocar senhas. Começar por administradores e usuários com privilégio, revogar credenciais de API que possam ter sido expostas e ampliar a troca se não der para saber quem foi exposto. Confirmar que as sessões antigas são rejeitadas.
- Procurar alterações e acesso persistente. Comparar com uma versão limpa contas criadas, permissões, histórico do gerenciador de tags, templates, plugins e scripts injetados, e investigar se ficou uma porta dos fundos (backdoor).
- Achar contas afetadas e desfazer mudanças. Revisar nos logs do período logins incomuns, contas novas, arquivos alterados e transações inesperadas, com os indicadores publicados pela The Layman Security, e reverter o que for confirmado.
- Tirar do ar o site invadido. Com invasão confirmada, servir uma página estática de manutenção com HTTP 503, limpar ou restaurar um backup limpo e só reativar depois de confirmar que o código malicioso saiu.
| Prazo | O que fazer | Onde |
|---|---|---|
| Imediato | Remover o script do DebugBear e limpar o cache | Templates, plugins, gerenciador de tags |
| Logo depois | Encerrar sessões, trocar senhas, revogar chaves de API | Painel de usuários, contas de API |
| Em seguida | Comparar contas, permissões, tags e scripts com versão limpa; revisar logs e reverter o confirmado | Histórico do gerenciador de tags, logs de acesso |
| Se houver invasão | Página de manutenção com HTTP 503 e restauração de backup limpo | Servidor ou hospedagem |
O que ainda não se sabe
- Quantos sites receberam o código. Nenhuma fonte informa.
- Desde quando o script estava adulterado. As fontes dão a descoberta, 29 de outubro, não o início.
- Quando o script pode voltar. O DebugBear não diz.
- O vínculo com a Polymarket. É relatado pela SEJ; o DebugBear não nomeia o cliente.
Perguntas frequentes
Como garantir que as sessões antigas foram encerradas?
A SEJ avisa que trocar a senha pode não encerrar sessões já abertas e recomenda confirmar que as sessões antigas são rejeitadas, começando por administradores e usuários com privilégio.
Até quando o script deve ficar fora do site?
As fontes não dão data. Segundo a SEJ, o DebugBear orientou a remoção em 29 de outubro; no post do LinkedIn, a empresa diz que a investigação continua, sem indicar quando o script pode voltar.
Matéria produzida pela redação automatizada do Cientistas Digitais (CD Bot) a partir das fontes listadas abaixo e revisada antes da publicação.