Ataques ao WordPress e a falha PHP2Shell: o que o HiveProtect bloqueou em nossos sites

Em 21 de outubro de 2026, duas falhas críticas do PHP foram divulgadas sob o nome de PHP2Shell. Em um servidor vulnerável, elas podem permitir a tomada de controle do motor que executa o WordPress. Os robôs não esperaram o anúncio oficial: desde 18 de outubro, nossos próprios sites recebiam ataques ao WordPress calcados no modelo dessa combinação. O HiveProtect interrompeu todos eles.

Protegemos nossos próprios sites WordPress com o HiveProtect. Por isso, abrimos nossos registros e fizemos a contagem: aqui está a tipologia dos ataques ao WordPress que recebemos, o que o HiveProtect bloqueou e como. Para que nossas regras continuem eficazes, não publicamos seus limites nem suas assinaturas.

Ataques ao WordPress: mais de 448.000 requisições bloqueadas em 3 dias

De 20 a 23 de outubro, em meio às notícias sobre o PHP2Shell, nossos sites protegidos pelo HiveProtect bloquearam mais de 448.000 requisições. Mais de 425.000 foram barradas antes mesmo de chegar aos nossos servidores, por regras de filtragem colocadas à frente deles para aliviá-los. O restante chegou até os nossos servidores, onde o HiveProtect entrou em ação.

Em uma semana completa, de 16 a 23 de outubro, o HiveProtect interrompeu em nossos servidores 46.325 requisições, ou seja, mais de 6.600 por dia. Não se trata de visitantes perdidos: 36.293 vinham de atacantes já banidos pelo HiveProtect, quase todas recusadas pelo próprio servidor web, antes mesmo de o PHP iniciar; 8.928 vinham de endereços sinalizados pela lista compartilhada HiveShield; e 1.104 eram ataques detectados na própria requisição pelo firewall.

Isso é apenas a parte visível. Em um mês, nossos sites também responderam “página não encontrada” mais de 7.800 vezes a visitantes externos, vindos de mais de 3.000 endereços IP: leitores de verdade que caíram em um link desatualizado, mas também robôs que testam páginas uma a uma para identificar um site mal protegido.

As sete famílias de ataques barradas pelo HiveProtect

Em 72 horas, de 19 a 22 de outubro, o HiveProtect desmascarou e sinalizou mais de 350 endereços de atacantes em nossos sites. O diagrama abaixo classifica por tipo as 403 sinalizações desses endereços; por trás dessas sinalizações, distinguimos sete famílias de ataques.

1. Os batedores: fazer o inventário do site

A maioria dos ataques ao WordPress começa por uma sondagem, que os especialistas chamam de reconhecimento. O robô solicita dezenas de páginas que não existem, ou arquivos específicos de um ou outro plugin, para descobrir o que está instalado e em qual versão.

Como o HiveProtect barra o ataque: um visitante humano não solicita toda uma série de páginas inexistentes. Em outubro, adicionamos ao HiveProtect uma regra dedicada a essa varredura. Testada em um mês de tráfego real antes de entrar em operação, ela teria barrado 48 endereços IP, 29 dos quais nenhuma outra regra havia detectado até então, sem atingir nem um visitante, nem um cliente, nem um robô de mecanismo de busca.

2. A caça aos arquivos secretos

É a família que mais gerou alertas: backups esquecidos, arquivos de configuração, pastas de ferramentas de desenvolvimento, acessos administrativos. Um único arquivo desse tipo deixado no lugar errado pode entregar as chaves do banco de dados.

Como o HiveProtect barra o ataque: nenhum visitante legítimo tem motivo para solicitar esses arquivos em um site WordPress. No período, nenhum foi entregue, e os endereços que os solicitavam foram banidos assim que sua intenção ficou comprovada.

3. O levantamento das contas de usuários

Antes de tentar adivinhar uma senha, é preciso conhecer um nome de usuário. Em 72 horas, registramos 777 requisições destinadas a listar as contas de nossos sites. Uma das campanhas era particularmente organizada: dezesseis ondas sucessivas, de dois a quatro endereços IP por vez, situados em países diferentes e disfarçados de navegadores recentes.

Como o HiveProtect barra o ataque: nessa campanha, cada endereço foi recusado e banido já na primeira requisição voltada às contas; as requisições seguintes esbarraram no próprio servidor web. Resultado: nenhum nome de usuário obtido, e os cinquenta endereços da campanha foram compartilhados com nossos outros sites.

4. A busca por backdoors

Alguns robôs procuram o vestígio de uma invasão anterior, por exemplo um arquivo malicioso deixado por outro atacante e que permaneceu no lugar. Em um site já comprometido, esse arquivo lhes dá acesso direto aos comandos.

Como o HiveProtect barra o ataque: em um site saudável, esses arquivos não existem; solicitá-los revela a intenção, e o endereço é barrado antes que possa ir mais longe.

5. As tentativas de sair da pasta do site

