Falhas críticas no PHP: versões corrigidas e medidas para administradores

Em 21 de outubro de 2026, a equipe do PHP publicou correções para CVE-2026-109618 e CVE-2026-109619, duas falhas críticas que podem permitir execução remota de código sem autenticação em instalações que atendem requisições web. As versões upstream corrigidas e as medidas para quem ainda não consegue atualizar estão detalhadas a seguir, conforme o aviso oficial do PHP.

O que o PHP corrigiu

Execução remota de código é a possibilidade de um invasor executar comandos em um servidor pela rede. Segundo o PHP, a CVE-2026-109618 envolve uma falha no tratamento de falta de memória: o PHP pode ser interrompido enquanto dados internos da requisição ainda estão incompletos, e a limpeza posterior pode tratá-los como válidos.

Na CVE-2026-109619, um estado interno associado a uma requisição pode permanecer depois que a memória que o armazenava foi liberada. Uma requisição posterior, atendida pelo mesmo processo de trabalho, pode usar esse estado antigo antes de a inicialização normal redefini-lo.

Quais instalações devem ser revisadas

O PHP considera em risco todas as instalações que atendem requisições web. O aviso cita PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Entre essas configurações, o PHP aponta mod_php como a de maior risco: uma requisição sem autenticação pode acionar a falha antes de qualquer código da aplicação ser executado.

Versões upstream corrigidas

Esses números correspondem às versões publicadas pelo projeto PHP. Para instalações mantidas por uma distribuição Linux ou por um fornecedor de suporte de longo prazo (LTS), verifique o pacote correspondente com o próprio fornecedor.

Ramos antigos, hospedagem e PHP integrado

O projeto PHP não fornece mais atualizações para PHP 8.1 e versões anteriores. Algumas distribuições e fornecedores LTS, porém, mantêm correções retroportadas, conhecidas como backports. O PHP também publicou correções mínimas no código-fonte para os ramos 7.4, 8.0 e 8.1. A versão do pacote instalado depende de quem o mantém.

O Centro Nacional de Segurança Cibernética do Reino Unido (NCSC) também recomenda acompanhar atualizações de softwares de terceiros, incluindo aparelhos e serviços que tragam PHP integrado. Em uma hospedagem gerenciada, ou quando o PHP faz parte de outro produto, o fornecedor responsável pelo pacote é quem pode indicar a atualização aplicável.

O que fazer se a atualização não puder ser imediata

O PHP afirma que as medidas temporárias reduzem a exposição a caminhos específicos, mas não tornam segura uma instalação vulnerável. A atualização é a solução completa.

Para a CVE-2026-109618, o PHP recomenda definir memory_limit=-1 em uma configuração que a aplicação não possa substituir. A medida remove a falha causada pelo limite de memória configurável do PHP, mas uma falta de memória no sistema ainda pode alcançar o caminho vulnerável. O aviso também orienta limitar post_max_size: a 8M para aplicações sem envio de arquivos e a 32M quando uploads forem necessários. upload_max_filesize deve ficar abaixo de post_max_size.

Para a CVE-2026-109619, o PHP orienta desativar session.upload_progress.enabled=0 antes da análise da requisição e reiniciar todos os processos de trabalho. Essa medida bloqueia os caminhos confirmados ligados ao recurso de progresso de upload, mas não todas as variantes. No PHP 8.5, o aviso também recomenda definir fatal_error_backtraces=0 e reiniciar os processos; essa configuração cobre o caminho confirmado relacionado a rastros de erros fatais.

O NCSC recomenda começar identificando todas as instalações PHP, sem restringir a busca a versões antigas, e priorizar as que estão expostas à internet. Depois, a organização deve aplicar a atualização adequada e acompanhar as correções de fornecedores de pacotes e de softwares que integram PHP. Se não for possível atualizar, a alternativa é aplicar as medidas temporárias do PHP. Quando elas não puderem ser aplicadas a tempo, o NCSC recomenda considerar tirar o sistema do ar até que possa ser protegido. Se também não for possível atualizar ou desligá-lo imediatamente, a orientação é procurar sinais de comprometimento e backdoors antes da atualização ou mitigação.

O que visitantes de sites podem fazer

A vulnerabilidade está no servidor: quem visita um site não consegue instalar o patch de PHP. A correção cabe à organização que opera o servidor; em uma hospedagem gerenciada ou serviço com PHP integrado, a atualização passa pelo fornecedor responsável.