Falhas críticas do PHP: da corrupção de memória à proteção da operação

O que essas vulnerabilidades mudam

As falhas atingem o núcleo do PHP, abaixo de frameworks como Laravel, Symfony e WordPress. Uma aplicação pode manter seus pacotes atualizados e ainda executar sobre um interpretador vulnerável. O impacto potencial é execução remota de código com os privilégios do processo PHP; o alcance sobre arquivos, segredos e outros serviços depende das permissões e do isolamento do ambiente.

As correções foram publicadas em 21/10/2026. O PHP atribui CVSS 4.0 de 9.2 às duas CVEs; o NVD registra CVSS 3.1 de 9.8 para a CVE-2026-109618. São avaliações com versões e vetores distintos. A existência de PoCs públicos aumenta a urgência, mas não comprova comprometimento nem exploração universal.

Versões oficiais com correção

A tabela descreve as séries oficiais suportadas. Backports de distribuições podem usar outro número de pacote: confirme o boletim e a revisão do fornecedor. PHP 8.1 e anteriores estão fora do suporte regular oficial; fornecedores LTS e backports de emergência exigem avaliação própria.

CVE-2026-109618 · quando a interrupção deixa a memória inválida

O tratamento de falta de memória (out-of-memory, OOM) pode interromper uma operação enquanto estruturas internas da requisição ainda não estão completamente inicializadas. Mais tarde, a rotina de encerramento pode tratar esse estado incompleto como válido. O problema é a segurança da limpeza após a interrupção, e não simplesmente “consumir muita RAM”.

No mod_php, há demonstração de execução remota antes do código da aplicação. No PHP-FPM, falhas durante o startup podem encerrar o filho, mas caminhos durante a execução da aplicação também precisam ser considerados. Por isso, uma página de login e validações implementadas apenas no framework não formam uma barreira suficiente.

CVE-2026-109619 · memória liberada, referência ainda viva

A segunda falha atravessa a fronteira entre requisições. Um worker persistente retém uma referência global a memória que pertencia à requisição anterior. Se o estado não for limpo corretamente antes de liberar essa memória, uma operação posterior pode acessá-la como se ainda estivesse válida: é o padrão use-after-free.

O encadeamento depende de um produtor de estado obsoleto e de um consumidor que o alcance antes da reinicialização normal, em outra requisição atendida pelo mesmo worker. Erros fatais podem interromper a limpeza; operações de sessão e upload ou diagnósticos iniciais podem participar do caminho. Um novo request HTTP não implica um novo processo nem memória global nova.

A mesma falha, caminhos de exposição diferentes

Como priorizar a exposição real

Comece pelos serviços expostos à internet e pelos ambientes com mod_php. Mapeie também APIs, backoffices, uploads, importadores e produtos de terceiros que embarcam PHP. No FPM, avalie os pools e o fluxo da aplicação; trocar somente o frontend HTTP não remove uma falha do interpretador.

Uma correção distribuída por backport pode manter o número principal antigo. A decisão deve se apoiar no boletim do fornecedor e na revisão instalada, e não apenas em banners HTTP ou comparações textuais de versões. A indicação genérica “PHP 8.2+” é insuficiente: cada série tem um ponto mínimo corrigido.

Defesa em camadas, com a correção no centro

O controle decisivo é aplicar a correção completa do runtime. Enquanto a mudança é preparada, restrinja caminhos expostos e revise limites no proxy e no servidor. Um WAF pode reduzir tráfego conhecido; ele não prova que todos os caminhos de corrupção de memória foram bloqueados.

Medidas como desabilitar session.upload_progress.enabled quando o recurso não é necessário, ou fatal_error_backtraces nos casos aplicáveis do PHP 8.5, atingem caminhos específicos e exigem configuração administrativa e reinício dos workers. Não substituem o patch. Não aplique mudanças genéricas em memory_limit sem avaliar disponibilidade e os limites de recursos do ambiente.

Roteiro de correção verificável

1. Inventarie o PHP do servidor web, dos pools FPM, dos workers de fila, do cron e das imagens. O php -v do terminal verifica apenas aquele binário CLI.
2. Confirme a correção no advisory do fornecedor e registre pacote, revisão, origem do repositório e, em contêineres, digest da imagem.
3. Teste autenticação, uploads, sessões, importações, integrações, extensões e tarefas assíncronas em homologação. Prepare backup restaurável e plano de retorno.
4. Atualize o pacote ou reconstrua a imagem e substitua todos os processos afetados. Atualização no disco sem renovar workers pode deixar o runtime antigo ativo.
5. Valide a versão usada pelo tráfego real, os fluxos de negócio e os logs após a troca. Use diagnóstico restrito; não publique phpinfo() para comprovar a versão.
6. Guarde evidências de implantação e da validação. Um rollback para uma versão vulnerável exige contenção e um novo plano de correção.

O que observar depois da atualização

Correlacione erros fatais, OOM, falhas de workers, avisos de inicialização e comportamento anormal de uploads com os logs do proxy e da aplicação. Esses sinais orientam a investigação, mas isoladamente não demonstram exploração. Da mesma forma, a ausência de mensagens não comprova segurança: algumas falhas ocorrem antes de registrar o erro.

Se houver suspeita de comprometimento, atualizar não encerra a resposta ao incidente. Preserve evidências, contenha o ativo e avalie credenciais, alterações de arquivos e acessos dependentes. A correção deve ser acompanhada da investigação do que aconteceu antes dela.