PHP 8.5.12 e 8.4.27 corrigem duas falhas RCE críticas

O PHP lançou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 em 21 de outubro de 2026 para corrigir duas falhas críticas. Ambas podem permitir que um invasor execute código em um servidor web sem fazer login. O comunicado de segurança do PHP.net pede que todos os usuários de PHP atualizem imediatamente. Ele acrescenta que nenhuma mudança de configuração protege totalmente um servidor. Por isso, instalar a nova versão é a única escolha segura.

O PHP anunciou esta versão fora do calendário um dia antes, depois que detalhes dos bugs vazaram antes do previsto. Cobrimos esse aviso prévio hoje de manhã. A versão de hoje responde às perguntas em aberto: quais versões foram corrigidas, o que os bugs fazem e quem está mais exposto.

O que as duas falhas do PHP fazem

Os dois bugs estão no código que prepara e limpa cada requisição web. O PHP dá nota 9.2 a cada um no CVSS v4.0, a escala padrão de gravidade de 0 a 10. Ele também diz que ambos “podem permitir a execução remota de código sem autenticação”. Sem autenticação significa que o invasor não precisa de conta nem de senha.

CVE	Aviso do GitHub	O que dá errado
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Ficar sem memória pode fazer o PHP parar no meio da preparação de uma requisição. O código de limpeza pode então tratar os dados construídos pela metade como válidos.
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Alguns dados da requisição podem sobreviver à memória por trás deles. A próxima requisição no mesmo processo worker pode usar primeiro esses dados obsoletos.

Um processo worker é uma das cópias de longa duração do PHP que um servidor web mantém ativas para responder a requisições. Reutilizar workers é normal e rápido. Por isso, dados que sobram de uma requisição importam para a seguinte.

Quem está em risco

Segundo o comunicado do PHP, toda instalação que atende requisições web pode ser afetada. Isso inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O PHP considera o mod_php, o módulo que executa o PHP dentro do próprio Apache, o de maior risco. O comunicado descreve um “exploit demonstrado” em que uma única requisição sem autenticação dispara o ataque antes de qualquer código da aplicação ser executado.

Esse detalhe importa para quem depende de defesas no nível da aplicação. Uma regra de firewall dentro do WordPress ou de um framework nem chega a ser executada.

O comunicado do PHP não relata ataques reais. Outros relatos são menos definidos. Segundo o TechStartups, o diretor de tecnologia da Cloudflare viu sinais iniciais de ataques, embora a escala não esteja clara. O TechStartups também cita Benjamin Harris, diretor-executivo da watchTowr, que disse ao BleepingComputer que os dois bugs são “CVSS10”. Isso é mais alto que o 9.2 atribuído pelo próprio PHP. O Gulf News, citando a Reuters, informa que sites governamentais na Europa e em outros lugares saíram do ar na quarta-feira, após a divulgação. Ele não diz se ataques causaram essas quedas.

A Amazon informou depois que seus honeypots MadPot registraram uma tentativa de exploração em 17 de outubro, quatro dias antes desta versão, como mostra Amazon viu tentativas de ataque ao PHP2Shell quatro dias antes da divulgação.

Quais versões do PHP instalar

Branch	Versão corrigida	Observações
PHP 8.5	8.5.12	Corrigida
PHP 8.4	8.4.27	Corrigida
PHP 8.3	8.3.36	Corrigida
PHP 8.2	8.2.35	Corrigida; o branch chega ao fim da vida útil em 31 de dezembro de 2026
PHP 8.1, 8.0, 7.4	Nenhuma	Apenas patches mínimos de código-fonte, em branches chamados PHP-8.1-CVE-2026-109618-109619 e semelhantes
Anteriores à 7.4	Nenhuma	Sem correção do PHP

Os patches de código-fonte para 7.4, 8.0 e 8.1 não são versões empacotadas. Alguém precisa compilá-los. O Gulf News observa que alguns fornecedores podem fazer backport das correções para versões mais antigas que ainda suportam.

O PHP também lista mitigações parciais, entre elas desativar session.upload_progress.enabled e apertar os limites de tamanho das requisições. O comunicado é direto: essas medidas “não tornam uma instalação segura”. Elas apenas restringem o ataque enquanto uma atualização de verdade é implantada.

O que isso significa para desenvolvedores

Aplique o patch hoje, e aplique também nos lugares que você esquece. O servidor óbvio raramente é a única cópia do PHP que uma organização executa.

• Verifique cada runtime, não só o site principal. Execute php -v em cada host. Depois verifique imagens base de contêiner, runners de CI, máquinas de staging e ferramentas internas. Uma imagem Docker fixada em uma tag antiga mantém o bug até que alguém a reconstrua.
• Reinicie depois de atualizar. O PHP-FPM e o Apache mantêm processos worker ativos. Um pacote novo no disco não faz nada até esses workers reiniciarem. Por isso, confirme depois a versão em execução.
• Comece pelos hosts com mod_php. O PHP aponta essa como a configuração de maior risco, com um exploit que dispara antes de o seu código rodar. Se você não puder atualizar um servidor com mod_php hoje, considere tirá-lo do ar até poder.
• Trate o PHP 8.1 e anteriores como upgrade de emergência. Nenhuma versão oficial virá. Os patches de código-fonte ganham tempo, mas só se alguém os compilar e mantiver. Pergunte ao seu provedor de hospedagem ou à sua distribuição Linux se algum deles oferece um backport.
• Planeje o fim da vida útil do PHP 8.2. O branch 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026. Migrar agora para 8.4 ou 8.5 evita uma segunda correria no fim do ano.
• Fique de olho nos logs. Os relatos de ataques iniciais não foram confirmados, mas os detalhes agora são públicos. Travamentos incomuns ou erros de falta de memória nos workers do PHP merecem uma análise mais atenta.