O PHP publicou hoje, 21 de outubro de 2026, uma atualização de segurança urgente para duas vulnerabilidades críticas que podem permitir execução remota de código sem autenticação. Os problemas foram identificados como CVE-2026-109618 e CVE-2026-109619, ambos com pontuação CVSS v4.0 de 9,2.
O alerta é especialmente relevante para servidores que executam PHP e recebem requisições da internet. A equipe do PHP recomenda a atualização imediata, enquanto o CERT-EU orienta as organizações a identificar os ativos afetados e preparar a aplicação das correções sem demora.
O que foi corrigido
As duas falhas podem levar a remote code execution, ou execução remota de código, sem que o atacante precise se autenticar. Isso significa que um invasor pode tentar explorar o processo PHP por meio de uma requisição especialmente preparada antes mesmo de a aplicação web executar seu código normal.
A primeira vulnerabilidade, CVE-2026-109618, está relacionada a corrupção causada por uma condição de falta de memória. Em determinadas situações, o tratamento de erro pode interromper o PHP quando estruturas internas de uma requisição ainda estão parcialmente inicializadas. Durante a limpeza, dados inválidos podem ser tratados como se fossem válidos.
A segunda, CVE-2026-109619, envolve estado global obsoleto. Dados internos pertencentes a uma requisição podem permanecer depois que a memória de suporte foi liberada. Uma requisição posterior atendida pelo mesmo processo pode reutilizar esse estado antes da inicialização normal, abrindo um caminho para comportamento inesperado e execução de código.
Os detalhes técnicos completos foram publicados nos avisos de segurança vinculados pelo projeto PHP. Como os problemas afetam componentes que processam requisições, o risco não depende apenas do framework ou do CMS usado pela aplicação.
Quem pode estar vulnerável
O aviso oficial considera em risco as instalações PHP que atendem requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é considerado maior em ambientes com mod_php, para os quais foi demonstrado um caminho em que uma requisição não autenticada pode iniciar o ataque antes da execução do código da aplicação.
A versão do PHP precisa ser verificada diretamente no servidor. Não é suficiente confirmar apenas a versão do WordPress, do Laravel ou de outro sistema que use PHP. Também é importante identificar servidores legados, ambientes de homologação expostos, contêineres esquecidos e serviços que utilizam uma versão diferente da instalação principal.
Versões corrigidas
O PHP disponibilizou as seguintes versões corrigidas:
- PHP 8.5.12;
- PHP 8.4.27;
- PHP 8.3.36;
- PHP 8.2.35.
As versões PHP 8.1 e anteriores não recebem mais atualizações regulares do projeto PHP. Distribuições Linux e fornecedores com suporte de longo prazo podem oferecer correções retroportadas, mas isso deve ser confirmado com o fornecedor responsável. Quando não houver pacote corrigido, o caminho recomendado é migrar para uma versão suportada.
O PHP 8.2 tem suporte de segurança previsto até 31 de dezembro de 2026. Mesmo depois da aplicação desta correção, equipes que ainda usam PHP 8.2 devem planejar a migração para uma versão com ciclo de suporte mais longo.
O que administradores devem fazer agora
Primeiro, faça um inventário. Liste servidores, contêineres, imagens de aplicação, pools PHP-FPM, módulos Apache, serviços CGI, proxies e provedores de hospedagem que executam PHP. Registre a versão efetiva em cada ambiente e não apenas a versão declarada no gerenciador de dependências.
Depois, atualize para uma versão corrigida. Use os pacotes oficiais da distribuição, do provedor de hospedagem ou os binários disponibilizados pelo PHP. Reinicie os processos PHP-FPM, Apache, LiteSpeed ou outros trabalhadores para garantir que todos os processos carreguem a versão corrigida. Valide a versão depois do reinício.
Revise a exposição à internet. Enquanto a atualização não for possível, o CERT-EU recomenda considerar o isolamento de aplicações PHP voltadas para a internet. Essa medida reduz a exposição, mas não substitui a atualização. Restrição de acesso por rede, proxy ou VPN deve ser temporária e acompanhada por monitoramento.
O PHP documenta algumas configurações que reduzem caminhos específicos de exploração, como limites de tamanho de requisições e desativação de determinados recursos de progresso de upload. Essas medidas são paliativas: o próprio projeto afirma que não tornam uma instalação segura. A atualização é a única solução completa.
Como verificar um servidor
Em instalações tradicionais, verifique a versão do interpretador usado pelo serviço web, não apenas a versão do PHP disponível no terminal:
php -v
php-fpm -v
php -i | grep -E 'PHP Version|Server API'Em contêineres, verifique a imagem efetivamente em execução:
docker exec <container> php -v
kubectl exec <pod> -- php -vO resultado deve ser comparado com a versão corrigida correspondente à linha de suporte utilizada. Em provedores gerenciados, solicite confirmação sobre as versões disponíveis e pergunte especificamente se as correções para CVE-2026-109618 e CVE-2026-109619 já foram aplicadas.
Depois da atualização: procure sinais de comprometimento
Como as falhas podem permitir execução remota de código, a correção deve ser acompanhada por uma verificação básica de segurança. Revise logs do servidor web, PHP-FPM, WAF, proxy e sistema operacional em busca de requisições incomuns, picos de erro, criação inesperada de arquivos, processos filhos anômalos ou conexões de saída desconhecidas.
Também verifique alterações recentes em arquivos PHP, tarefas agendadas, usuários administrativos, chaves SSH, tokens de aplicação e credenciais armazenadas no servidor. Se houver evidência de exploração, preserve os logs, isole o ativo, faça uma análise forense e altere as credenciais potencialmente expostas. Não presuma que a simples atualização removeu uma persistência já instalada.
Impacto para sites WordPress
Sites WordPress podem estar vulneráveis mesmo quando o núcleo, os plugins e os temas estão atualizados, porque a falha está no interpretador PHP que processa o site. Por isso, proprietários de sites devem verificar a versão de PHP no painel da hospedagem ou solicitar essa informação ao provedor.
Após a atualização, teste login, publicação, upload de mídia, formulários, tarefas agendadas, integrações externas e páginas que dependam de extensões PHP. Mantenha um backup recente e confirme que existe um procedimento de restauração antes de alterar a versão em produção.
Conclusão
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 merecem tratamento prioritário porque combinam alta severidade com a possibilidade de execução remota sem autenticação. A resposta mais segura é identificar todas as instalações PHP expostas, atualizar para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — conforme a linha utilizada — e investigar sinais de exploração.
Se a atualização imediata não for possível, reduza temporariamente a exposição da aplicação e aplique as medidas paliativas recomendadas pelo projeto PHP. Não trate essas medidas como substitutas do patch: para esta falha, a correção definitiva é atualizar.
Fontes oficiais
PHP.net: Security advisory: Critical remote code execution vulnerabilities, update now.
PHP Security Team: Upcoming Critical PHP Security Release.
CERT-EU: Critical Vulnerabilities in PHP — Security Advisory 2026-018.
GitHub Security Advisories: CVE-2026-109618 e CVE-2026-109619.
