As falhas críticas no PHP identificadas como CVE-2026-109618 e CVE-2026-109619 receberam correções em 21 de outubro de 2026. Elas podem permitir que um atacante sem autenticação execute código no servidor, conforme as condições de exploração e a integração usada para atender às requisições web. A PHP Foundation confirmou a liberação das atualizações para as quatro séries suportadas.
O problema está no interpretador, não em um plugin específico ou exclusivamente no WordPress. Para quem administra sites, lojas ou sistemas em PHP, a verificação precisa alcançar o serviço que executa a aplicação e o pacote efetivamente fornecido pela hospedagem.
Quais versões do PHP corrigem as falhas
O comunicado do projeto PHP relaciona as seguintes versões corrigidas:
| Série do PHP | Versão com as correções |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
A tabela se refere às versões distribuídas pelo próprio projeto, frequentemente chamadas de upstream. Distribuições Linux e fornecedores de suporte podem incorporar o patch aos seus pacotes sem adotar o mesmo número de versão, situação que exige consultar o boletim do fornecedor.
PHP 8.1 e versões anteriores não voltaram ao suporte regular do projeto. Diante da gravidade, os mantenedores também disponibilizaram adaptações mínimas do código da correção para PHP 7.4, 8.0 e 8.1. Isso não equivale a uma nova linha completa de manutenção: quem depende de versões antigas precisa confirmar a cobertura do fornecedor ou planejar a migração para uma série suportada.
Duas falhas diferentes no tratamento das requisições
As vulnerabilidades envolvem memória e o ciclo de atendimento de requisições. A Cisco Talos classificou ambas com pontuação CVSS 4.0 de 9,2, considerada crítica na escala de gravidade técnica.
CVE-2026-109618: erro de memória durante uma interrupção
Segundo o boletim técnico sobre corrupção em condições de falta de memória, uma interrupção pode deixar estruturas internas da requisição parcialmente inicializadas. A etapa de encerramento pode então usar esses dados em estado inválido, abrindo caminho para execução de código.
No Apache com mod_php, o encerramento é executado mesmo quando a inicialização da requisição falha. O boletim descreve um caminho de ataque que ocorre antes do código da aplicação. Nesse cenário, exigir login no site não impede, por si só, que o processamento vulnerável seja alcançado.
No PHP-FPM, uma falha na inicialização encerra o processo de atendimento, impedindo que ele siga esse mesmo fluxo de limpeza com dados inválidos. Outros caminhos de ataque dependem de operações da aplicação. O boletim também analisa FrankenPHP e LSAPI, com condições e graus de demonstração diferentes.
CVE-2026-109619: estado antigo reutilizado por um processo
No boletim sobre reutilização de estado global, o problema aparece quando um processo de atendimento, ou worker, conserva referências a dados de uma requisição depois que a memória correspondente foi liberada.
Ao atender outra requisição, esse mesmo processo pode acessar o estado antigo antes de sua reinicialização normal. A exploração depende de operações que deixem esse estado pendente e de outras que voltem a consumi-lo. O aviso documenta como essa combinação pode chegar à execução remota de código.
Atualizar o WordPress não substitui atualizar o PHP
O alerta oficial do WordPress esclarece que não há atualização do CMS exigida ou prevista especificamente para resolver essas vulnerabilidades. A correção pertence à camada PHP do servidor.
No painel do WordPress, o caminho indicado para consultar a versão em uso é Ferramentas → Saúde do site → Informações → Servidor. A informação também pode aparecer no painel da hospedagem. Esse número ajuda a identificar a instalação, mas precisa ser confrontado com a revisão do pacote e o boletim do provedor quando houver correção retroportada.
Em hospedagem compartilhada ou gerenciada, a pergunta ao suporte deve ser específica: as duas CVEs foram corrigidas no serviço PHP que atende aquele domínio? Uma resposta sobre atualização de plugins ou regras adicionais de firewall não confirma que o interpretador tenha recebido o patch.
Para instalações administradas pela própria equipe, também importa distinguir ambientes. Um servidor pode oferecer mais de uma versão do PHP para sites diferentes; o resultado observado em um domínio não comprova a situação de todos os demais.
Por que um pacote PHP 8.3.6 pode conter a correção
A Canonical publicou o aviso USN-8948-1 para as duas vulnerabilidades. No Ubuntu 24.04 LTS, o boletim identifica a revisão 8.3.6-0ubuntu0.24.04.13 dos pacotes PHP 8.3 como corrigida, embora o número inicial seja menor que o PHP 8.3.36 da tabela upstream.
Essa diferença é um exemplo de backport: o fornecedor aplica mudanças de segurança à versão que mantém na distribuição. A comparação precisa considerar o identificador completo do pacote, a edição do sistema e o aviso correspondente, não apenas os primeiros números mostrados no painel.
O mesmo boletim inclui pacotes PHP 8.1 do Ubuntu 22.04 LTS. Isso demonstra uma correção disponibilizada pela distribuição; não significa que o projeto PHP tenha retomado o suporte regular à série 8.1.
Na confirmação com o provedor, três informações ajudam a eliminar ambiguidades: a identificação da instalação que atende o site, a revisão corrigida fornecida para aquele sistema e o boletim que cobre ambas as CVEs. A condição publicada para um pacote Ubuntu não pode ser transferida automaticamente para outro repositório ou fornecedor.
WAF e ajustes temporários não encerram a atualização
A Talos informa que regras de detecção para Snort foram disponibilizadas, inclusive na edição comunitária. São controles de rede adicionais; não alteram o código vulnerável do interpretador. Sua presença não comprova que o servidor tenha sido corrigido.
O NCSC britânico recomenda identificar as instalações PHP e priorizar as expostas à internet, em vez de procurar somente versões já consideradas antigas. Essa exposição é também um critério para a priorização de atualizações de segurança.
O órgão orienta seguir as medidas temporárias publicadas pelo fornecedor quando a atualização não puder ser aplicada de imediato. Se nem a correção nem essas medidas forem viáveis no prazo necessário, recomenda considerar a retirada do sistema do ar até que a exposição possa ser mitigada. Trata-se de uma decisão operacional a avaliar para o serviço afetado, não de uma instrução para desligar indiscriminadamente qualquer site que use PHP.
O projeto PHP ressalta que as medidas provisórias reduzem caminhos específicos de ataque, mas não substituem uma atualização completa. Para sistemas que não puderem ser atualizados ou desativados imediatamente, o NCSC também orienta procurar evidências de comprometimento e possíveis acessos persistentes deixados por invasores antes da atualização ou mitigação.
A liberação das correções foi antecipada
Segundo a PHP Foundation, a publicação estava prevista para 22 de outubro, às 14h UTC, mas foi antecipada para 21 de outubro, no mesmo horário. A mudança ocorreu após os identificadores das CVEs começarem a circular em fóruns e redes sociais em 20 de outubro, acompanhados de informações incorretas sobre horário e gravidade.
A fundação relata que as distribuições já preparavam seus pacotes. As quatro versões corrigidas do projeto PHP foram liberadas em 21 de outubro, um dia antes do cronograma original.
