Seu site hackeado? Fale conosco e nós cuidamos disso
Se o seu site foi hackeado, não apague nada ainda: faça uma cópia dos arquivos e do banco de dados, coloque o site em manutenção, avise a hospedagem e troque todas as senhas e chaves de API a partir de um computador limpo. Depois é preciso descobrir por onde entraram, limpar ou reconstruir, e atualizar PHP, CMS e servidor antes de reabrir.
Vale o mesmo se o seu provedor avisou sobre uma vulnerabilidade e você não sabe se ela afeta o seu site. Conte o que aconteceu, revisamos o servidor e cuidamos da limpeza, das atualizações e das chaves novas.
Como saber se o seu site foi hackeado?
Um só destes sinais já justifica revisar o servidor. Algumas invasões não aparecem de fora: o site carrega normalmente enquanto alguém usa o servidor para enviar spam ou registra o que os seus clientes digitam nos formulários.
-
O Chrome ou o Google mostram um aviso vermelho de «site perigoso» ou «site enganoso» ao entrar no seu site.
-
Quem chega pelo Google é redirecionado para cassinos, farmácias ou páginas de spam.
-
Você pesquisa site:seudominio.com e aparecem páginas que ninguém da sua equipe criou.
-
Há usuários administradores no WordPress ou no PrestaShop que você não reconhece.
-
A hospedagem suspendeu a conta ou avisou sobre malware ou envio de spam.
-
Seu provedor avisou sobre uma vulnerabilidade (php2shell, uma CVE do NGINX ou do Node.js) e você não sabe se ela afeta o seu site.
-
Os e-mails do seu domínio voltam ou caem na pasta de spam dos clientes.
-
O navegador avisa que o certificado do site não é válido.
-
Chega uma fatura de API (OpenAI, Google Cloud, AWS…) muito acima do normal: alguém está usando as suas chaves.
Site hackeado: o que fazer na primeira hora
Estes passos valem quer você fale conosco ou não. Vêm nesta ordem porque a cópia do estado atual se perde assim que alguém começa a apagar arquivos.
- Não apague nada ainda. Faça uma cópia do estado atual, arquivos e banco de dados, e guarde fora do servidor. Anote o horário e tire capturas de tela do que está vendo. Essa cópia serve para descobrir por onde entraram e, se você for registrar ocorrência, como prova.
- Proteja os visitantes. Coloque o site em modo de manutenção ou sirva uma página estática enquanto durar a limpeza. Se a hospedagem já suspendeu a conta, não peça a reativação antes de o site estar limpo.
- Avise a hospedagem. Ela tem os logs de acesso do servidor e pode ver se outros sites da mesma conta também foram afetados.
- Troque as senhas a partir de um computador limpo. Painel da hospedagem, administradores do CMS, FTP ou SFTP, SSH, banco de dados, e-mail do domínio e registrador. Ative a verificação em duas etapas onde for possível. Se o computador de onde você gerencia o site estiver infectado, as senhas novas também vazam.
- Revogue as chaves de API guardadas no site. Gateway de pagamento, e-mail transacional, mapas, serviços de IA: gere chaves novas e desative as antigas. Uma chave copiada continua funcionando mesmo depois de limpar o servidor.
- Revise os usuários administradores. Anote o nome e a data de criação dos que você não reconhece e depois exclua-os.
- Se houver dados pessoais, o prazo já começou. Se o site guarda dados de clientes (pedidos, formulários, contas), uma invasão pode ser uma violação de dados pessoais. Pelo RGPD, há 72 horas desde que você toma conhecimento para notificar a autoridade de proteção de dados quando houver risco para as pessoas.
Para pedir depois a revisão ao Google, o processo está na ajuda do relatório Problemas de segurança. Se a sua empresa está na Espanha, a linha 017 do INCIBE é gratuita e confidencial, e a AEPD explica como notificar uma violação.
# Administradores que você não reconhece? (WordPress com WP-CLI)$ wp user list --role=administrator --fields=user_login,user_registered# Arquivos PHP modificados nos últimos 7 dias$ find . -name "*.php" -mtime -7 -type f# Em uploads não deveria haver nenhum .php$ find wp-content/uploads -name "*.php"# Tarefas agendadas que você não criou$ crontab -lCom acesso SSH ao servidor. Se você não tiver, a hospedagem pode fornecer os logs de acesso e a lista de arquivos modificados.
O que fazer se o seu provedor avisar sobre uma vulnerabilidade?
Verificar a versão que você usa, atualizar para a corrigida e, se a falha permitia executar código ou ler memória, verificar se alguém entrou antes do patch. Estes são os alertas recentes que tocam mais sites e servidores.
PHP: php2shell
CVE-2026-109618 e CVE-2026-109619, CVSS 9,2, sem autenticação. Corrigidas em 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A Wiz demonstrou execução remota de código contra WordPress, Drupal e Joomla.
Node.js
Dez CVE em 21 de outubro, entre elas uma escrita fora dos limites no descompressor Brotli que permite executar código. Corrigidas em v26.12.1, v24.22.1 e v22.23.4; a 20.x e a 25.x já não recebem patch.
NGINX
O «NGINX Rift» (CVE-2026-42945) teve tentativas de exploração desde 16 de maio. O lote de outubro, com request smuggling em HTTP/3 e falsificação de sessão TLS, é corrigido na 1.31.7 e na 1.30.6 ou superiores.
Certificados: GoDaddy e eMudhra
A GoDaddy revogou 404.607 certificados TLS em 21 de outubro por um problema de conformidade; o site que não instalar o certificado de substituição pode ficar inacessível. Chrome, Apple e Microsoft deixaram de confiar em oito CA intermediárias da eMudhra com chaves fracas.
Segredos: LiteLLM e Railway
A versão 1.107.0 do LiteLLM publicada no PyPI e no Docker Hub roubava credenciais ao iniciar. A Railway detectou atividade anômala nos sistemas que guardam as variáveis de ambiente dos clientes e pede que sejam trocadas. Nos dois casos, as chaves são trocadas mesmo que o servidor pareça saudável.
As versões corrigidas, os comandos para conferir e o que trocar em cada caso, num só artigo.
O que corrigir, rodar e renovar →Como recuperar um site hackeado?
Sete passos, nesta ordem. Limpar sem saber por onde entraram deixa a mesma porta aberta.
-
Contenção
Primeiro paramos o que ainda está acontecendo: redirecionamentos, envio de spam, processos que não deveriam estar rodando. Se for preciso, o site fica em manutenção enquanto trabalhamos.
-
Cópia e análise básica
Guardamos uma cópia do estado comprometido e olhamos os logs de acesso, os arquivos modificados, os usuários e as tarefas agendadas para achar a porta de entrada. Se você precisar de um laudo pericial para um processo ou para o seguro, quem assina é um perito; a cópia fica guardada para que ele possa trabalhar com ela.
-
Limpeza ou reconstrução
Se existe um backup anterior à invasão e sabemos como entraram, ele é restaurado e limpo. Se não, o CMS é reinstalado a partir das fontes oficiais e só o conteúdo revisado é migrado.
-
Atualizar PHP, CMS e servidor
PHP para uma versão com patch, núcleo do CMS, plugins e tema, e o software do servidor (NGINX, Apache, Node.js) se for você quem o administra. O que não aceita uma versão com suporte é substituído ou removido.
-
Troca de credenciais
Senhas, chaves SSH, chaves de API e variáveis de ambiente. Tudo o que estava no servidor é tratado como comprometido.
-
Verificação e listas negras
Conferimos que o site serve o que deve, pedimos a revisão ao Google pelo Search Console e verificamos se o domínio ou o IP do servidor aparecem em listas negras de e-mail.
-
Manutenção
Backups periódicos guardados fora do servidor, atualizações e acompanhamento dos alertas de segurança do software que o seu site usa.
- Modo de manutenção se necessário
- Corte de redirecionamentos e spam
- Processos e conexões suspeitas
- Aviso à hospedagem
- Cópia do estado comprometido, fora do servidor
- Logs de acesso e de erros
- Arquivos modificados recentemente
- Usuários, tarefas cron e chaves SSH
- Porta de entrada provável
- Restaurar um backup anterior à invasão
- Ou reinstalar o CMS a partir das fontes oficiais
- Remover backdoors e arquivos injetados
- Revisar o banco de dados (usuários, opções, conteúdo)
- PHP para uma versão com patch
- Núcleo do CMS, plugins e tema
- NGINX, Apache ou Node.js
- Substituir o que não tem suporte
- Hospedagem, CMS, FTP/SFTP, SSH e banco de dados
- Chaves de API e tokens
- Variáveis de ambiente
- Verificação em duas etapas
- Revisão no Search Console
- Listas negras de e-mail e IP
- Certificado TLS válido
- Teste de que o site funciona
- Backups periódicos fora do servidor
- Atualizações de PHP, CMS e plugins
- Acompanhamento de alertas de segurança
Está vendo isso agora? Mande o endereço do site e o que você notou.
Fale conosco →Dá para limpar ou é preciso refazer o site?
Depende do que há no servidor e de existir um backup anterior à invasão.
Dá para limpar
- Sabemos por onde entraram e dá para fechar.
- Existe um backup anterior à invasão.
- O CMS, os plugins e o tema aceitam uma versão de PHP com suporte.
Melhor reconstruir
- Não há nenhum backup confiável, ou a infecção volta depois de cada limpeza.
- O site depende de plugins abandonados ou de uma versão de PHP sem suporte.
- Reinstala-se a partir das fontes oficiais e migra-se o conteúdo revisado, ou refaz-se: para um site institucional, por exemplo um site estático com Astro, que não executa PHP no servidor.
Perguntas frequentes sobre sites hackeados
O que fazer se o meu site foi hackeado?
Como saber se o meu site foi hackeado?
Basta restaurar um backup?
Como tirar o aviso de site perigoso do Google?
Tenho de notificar a autoridade de proteção de dados?
O meu site em PHP é afetado pelo php2shell?
Vocês garantem que não vai acontecer de novo?
Do que vocês precisam para começar?
Conte o que aconteceu e nós cuidamos disso
Com o endereço do site, o que você viu e os acessos que ainda tem, revisamos o servidor e dizemos se dá para limpar, se é preciso reconstruir e o que tem de ser atualizado.
Conte-nos seu desafio. Propomos uma solução.
Sem compromisso. Em menos de 24 horas, você recebe uma proposta com escopo, cronograma e orçamento. Sem letras miúdas.