Em resumo: Quando o site reencaminha para páginas alheias, a causa está numa de seis camadas: DNS, CDN ou proxy, configuração do servidor web, código PHP, base de dados ou scripts incluídos. Como muitos redirecionamentos só atuam sob condições, teste de forma dirigida com várias identificações e páginas de origem. Proteja primeiro os visitantes, preserve os vestígios e, depois de remover, feche a porta de entrada.
Quando os clientes vão parar a páginas de concursos
O aviso vem quase sempre de fora. Um cliente escreve que, ao abrir a sua página, foi parar a um concurso ou a uma loja duvidosa. Verifica no seu computador e tudo parece normal. Isto não é uma contradição, é intencional: os redirecionamentos posteriores a um ataque são construídos para que os operadores os notem o mais tarde possível.
Para a sua empresa, isto é delicado. Os visitantes perdem confiança, os motores de busca e os navegadores podem apresentar avisos e, nas páginas de destino, esperam por vezes burlas ou software malicioso. Além disso, um redirecionamento quase nunca é a única coisa que um atacante deixa.
Depois do PHP2Shell, as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 com execução de código sem autenticação, os redirecionamentos contam-se entre as consequências visíveis que os operadores devem levar a sério. Não são uma indicação específica do PHP2Shell, pois não existem indicadores de comprometimento confirmados. Mas mostram que alguém conseguiu alterar conteúdos do seu site.
Com frequência, os redirecionamentos não vêm sozinhos. Quem reencaminha visitantes cria muitas vezes também páginas de spam para os motores de busca, para captar ainda mais tráfego. Se o Google já apresentar um aviso de site comprometido, o guia Remover o aviso do Google descreve o caminho para a revisão. As páginas alheias no índice de pesquisa são tratadas no artigo Spam de SEO e páginas alheias no índice do Google.
Porque é que o site só reencaminha às vezes
Os redirecionamentos condicionais avaliam características do pedido. As mais frequentes são estas:
- Origem: só quem chega através de um resultado de pesquisa é reencaminhado. Os acessos diretos mostram a página normal.
- Dispositivo: só são afetados os dispositivos móveis ou determinados navegadores.
- Repetição: o redirecionamento atua uma vez por visitante e, depois, define um cookie e deixa de atuar.
- Sessão iniciada: quem tem sessão iniciada no CMS nunca vê nada.
- Tempo ou acaso: o redirecionamento só atua numa parte dos acessos.
Por isso, não teste apenas no seu posto de trabalho. Com uma consulta apenas de leitura, vê como o servidor responde a diferentes acessos:
# Acesso normal: código de estado e destino de um possível redirecionamento
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Acesso como se fosse de um dispositivo móvel que chega através de uma pesquisa
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Se só na segunda consulta aparecer um destino estranho, o redirecionamento está no servidor. Se ambas passarem sem problemas, pode ocorrer no navegador, por JavaScript. Nesse caso, ajuda olhar para o código-fonte da página entregue ou para a vista de rede das ferramentas de programador do navegador, de preferência numa janela privada.
O site reencaminha: verificar as seis camadas
Proceda de fora para dentro. Assim evita passar horas a procurar no código quando a causa está numa entrada DNS:
| Camada | Causa típica | Verificação |
|---|---|---|
| Domínio e DNS | entrada A ou servidor de nomes alterado | comparar as entradas DNS com o estado esperado conhecido, verificar o acesso ao registador |
| CDN ou proxy | regra alheia de reencaminhamento ou de página | rever as regras na área de cliente do fornecedor |
| Servidor web | regras no .htaccess ou na configuração do servidor |
procurar regras Rewrite e Redirect com condições |
| Código PHP | código adicional em ficheiros de entrada, modelos ou extensões | comparar os ficheiros principais com o original |
| Base de dados | definições de endereço alteradas, scripts em conteúdos ou opções | procurar de forma dirigida endereços e scripts alheios |
| Scripts externos | inclusão comprometida de terceiros | listar e avaliar as origens dos scripts incluídos |
As camadas exteriores costumam ser ignoradas, porque não estão no próprio servidor. É precisamente por isso que são perigosas: quem assumiu o controlo da conta no registador ou no fornecedor de CDN não precisa de acesso ao servidor. Verifique aí, além das regras, quem tem acesso e se a autenticação de dois fatores está ativa.
Para a camada do servidor web, servem pesquisas apenas de leitura por regras que reagem à origem ou ao dispositivo:
# Regras de reencaminhamento com condições em todos os ficheiros .htaccess
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Reencaminhamentos na configuração do servidor (Apache e Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Para a camada PHP, o procedimento está descrito em Comparar os ficheiros principais do CMS com o original. Para a base de dados, vale a pena consultar o artigo Verificar na base de dados a presença de código introduzido.
Quando a causa está fora do servidor
Nem todo o redirecionamento significa um servidor comprometido. Os scripts de terceiros incluídos, por exemplo para chats, estatísticas ou publicidade, são executados diretamente no navegador dos visitantes. Se um desses fornecedores for comprometido, ou se expirar um domínio de onde a sua página ainda carrega um script, pode surgir daí um redirecionamento sem que nenhum ficheiro tenha sido alterado no seu servidor.
Uma Content Security Policy limita as origens de onde o navegador pode carregar scripts e torna estes casos visíveis. Encontra indicações em Cabeçalhos de segurança para sites. Muito raramente, a causa está no próprio visitante: software publicitário ou malicioso no seu computador reencaminha então também noutros sites.
A ordem certa depois da descoberta
- Proteger os visitantes: colocar o site em modo de manutenção ou bloquear as áreas afetadas.
- Preservar vestígios: copiar regras, ficheiros e conteúdos da base de dados suspeitos, com data e hora, antes de os remover.
- Remover: eliminar o redirecionamento e substituir os ficheiros principais por uma origem limpa.
- Fechar a porta de entrada: levar o PHP para uma versão corrigida, atualizar o CMS e as extensões, reiniciar todos os workers, renovar os acessos.
- Voltar a testar: verificar de novo com todas as variantes da segunda secção e acompanhar a Search Console.
Uma regra de reencaminhamento removida não é prova de que o site está limpo. Se a regra regressar passados alguns dias, há ainda uma porta dos fundos que a volta a escrever.
Como ajuda concretamente a PHP SOS?
- Reproduzimos o redirecionamento com várias identificações e páginas de origem e delimitamos a camada.
- Preservamos vestígios e removemos redirecionamentos, código malicioso e portas dos fundos em ficheiros, configuração e base de dados.
- Em caso de infeção aguda, a nossa ajuda de emergência para sites comprometidos assume a contenção até o incidente estar concluído e documentado.
- Verificamos os scripts de terceiros incluídos e recomendamos uma Content Security Policy adequada.
Perguntas frequentes
Porque não vejo eu próprio o redirecionamento?
Muitos redirecionamentos só atuam sob certas condições: para visitantes vindos da pesquisa do Google, apenas em dispositivos móveis, só na primeira visita ou não para administradores com sessão iniciada. Por isso, teste com vários dispositivos, sem sessão iniciada e através de uma ligação de resultado de pesquisa.
Pode um redirecionamento surgir também sem ataque?
Sim. Um plugin expirado, um script externo comprometido, entradas DNS incorretas ou software malicioso no computador do visitante podem ter efeitos semelhantes. Se a causa estiver no próprio computador, o redirecionamento costuma ocorrer também noutros sites.
Onde escondem os atacantes mais frequentemente os redirecionamentos?
São típicas as regras no .htaccess ou na configuração do servidor, código adicional em ficheiros de entrada da aplicação, definições de endereço alteradas na base de dados e excertos de JavaScript introduzidos em conteúdos ou modelos.
O que devo fazer de imediato se o meu site redireciona?
Proteger os visitantes, por exemplo com um modo de manutenção, e preservar vestígios antes de eliminar o que quer que seja. Depois, procurar a causa camada a camada e fechar a porta de entrada. Uma regra removida sem fechar a vulnerabilidade costuma regressar.