Duas falhas de execução remota de código no PHP atingem todas as instalações da web

Em 21 de outubro de 2026 o PHP publicou um aviso de segurança com duas falhas críticas de execução remota de código. As duas permitem que um atacante execute código no servidor sem precisar de senha, sem token e sem nenhuma credencial válida. A recomendação oficial é atualizar imediatamente, e o conselho é levá-lo a sério: são falhas de.authentication zero, do tipo que os atacadores automatizados procuram primeiro.

A primeira falha é a CVE-2026-109618, registrada como GHSA-w8hw-w9fx-j79w. Ela acontece quando o PHP fica sem memória durante o tratamento de uma requisição. O caminho de limpeza dos dados internos da requisição é interrompido no meio, e o que sobrou pela metade acaba sendo tratado como se estivesse inteiro. O resultado é a corrupção da memória do processo, e é a partir dela que o código do atacante roda, antes de qualquer linha da aplicação chegar a ser executada.

A segunda falha é a CVE-2026-109619, registrada como GHSA-6wmf-4rv5-p3rp. Aqui o problema é o estado interno que pertence à requisição. Esse estado pode sobreviver depois de a memória que o sustentava ter sido liberada, e a requisição seguinte, atendida pelo mesmo processo, acaba usando esse estado velho antes que a inicialização normal o substitua.

O risco é maior justamente onde o PHP é mais comum: qualquer instalação que atende requisições da web. Isso inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O PHP considera o risco máximo no mod_php, porque existe um exploit demonstrado em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação rodar. A correção é atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, conforme a série em uso.

Quem não consegue atualizar de imediato pode reduzir a exposição com medidas de contenção. Para a CVE-2026-109618, o caminho é colocar memory_limit como -1 de um jeito que a aplicação não consiga reverter, por exemplo com php_admin_value no pool do FPM, e manter post_max_size baixo, como 8M quando não há upload ou 32M quando há, sempre com upload_max_filesize abaixo do post_max_size, além de limites de requisição no servidor web. Para a CVE-2026-109619, o caminho é desativar session.upload_progress.enabled em um php.ini, pool do FPM ou configuração do servidor que valha antes da análise da requisição, sem depender de ini_set() nem de .user.ini, e, no PHP 8.5, colocar fatal_error_backtraces como 0.

O próprio aviso é claro: somente a atualização é a solução completa. As contenções acima diminuem a exposição para caminhos específicos, mas não tornam a instalação segura. A série 8.1 e anteriores deixou de receber atualizações do projeto PHP, e algumas distribuições e fornecedores de longo prazo mantêm correções próprias. Quem usa o repositório mantido por voluntários, o rpms.remirepo.net, deve migrar para os pacotes da distribuição ou compilar a partir do código, porque esse repositório não recebe atualização hoje. A equipe de segurança do PHP também RELEASE minimal source-backports para 7.4, 8.0 e 8.1, para quem compila do código ou não tem fornecedor de longo prazo.

A lição prática é a de sempre, e ela continua valendo: uma falha crítica de dois dias de duração já foi explorada em escala global, porque a varredura automatizada não espera ninguém. A diferença entre uma empresa que foi exposta e uma que não foi está no processo de atualização, não na sorte.