Falhas críticas de RCE no PHP exigem atualização imediata: CVE-2026-109618 e CVE-2026-109619

A DigitalOcean confirma duas falhas críticas de execução remota de código no PHP, CVE-2026-109618 e CVE-2026-109619, divulgadas em 21 de outubro de 2026. Qualquer uma permite rodar código arbitrário no servidor, com risco de comprometimento total. Há prova de conceito pública e não existe mitigação completa além do patch. As versões corrigidas são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Quem está no PHP 8.1 ou anterior não terá correção oficial e precisa planejar a migração.

O escopo vai além de Droplets. A empresa cita workloads em DOKS, apps do App Platform, containers customizados e imagens Marketplace 1-Click já implantadas (WordPress, LAMP, LEMP, Laravel). Nas imagens de contêiner, a correção é trocar a versão no Dockerfile ou na imagem base, reconstruir e reimplantar. Em distros que empacotam o PHP, o número da versão pode não mudar, então a checagem certa é o changelog do pacote com os dois CVEs. Na família CentOS, Fedora, Rocky e AlmaLinux, os patches ainda estavam em preparação na publicação. Depois de atualizar, é preciso reiniciar PHP-FPM ou Apache, passo que costuma ser esquecido.

Pelo modelo de responsabilidade compartilhada, a DigitalOcean corrige o PHP onde o runtime é dela (App Platform, Cloudways, Functions). Dentro de uma Droplet, o patch é do cliente. A empresa também lembra que corrigir não remove invasão anterior: depois de atualizar, vale investigar sinais de comprometimento.

O assunto evoluiu em poucos dias. Em 21 de outubro de 2026, o CEVIU noticiou "PHP Alerta para Duas Falhas Críticas de Segurança: Patches de Emergência a Caminho", quando os patches ainda eram promessa. Em 22 de outubro de 2026, vieram "PHP lança correções emergenciais para dois zero-days explorados e sites podem sofrer quedas" e "PHP lança atualização de segurança que corrige duas vulnerabilidades críticas", com as correções já publicadas. A matéria de hoje traz o passo operacional: versões exatas, o que a DigitalOcean cobre e o que fica por conta do cliente.

Para quem opera plataforma, isso significa montar um inventário de tudo que roda PHP, inclusive ferramentas internas esquecidas, e priorizar o que está exposto. Em ambientes com contêineres, o rebuild e o redeploy entram no pipeline com urgência. Quem está no PHP 8.1 ou anterior fica sem correção oficial, então a migração deixa de ser dívida técnica e vira prioridade de segurança.