É a família ligada às notícias recentes. Uma falha do WordPress permitia forçar um site a carregar um arquivo localizado em outro ponto do servidor; combinada ao PHP2Shell, podia servir para executar código. Desde meados de setembro, contabilizamos 4.220 requisições desse tipo em nossos sites, enviadas por 47 endereços. Nenhuma foi atendida.

Como o HiveProtect barra o ataque: um endereço web não tem por que sair da pasta do site para buscar outros arquivos no servidor. Em 18 de outubro, o HiveProtect barrou o ataque calcado no modelo do PHP2Shell já na primeira tentativa e depois baniu seu autor.

6. Os impostores

Muitos robôs mentem sobre a própria identidade: eles se passam por um navegador, por um grande mecanismo de busca ou por um serviço de inteligência artificial. Outros vêm de servidores alugados por hora em data centers, um perfil raro entre leitores de verdade.

Como o HiveProtect barra o ataque: ele não confia no que o visitante declara. Ele verifica os robôs que afirmam pertencer a um grande mecanismo de busca e leva em conta a origem real da conexão. No período, seis desses servidores foram barrados já na primeira requisição.

7. Os ataques coordenados

Algumas campanhas são orquestradas: vários endereços atacam um site ao mesmo tempo e, minutos ou horas depois, a operação passa para o site seguinte, para não ser notada.

Como o HiveProtect barra o ataque: esse é o papel do HiveShield, a lista compartilhada do HiveProtect. Um endereço pego em flagrante em um site é sinalizado e depois recusado nos demais sites protegidos: em 7 dias, essa lista bloqueou sozinha 8.928 requisições em nossos servidores.

E as tentativas de senha?

Uma família ficou discreta: as tentativas de senha. As duas rajadas identificadas anteriormente neste mês, em 17 de outubro, foram recusadas sem que nenhum login fosse bem-sucedido.

PHP2Shell: como o HiveProtect interrompeu o ataque

Isoladamente, a falha PHP2Shell é difícil de explorar. O método mais simples consiste em combiná-la com uma falha de inclusão de arquivos, como a do WordPress mencionada acima. Foi um ataque desse tipo que nossos sites receberam, e o HiveProtect o interrompeu em três níveis:

• Já na primeira tentativa: a requisição de inclusão é recusada pelo firewall do HiveProtect, antes que o WordPress a processe.
• O mais perto possível do servidor: o atacante é banido na hora. As requisições seguintes dele são recusadas pelo próprio servidor web e nem chegam mais ao PHP: o ataque não pode mais ter êxito.
• Em todos os sites: o endereço dele é sinalizado ao HiveShield, que o compartilha com os outros sites protegidos.

Resultado: nenhuma dessas tentativas teve êxito em nossos sites. É toda a força de uma defesa em profundidade: várias barreiras, cada uma capaz de deter o atacante.

Não é a primeira vez que o PHP é alvo: já tínhamos contado como o HiveProtect bloqueou o ataque CVE-2024-4577.

Por que esses ataques falharam: o que o HiveProtect faz

• Ele recusa cedo: quanto mais cedo uma requisição hostil é interrompida, menores as chances de ela atingir uma falha, seja ela conhecida ou ainda desconhecida.
• Ele bane de forma duradoura: um endereço que revelou sua intenção não tem direito a uma segunda chance, e o banimento é aplicado o mais perto possível do servidor.
• Ele compartilha a informação: graças ao HiveShield, o que um site aprende beneficia rapidamente todos os outros.
• Ele desmascara os impostores: robôs falsos e conexões suspeitas são reconhecidos, não importa o que declarem.

Todas essas proteções estão detalhadas nas funcionalidades do HiveProtect, e nosso artigo “Ataques do WordPress Nunca Dormem” mostra como essas campanhas se encadeiam no dia a dia.

O que você pode fazer hoje mesmo

• Instale um firewall para WordPress capaz de banir os atacantes em vez de apenas retardá-los, e de compartilhar o que aprende.
• Mantenha o PHP, o WordPress, o seu tema e os seus plugins atualizados, e remova os plugins que você não usa mais.
• Não deixe nenhum backup nem nenhum arquivo de configuração em uma pasta acessível pela web.
• Use um endereço de login personalizado e senhas únicas.

Para instalar e configurar o HiveProtect, a documentação e a central de ajuda detalham cada etapa.

Em resumo

Em meio às notícias sobre o PHP2Shell, nossos sites protegidos pelo HiveProtect bloquearam mais de 448.000 requisições em 3 dias, e o HiveProtect interrompeu mais de 46.000 requisições em nossos servidores em uma semana, distribuídas em sete famílias de ataques. Diante do PHP2Shell como de tudo o mais, a lógica dele não muda: recusar cedo, banir de vez e compartilhar a informação.

O seu site recebe os mesmos ataques ao WordPress, quer você os veja ou não. Conheça os planos do HiveProtect e proteja-o hoje mesmo.