Passados sete dias desde que o projeto PHP divulgou correções emergenciais para duas vulnerabilidades críticas batizadas de PHP2Shell (CVE-2026-109618 e CVE-2026-109619), o cenário de ameaça segue sendo monitorado de perto. Até 28 de outubro de 2026, não há registro de nenhum site WordPress efetivamente comprometido por meio do PHP2Shell, segundo dados analisados a partir de mais de 5 milhões de sites protegidos pela Wordfence. As equipes de limpeza de sites e resposta a incidentes da empresa não trataram, até o momento, nenhum caso de comprometimento atribuído a essas duas falhas.
Isso, no entanto, não significa que um servidor sem a devida atualização esteja seguro. A correção definitiva continua sendo atualizar o PHP para as versões 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou um pacote de fornecedor que confirme conter ambos os reparos) e reiniciar o serviço do PHP. Vale reforçar: atualizar o WordPress não atualiza o PHP.
Desde o lançamento das correções, a Wordfence vem analisando dados de segurança coletados nos sites que protege, testando as vulnerabilidades em laboratório próprio e acompanhando novos relatórios publicados por pesquisadores e fornecedores de segurança. Este texto reúne o status atual da situação e respostas diretas às perguntas mais frequentes sobre o tema.
PHP2Shell: status atual e ausência de comprometimentos confirmados no WordPress
Como mencionado, até 28 de outubro de 2026 não há casos confirmados de sites WordPress comprometidos pelo PHP2Shell. Entre os dias 23 e 27 de outubro, uma regra de monitoramento dedicada registrou aproximadamente 77.600 requisições relacionadas, originadas de mais de 2.000 endereços IP distintos. A análise desse tráfego não encontrou nenhum padrão compatível com uso rotineiro por visitantes ou funcionalidades legítimas do site — todas as ocorrências apresentavam sinais de tentativa de ataque, identificação como ferramentas de varredura ou outros indícios de testes automatizados.
Relatórios recentes ajudam a explicar por que é importante separar tentativas de exploração de comprometimentos efetivamente confirmados. No dia 26 de outubro, a empresa Dream informou que um invasor usou um exploit do PHP2Shell adaptado a uma plataforma de firewall não identificada, combinado a uma vulnerabilidade de escalonamento de privilégios no kernel Linux, para assumir controle total de 24 firewalls expostos à internet e de um servidor interno de gerenciamento de firewalls. Segundo a Dream, o atacante extraiu uma senha de conta de serviço LDAP e enumerou usuários e grupos em um ambiente descrito como vinculado ao governo dos Estados Unidos. O relatório público não identifica o fornecedor afetado nem publica os artefatos recuperados, e a Wordfence não verificou o incidente de forma independente. Além disso, o caso não envolve o WordPress.
Em paralelo, a Palo Alto Networks afirma ter observado exploração ativa voltada a interfaces de gerenciamento do PAN-OS expostas à internet, sem que seu alerta estabeleça relação com o relatório divulgado pela Dream.
No dia 27 de outubro, a Wiz relatou que nenhuma das tentativas observadas por sua equipe havia sido concluída com sucesso. Já no dia 28, a Morphisec reportou execução de código em um servidor Windows de um cliente, rodando IIS e PHP-CGI. O comunicado da Morphisec não relaciona o incidente ao WordPress e não traz detalhes técnicos suficientes para uma verificação independente de que o PHP2Shell tenha sido, de fato, a causa.
Testes de laboratório indicam que um exploit funcional, em geral, precisa ser ajustado conforme as características do servidor-alvo. Um mesmo teste executou código em uma configuração, mas apenas travou o PHP em outra. A Wiz relatou diferenças semelhantes entre configurações distintas de servidor, enquanto a Hacktron constatou que, mesmo um exploit já funcional, exigiu adaptações para atingir um novo alvo. Ainda assim, os atacantes continuam ajustando suas ferramentas, e um ataque bem-sucedido pode dar acesso a arquivos, banco de dados e senhas do site — por isso a atualização do PHP permanece essencial.
Linha do tempo: como evoluiu o caso PHP2Shell
- 20 de outubro: o projeto PHP anunciou um lançamento de segurança crítico, e a Wordfence publicou um alerta preventivo para proprietários de sites.
- 21 de outubro: o PHP lançou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 com as correções, seguido de um comunicado da Wordfence reforçando a urgência da atualização.
- 21 de outubro: a Wordfence publicou análise destacando que, em testes de laboratório, um exploit executou código em uma compilação especialmente configurada do PHP, mas apenas travou uma compilação padrão.
- 22 de outubro: novo levantamento identificou mais de 74.000 requisições relacionadas ao PHP2Shell, sem nenhum comprometimento confirmado em sites WordPress.
- 23 de outubro: o projeto PHP divulgou uma vulnerabilidade adicional e ainda sem correção, a CVE-2026-115560, junto com uma solução de contorno via configuração.
- 26 de outubro: a Dream relatou que um invasor usou o PHP2Shell combinado a uma falha do kernel Linux para controlar 24 firewalls expostos à internet e um servidor interno de gerenciamento, sem identificar o fornecedor e sem relação com o WordPress.
- 27 de outubro: a Wiz informou que as tentativas observadas fracassaram, destacando que a evidência pública mais forte revisada envolvia exploração bem-sucedida apenas de honeypots.
- 28 de outubro: a Morphisec relatou um incidente em cliente com ambiente Windows/IIS atribuído ao PHP2Shell, sem relação com o WordPress e sem detalhamento técnico suficiente para verificação independente.
- 28 de outubro: a Palo Alto Networks atualizou seu alerta informando exploração ativa contra interfaces de gerenciamento do PAN-OS expostas à internet, sem vínculo estabelecido com o caso da Dream.
O que a Wordfence está observando nos servidores monitorados
A equipe de resposta a ameaças da Wordfence tem analisado a atividade relacionada ao PHP2Shell nos registros de segurança de mais de 5 milhões de sites protegidos, comparando esses dados com relatórios públicos e sinais conhecidos de ataque para entender o que os agentes maliciosos estão tentando fazer, como suas ferramentas estão mudando e se algum comprometimento já pode ser confirmado.
Entre as tentativas identificadas nas requisições estão:
- Execução de comandos para verificar se um ataque funcionou
- Roubo de senhas de banco de dados e outros segredos presentes em arquivos wp-config.php e .env
- Instalação de arquivos de backdoor em pastas de upload, plugins ou temas, garantindo acesso contínuo ao invasor
- Download e execução de código malicioso adicional, modalidade observada com menor frequência que as demais
Essas requisições mostram apenas a intenção dos atacantes, não comprovam se o ataque teve sucesso. A partir de 23 de outubro, uma regra de monitoramento específica passou a acompanhar essa atividade e, até 27 de outubro, havia registrado cerca de 77.600 requisições relacionadas, vindas de mais de 2.000 endereços IP.
A revisão completa das correspondências não encontrou tráfego compatível com uso legítimo — todas traziam sinais de ataque, identificação como ferramentas de varredura ou outros indícios de automação. Chama atenção, ainda, um grupo coordenado de 27 endereços IP observado em 22 de outubro: 26 deles começaram a enviar requisições relacionadas dentro de uma janela de apenas 13 minutos, padrão que ajuda a diferenciar atividade automatizada coordenada do tráfego comum de visitantes.
Recomendações para proprietários de sites WordPress
Diante do cenário atual, a orientação permanece a mesma desde o início do alerta: a prioridade é atualizar o PHP do servidor para uma das versões corrigidas — 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — e reiniciar o serviço, já que a simples atualização do WordPress não resolve o problema. Mesmo sem comprometimentos confirmados até agora, a persistência das tentativas de exploração e a rápida adaptação das ferramentas usadas pelos atacantes mostram que o risco segue real. Dessa forma, Plustag IA recomenda que administradores de sites tratem a atualização do PHP como prioridade imediata, independentemente de o servidor já ter sido alvo de tentativas registradas ou não, já que o monitoramento contínuo indica que a varredura automatizada permanece ativa em escala global.
Com informações de wordfence.com.
