O projeto PHP publicou em 20 de outubro de 2026 um aviso antecipado de versão de segurança crítica, marcada para 21 de outubro de 2026, às 14h UTC (11h em Brasília). A atualização corrige duas falhas com nota 9,2 no CVSS 4.0, cujos detalhes vazaram antes do patch e ganharam entre pesquisadores o apelido de PHP2Shell.
Em três linhas: as falhas permitem execução remota de código em servidores com PHP. A correção sai em 21 de outubro, às 11h de Brasília, e só então serão conhecidas as versões afetadas e corrigidas. Até lá, a recomendação é mapear onde o PHP roda e proteger primeiro o que está exposto à internet.
Segundo o aviso publicado no site oficial do PHP, a equipe de segurança pode antecipar a liberação se os detalhes se tornarem públicos ou se houver exploração ativa. As identificações CVE-2026-109618 e CVE-2026-109619 circulam em análises de empresas de segurança, mas ainda não aparecem na página do projeto.
O que o aviso do PHP confirma e o que veio do vazamento
Boa parte do que se lê sobre o PHP2Shell vem de capturas de tela de um post removido do Hacker News. Separar a origem de cada informação evita decisões baseadas em boato.
| Informação | Origem | Situação |
|---|---|---|
| Duas falhas críticas, CVSS 4.0 de 9,2 | Site oficial do PHP | Confirmado |
| Correção em 21/10/2026, 14h UTC | Site oficial do PHP | Confirmado, podendo ser antecipada |
| Execução remota de código | Huntress e Sansec | Reproduzida pela watchTowr, segundo a Huntress |
| Versões afetadas (relatos citam do PHP 5 ao 8) | Pesquisadores | Sem confirmação oficial |
| Exploração ativa | Huntress | Não confirmada até a publicação do alerta |
| Causa técnica e configuração necessária | Nenhuma fonte | Não divulgada |
A análise da Huntress sobre o vazamento informa que um vídeo curto de exploração também foi publicado e apagado depois. A empresa diz não ter visto ataques em ambientes de clientes, e não se sabe se a falha é alcançável por uma requisição web comum ou depende de configuração específica.
Linha do tempo do PHP2Shell, do vazamento ao patch
- 20 de outubro: detalhes das duas falhas aparecem no Hacker News, antes da divulgação coordenada. O post é removido, mas as imagens continuam circulando.
- 20 de outubro: o PHP publica o aviso antecipado da versão de segurança. A watchTowr reproduz uma das falhas, segundo a Huntress.
- 20 de outubro, 23h41 UTC: a Sansec atualiza sua página sobre o caso, que diz afetar servidores com PHP 5.4 ou posterior.
- 21 de outubro, 14h UTC: saída prevista das versões corrigidas, com a lista oficial do que está vulnerável.
A página da Sansec sobre o PHP2Shell trata o problema como uma correção de infraestrutura: não adianta atualizar plugin ou tema, porque a falha está no próprio interpretador.
Quais servidores entram na lista de risco
Qualquer máquina que execute PHP para atender a web. Na prática, isso inclui sites em O que é WordPress e para que serve?, lojas Magento, portais em Drupal e Joomla, painéis de hospedagem como cPanel e Plesk e softwares de fornecedores que trazem o PHP embutido, muitas vezes esquecido no inventário.
As versões mais recentes listadas pelo projeto são 8.5.11, 8.4.26, 8.3.35 e 8.2.34. A expectativa dos pesquisadores ouvidos pela Huntress é que só os ramos 8.x ainda suportados recebam correção.
E quem ainda roda PHP 7 ou mais antigo?
Esse é o grupo mais exposto. Se a correção não chegar aos ramos sem suporte, o caminho é migrar de versão ou tirar o serviço da internet aberta, colocando-o atrás de VPN ou de um WAF até a migração terminar.
Medidas para as horas antes da correção
- Faça o inventário. Rode php -v em cada servidor e liste também contêineres, imagens Docker e appliances de terceiros com PHP.
- Isole o que está fora de suporte. Sem patch previsto, ele precisa sair da exposição direta.
- Vigie os processos filhos do PHP. A Huntress sugere observar php-fpm, php-cgi, httpd e apache2 abrindo shells, interpretadores ou ferramentas de download, comportamento típico de quem ganhou execução remota.
- Prepare a janela de manutenção. Deixe combinado quem atualiza, em que ordem e como reverter se algo quebrar.
- Em caso de suspeita, preserve as evidências. Isole a máquina, guarde logs do servidor web e do PHP e procure arquivos novos na pasta pública, cron jobs e contas criadas recentemente.
Depois das 14h UTC: como aplicar a versão nova sem surpresa
A ordem recomendada é começar pelos servidores expostos à internet e deixar os internos para a sequência. Quem instala o PHP pelos repositórios do sistema operacional deve esperar o pacote da própria distribuição, que costuma trazer a correção em backport, sem mudar o número da versão principal.
Em hospedagem compartilhada, a atualização depende do provedor. Vale abrir um chamado perguntando o prazo e, se o painel permitir escolher a versão do PHP, conferir se a opção selecionada é de um ramo que vai receber o patch. Ambientes em contêiner pedem a reconstrução da imagem a partir da base corrigida, não apenas o reinício.
Nas equipes que já seguem um ciclo mensal, como o do Patch Tuesday de outubro: 3 zero-days e o que atualizar primeiro, o PHP2Shell deve entrar como prioridade fora do calendário.
A próxima data no radar: 21 de outubro, 11h de Brasília
É nesse horário que o projeto promete publicar as versões corrigidas, a lista de ramos afetados e os detalhes técnicos. Nas horas seguintes, os boletins de Debian, Ubuntu, Red Hat e dos grandes provedores de hospedagem devem indicar quais pacotes já trazem o patch. Com a causa técnica pública, o risco de ataques automatizados sobe, e quem atualizar no mesmo dia sai da fila mais visada.
