PHP corrige duas vulnerabilidades críticas de execução remota em 8.5.12, 8.4.27, 8.3.36 e 8.2.35

O aviso que levou a PHP Foundation a pedir atualização imediata

Em 21 de outubro de 2026, a PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) → Foundation publicou um aviso de segurança descrevendo duas vulnerabilidades críticas que permitem execução remota de código (RCE) sem necessidade de autenticação. As correções saíram em quatro versões simultaneamente: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. A recomendação da equipe de segurança é direta: atualizar imediatamente, sem esperar a próxima janela de manutenção.

O aviso classifica o risco como mais alto para instalações que rodam mod_php no Apache, onde foi demonstrado um exploit em que uma requisição não autenticada dispara o ataque antes mesmo de qualquer código da aplicação ser executado. Isso significa que WAF, autenticação da própria aplicação ou validação de entrada no código PHP não entram a tempo de bloquear o ataque: a falha acontece na camada do interpretador, abaixo do seu código.

As duas falhas: memória mal liberada e estado global contaminado

CVE-2026-109618 (RCE via corrupção por falta de memória, GHSA-w8hw-w9fx-j79w): quando o PHP fica sem memória durante o processamento de uma requisição, o tratamento desse erro pode interromper a inicialização de dados internos no meio do caminho. Na limpeza pós-requisição, o PHP trata esses dados parcialmente inicializados como se fossem válidos, abrindo caminho para execução de código arbitrário.

CVE-2026-109619 (RCE via estado global obsoleto, GHSA-6wmf-4rv5-p3rp): estado interno pertencente a uma requisição pode sobreviver depois que a memória que o sustenta já foi liberada. Um worker do PHP-FPM que atende múltiplas requisições em sequência pode, numa requisição seguinte, usar esse estado obsoleto antes que a inicialização normal o zere.

Em comum, as duas falhas exploram o ciclo de vida interno do interpretador PHP (alocação e liberação de memória por requisição), não um bug de lógica de aplicação. É por isso que nenhuma correção no nível do framework ou do código da aplicação resolve: a única solução completa é atualizar o binário do PHP.

Quem está exposto

O aviso lista como em risco toda instalação PHP que atende requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Na prática, isso cobre praticamente qualquer stack PHP em produção, de WordPress em hospedagem compartilhada a APIs Laravel ou Symfony rodando atrás de Nginx com PHP-FPM.

Para quem mantém infraestrutura no Brasil, vale mapear três cenários comuns:

• Hospedagem compartilhada com cPanel: geralmente roda mod_php ou php-cgi, exatamente o cenário de maior risco citado no aviso. A atualização depende do provedor de hospedagem, e vale checar o painel ou abrir chamado.
• VPS ou servidor dedicado com PHP-FPM + Nginx: depende do pacote da distribuição (apt, dnf) ou de build manual. Se o servidor usa Ubuntu, Debian, RHEL ou Alma, o aviso confirma que distribuições Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → e fornecedores LTS já receberam os patches antes do anúncio público.
• Containers Docker: imagens oficiais como php:8.4-fpm ou php:8.3-cli precisam ser reconstruídas a partir de uma tag atualizada; apenas reiniciar o container com a imagem antiga não aplica o patch.

Como atualizar

O caminho recomendado depende de como o PHP chegou ao seu servidor:

1. Se você compila a partir do código-fonte, baixe PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 na página oficial de downloads do projeto.
2. Se usa pacotes de distribuição Linux (apt, dnf, yum) ou um fornecedor LTS, verifique se o pacote já foi atualizado, já que esses canais receberam os patches com antecedência.
3. Se o projeto roda em PHP 8.1 ou anterior, não há mais atualização oficial do projeto PHP para essas versões. Algumas distribuições e fornecedores LTS mantêm backports, então vale checar com o fornecedor, ou planejar a migração para uma versão suportada.

Um ponto que pega bastante gente que mantém servidor PHP no Brasil: quem depende do repositório rpms.remirepo.net, mantido por voluntários e muito usado para ter versões recentes do PHP em CentOS, RHEL e Alma Linux, não vai encontrar as atualizações lá no dia do aviso. A recomendação é migrar para os pacotes da própria distribuição ou compilar a partir do código-fonte enquanto isso.

Para quem ainda está em PHP 7.4, 8.0 ou 8.1, a equipe de segurança do PHP liberou backports mínimos de código-fonte, uma exceção dada a gravidade do caso, para quem compila do zero ou não tem acesso a um fornecedor LTS.

Se não dá para atualizar agora: mitigações, não solução

O próprio aviso é enfático: as medidas abaixo reduzem a exposição a caminhos específicos de ataque, mas não tornam a instalação segura. Só a atualização resolve de fato.

Duas ressalvas do próprio aviso merecem atenção. Primeiro, para a falha de OOM, usar RLIMIT_AS ou RLIMIT_DATA no lugar de limite de container pode piorar o problema, porque esses limites conseguem causar justamente a falha de alocação que dispara a vulnerabilidade. Segundo, para a falha de estado obsoleto, esconder os diagnósticos com error_reporting, display_errors ou @ não ajuda em nada: é preciso corrigir os erros fatais alcançáveis por um atacante, incluindo falhas em callbacks, processamento de upload ou import, e timeouts de execução.

O que o aviso não responde

O material não detalha um exploit completo nem prova de conceito pública, o que é esperado em um aviso recém-publicado: a PHP Foundation costuma liberar os detalhes técnicos completos (campo do payload, condição exata de corrida) só depois que a maior parte do parque de produção já atualizou. Também não há, no aviso, um prazo definido para quando os advisories GHSA linkados vão trazer esses detalhes, nem estimativa de quantas instalações seguem vulneráveis.

Para times que mantêm PHP em produção, a ação prática agora é simples: checar a versão rodando (php -v), confirmar se o pacote do sistema operacional ou a imagem Docker já foi atualizada e, enquanto isso não acontece, aplicar as mitigações da tabela acima sabendo que elas são paliativo, não solução.