Falhas críticas no PHP em outubro de 2026: o que as software houses precisam corrigir agora

Outubro de 2026 trouxe o incidente de segurança mais sério do PHP em anos: duas vulnerabilidades críticas de execução remota de código, CVE-2026-109618 e CVE-2026-109619, corrigidas em atualizações de emergência no dia 21, e uma terceira, CVE-2026-115560, divulgada no dia 23 e ainda sem correção. As versões seguras são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem mantém sistemas em PHP precisa atualizar agora e aplicar a mitigação da terceira falha (desativar o session.upload_progress). Este post resume o que se sabe e traz o checklist para quem administra uma carteira de clientes.

O que aconteceu

No dia 20 de outubro o projeto PHP avisou que lançaria correções de emergência para duas falhas críticas, classificadas com CVSS 9,2 (v4.0) pela própria equipe, e pesquisadores chegaram a tratá-las como nota máxima. As correções saíram no dia 21, às 14h UTC, conforme a cobertura da BleepingComputer. As duas vulnerabilidades são do tipo use after free e permitem que um atacante não autenticado execute código arbitrário no servidor, segundo o alerta do centro de cibersegurança do Canadá. Há prova de conceito circulando, e o CTO da Cloudflare relatou os primeiros ataques observados logo após a divulgação.

Dois dias depois, em 23 de outubro, veio a parte que muita equipe ainda não viu: uma terceira vulnerabilidade de execução remota de código, CVE-2026-115560, que não é corrigida pelas atualizações do dia 21.

Versões afetadas e corrigidas

Para as duas primeiras falhas, as versões corrigidas são: 8.5.12 (para a série 8.5), 8.4.27 (série 8.4), 8.3.36 (série 8.3) e 8.2.35 (série 8.2). Qualquer versão anterior dentro dessas séries está vulnerável.

PHP 8.1 e anteriores não recebem mais atualizações do projeto. Sistemas nessas versões dependem de correções retroportadas do fornecedor da distribuição (Debian, Ubuntu, Red Hat e similares) ou de um fornecedor de suporte estendido; sem isso, ficam vulneráveis em definitivo. Se a sua carteira ainda tem produção em 8.1 para baixo, este incidente é o argumento concreto para o projeto de migração que vinha sendo adiado.

A terceira falha ainda não tem correção

Para a CVE-2026-115560, a recomendação oficial até a próxima atualização de segurança é desativar o recurso de progresso de upload de sessão no php.ini: session.upload_progress.enabled=0, com reinício do serviço. É uma funcionalidade pouco usada em aplicações modernas, então o custo da mitigação tende a ser baixo. Regras de WAF ajudam a reduzir a exposição enquanto o patch não sai, mas são paliativo, não correção.

Checklist para quem mantém carteira de clientes

Para uma software house, o trabalho não é atualizar um servidor, é varrer uma frota. A sequência que recomendamos: inventariar tudo que roda PHP na carteira, incluindo sistemas legados, e-commerces, WordPress e APIs internas, sem esquecer imagens de contêiner e appliances de terceiros que embarcam PHP; priorizar o que está exposto à internet e processa entrada de usuário; atualizar para a versão corrigida da série correspondente; aplicar a mitigação da terceira falha em todos os ambientes; e monitorar logs de aplicação e servidor atrás de processos, arquivos ou conexões de saída inesperados, porque exploração começou a ser observada. Clientes com contrato de manutenção devem ser avisados do que foi feito; clientes sem contrato devem ser avisados do risco, por escrito.

O que o incidente diz sobre contratos de sustentação

Um patch de emergência numa quarta-feira é exatamente o cenário que separa sustentação de abandono. Sistemas entregues sem contrato de manutenção não têm quem aplique a correção, e o cliente em geral só descobre isso no incidente. Para as software houses, a janela é dupla: proteger a própria carteira e oferecer o serviço de varredura e atualização para empresas cujo fornecedor original sumiu. O nosso checklist de encerramento de projeto trata justamente de deixar hospedagem e manutenção definidas antes de o projeto acabar, e o guia de contratação cobre o que exigir nesse ponto.

Perguntas frequentes

Quais versões do PHP estão vulneráveis?

Todas as versões 8.2, 8.3, 8.4 e 8.5 anteriores às correções de 21 de outubro de 2026 (8.2.35, 8.3.36, 8.4.27 e 8.5.12), além de PHP 8.1 e anteriores, que não recebem mais atualizações oficiais do projeto.

Como corrijo as falhas CVE-2026-109618 e CVE-2026-109619?

Atualizando o PHP para a versão corrigida da sua série (8.2.35, 8.3.36, 8.4.27 ou 8.5.12) e reiniciando o serviço. Em distribuições Linux, use o pacote atualizado do fornecedor; em contêineres, reconstrua a imagem com a base corrigida.

E a CVE-2026-115560, que não tem patch?

Até a correção sair, desative o progresso de upload de sessão (session.upload_progress.enabled=0 no php.ini) e reinicie o serviço. Acompanhe os anúncios de segurança do projeto PHP para aplicar o patch assim que for publicado.

Rodo PHP 7 ou 8.1. O que faço?

Verifique se a sua distribuição oferece correção retroportada e aplique. Em paralelo, trate a migração para uma série suportada como prioridade: sem suporte oficial, cada nova falha crítica encontra esses sistemas sem defesa.

Como sei se já fui atacado?

Procure nos logs por requisições multipart/form-data anômalas, processos e arquivos inesperados no servidor web, novas contas e conexões de saída não reconhecidas. Em caso de suspeita, trate como incidente: isole, preserve evidências e investigue antes de só atualizar e seguir em frente.