A falha crítica do PHP de outubro de 2026

PHP2Shell: o que se sabe sobre as duas falhas que permitem invadir servidores PHP sem senha, e por que corrigi-las dá mais trabalho do que parece.

Na terça-feira, 20 de outubro de 2026, a equipe de segurança do PHP fez algo incomum: avisou com um dia de antecedência que lançaria uma correção crítica. No dia seguinte saíram as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Elas corrigem duas vulnerabilidades, a CVE-2026-109618 e a CVE-2026-109619, ambas com nota 9.2 na escala CVSS 4.0. A recomendação oficial foi direta: atualizar imediatamente, porque nenhuma medida alternativa resolve o problema por completo.

O caso ganhou o apelido de PHP2Shell, nome de uma ferramenta de exploração que circulou em vazamentos antes do anúncio oficial. A gravidade vem da combinação de três fatores. O PHP roda boa parte da web, de WordPress e Magento a sistemas internos em Laravel. As falhas permitem executar código no servidor sem login. E o defeito está no próprio interpretador, então atualizar o CMS ou os plugins não resolve.

O código vulnerável existe desde o PHP 5.4, lançado em 2012. Isso significa que praticamente todo servidor PHP em produção estava exposto na manhã de 21 de outubro.

Duas falhas, um mesmo princípio

As duas vulnerabilidades exploram o mesmo ponto fraco: o PHP confia em dados internos que já não são válidos.

A CVE-2026-109618 envolve falta de memória no meio da preparação de uma requisição. O PHP marca certas estruturas internas como prontas antes de terminar de montá-las. Se a memória acaba nesse intervalo, a requisição é abortada e a rotina de limpeza trata a estrutura incompleta como válida. Isso corrompe a memória do processo. Pesquisadores mostraram que um POST grande, com um nome de campo gigante, basta para provocar essa falta de memória ainda durante a leitura dos dados enviados. Ou seja, antes de qualquer linha do site ser executada. A Red Hat acrescenta que o mesmo mecanismo de upload também pode devolver ao atacante trechos de memória do servidor dentro do cookie de sessão.

A CVE-2026-109619 envolve estado que sobrevive entre requisições. Servidores PHP modernos reaproveitam o mesmo processo para atender várias requisições seguidas. Em certos cenários, como um erro fatal com geração de backtrace ou o acompanhamento de progresso de upload de sessões, dados de uma requisição continuam referenciados depois que a memória foi liberada. A requisição seguinte, que pode ser a do atacante, usa esse resíduo antes que o PHP o reinicialize.

Combinadas, as duas falhas viram uma ferramenta de invasão que não depende de senha nem de qualquer defeito na aplicação. Segundo a Abstract Security, o ataque roda comandos com o usuário do servidor web sem derrubar o processo. Por isso pode não deixar nenhuma instabilidade visível.

Quem está exposto

O aviso oficial lista como vulneráveis todas as versões anteriores às corrigidas, em qualquer forma de execução web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco, porém, não é igual para todos.

Modo de execução	Risco	Motivo
Apache com mod_php	Mais alto	Exploração demonstrada sem login na configuração padrão, antes do código da aplicação rodar
PHP-FPM	Alto, mas exploração mais difícil	O FPM encerra o processo quando a inicialização falha; segundo o PHP, nenhuma exploração completa da CVE-2026-109618 contra FPM foi demonstrada
php-cgi, FrankenPHP, LiteSpeed	Alto	Listados como afetados no aviso oficial

A idade do problema é outro agravante. Segundo a watchTowr, versões que já não recebem suporte, inclusive o PHP 5, também são afetadas. Ambientes legados, comuns em sistemas internos de empresas e órgãos públicos, ficaram expostos e sem correção oficial.

As complicações

Em teoria, a solução é uma linha: atualizar o PHP. Na prática, o caso expõe vários problemas de quem mantém sites e sistemas.

Exploração ativa ou não? As fontes divergem

No dia do anúncio, a watchTowr informou ter detectado tentativas de exploração em sua rede de honeypots. A Sansec revisou a própria avaliação em 22 de outubro: os exploits públicos testados não funcionaram contra uma instalação padrão, e a maioria exige uma falha adicional de inclusão de arquivos na aplicação. Até 22 de outubro, a CISA não havia incluído as falhas em seu catálogo de vulnerabilidades exploradas. Para quem decide prioridades, a incerteza não muda nada: o código de ataque existe, foi demonstrado contra WordPress, Drupal e Joomla em configuração padrão, e a correção está disponível.

O número da versão engana

Distribuições Linux corrigem o PHP sem mudar o número principal da versão. A AlmaLinux, por exemplo, publicou pacotes corrigidos com numeração como 8.2.33 e 8.3.33, acrescida de um sufixo próprio. Um servidor pode mostrar uma versão “antiga” no phpinfo e já estar protegido, ou o contrário. Conferir apenas o número da versão leva a conclusões erradas. É preciso verificar a origem do pacote e o aviso de segurança da distribuição.

Quem controla a atualização nem sempre é você

Em hospedagem compartilhada, revendas cPanel e painéis como Plesk, a atualização depende do provedor. Imagens Docker com PHP fixado em uma tag antiga continuam vulneráveis até alguém reconstruir o contêiner. Servidores configurados anos atrás por terceiros, sem documentação, atrasam o diagnóstico de qual PHP realmente atende o site.

Versões sem suporte ficaram sem saída oficial

O PHP 8.1 e anteriores não recebem mais atualizações do projeto. A equipe do PHP publicou correções mínimas no código-fonte para 7.4, 8.0 e 8.1, mas elas exigem compilação manual. Na prática, quem roda um sistema legado tem três caminhos: compilar o PHP, depender de um fornecedor de suporte estendido ou migrar a aplicação às pressas.

O próximo prazo já está marcado

O PHP 8.2 recebe a última correção de segurança em 31 de dezembro de 2026. Muitos sites atualizados agora para a 8.2.35 estarão de novo sem cobertura em dois meses. A migração para 8.3 ou 8.4 pede testes de compatibilidade de temas, plugins e código próprio.

Mitigações reduzem o risco, não o eliminam

O aviso oficial lista medidas para quem não pode atualizar de imediato. Entre elas estão desativar o acompanhamento de progresso de upload de sessões, reduzir o tamanho máximo de POST e, no PHP 8.5, desligar os backtraces de erro fatal. O próprio PHP avisa que elas bloqueiam caminhos específicos de ataque, não todos. Algumas também conflitam com aplicações que dependem desses recursos.

Uma invasão pode não deixar rastro aparente

Como o ataque executa comandos sem derrubar o processo, um servidor comprometido entre o vazamento e a correção pode parecer normal. Atualizar fecha a porta, mas não remove quem já entrou. Os pesquisadores apontam dois sinais nos logs: erros fatais de falta de memória sem script associado e POSTs anormalmente grandes.

O que fazer agora

Para quem mantém sites PHP, a ordem é simples. Primeiro, identificar qual PHP realmente atende cada site e de onde vem o pacote. Depois, atualizar para uma versão corrigida, oficial ou da distribuição, e reiniciar todos os processos PHP. Em seguida, procurar sinais de invasão no período em que o servidor ficou exposto. Por fim, planejar a saída do PHP 8.2 antes do fim do ano.

Para clientes e gestores, a pergunta a fazer ao fornecedor ou à equipe técnica é objetiva: “nosso PHP já está corrigido contra a CVE-2026-109618 e a CVE-2026-109619, e alguém verificou se houve acesso indevido?”

Lições que ficam

O PHP2Shell repete um padrão conhecido: o maior risco não está no código que se escreve, e sim na camada que se esquece de manter. Algumas práticas reduzem o impacto do próximo caso:

manter inventário de cada servidor, com versão do PHP, origem dos pacotes e quem é responsável por atualizar;
ativar atualizações de segurança automáticas do sistema operacional sempre que possível;
preferir PHP-FPM a mod_php e reciclar periodicamente os processos;
acompanhar o calendário de suporte das versões e migrar antes do fim, não depois;
manter backups fora do servidor e monitoramento de alterações de arquivos;
incluir manutenção contínua no contrato de cada site entregue.

Falhas no interpretador vão continuar aparecendo. A diferença entre um susto e um incidente costuma estar em quanto tempo separa o anúncio da correção aplicada.