Falhas críticas no PHP: correção de emergência sai hoje

O time de segurança do PHP marcou para hoje, 21 de outubro de 2026, às 14h UTC — 11h de Brasília, o lançamento de uma atualização de emergência que corrige duas vulnerabilidades críticas no núcleo da linguagem. Ambas receberam nota 9,2 na escala CVSS v4.0. É a primeira vez em anos que o projeto publica um aviso prévio desse tipo, pedindo que administradores se preparem antes de o código sair.

O aviso foi enviado por Jakub Zelenka à lista oficial php.announce em 20 de outubro, às 19h33 UTC, e replicado na página inicial do php.net. O texto é deliberadamente econômico: informa a data, a quantidade de falhas e a gravidade, e nada mais. Detalhes técnicos, versões afetadas e versões corrigidas só serão publicados junto com a correção. O projeto reserva-se o direito de antecipar o lançamento caso os detalhes se tornem públicos ou apareça evidência de exploração ativa.

Esse último parágrafo deixou de ser hipótese no mesmo dia. Informações sob embargo vazaram antes do prazo, e é por isso que esta matéria existe agora, e não depois da correção: quem opera aplicações PHP expostas à internet tem poucas horas para se organizar.

Falhas críticas no PHP: o que é oficial

Até a publicação deste texto, o que está confirmado pelo próprio projeto PHP é apenas isto:

lançamento de segurança em 21 de outubro de 2026, 14h UTC (11h em Brasília, 16h CEST, 10h EDT);
duas vulnerabilidades, ambas classificadas como críticas, com CVSS v4.0 9,2;
versões afetadas e corrigidas serão divulgadas no momento do lançamento;
o lançamento pode ser antecipado se houver divulgação pública ou ataques.

O php.net não publicou identificadores CVE, não descreveu o componente afetado e não confirmou quais ramos recebem correção. Qualquer informação além desses quatro pontos vem de terceiros e deve ser tratada como tal.

O vazamento e quem confirmou

A cronologia reunida por empresas de segurança começa em 20 de outubro, por volta das 15h20 UTC, quando uma publicação no Hacker News — depois removida, mas preservada em capturas de tela — anunciou a divulgação iminente de duas falhas de execução remota de código no PHP. O embargo original, segundo a watchTowr, terminaria apenas na quinta-feira, 22 de outubro, às 11h no horário do leste dos Estados Unidos.

A watchTowr foi a primeira empresa a se manifestar publicamente. Benjamin Harris, presidente-executivo da companhia, afirmou que as informações haviam vazado e que as falhas são reais; a empresa diz acreditar ter reproduzido uma delas, mas não divulga detalhes técnicos até que a correção esteja disponível. É dessa confirmação que vêm os identificadores CVE-2026-109618 e CVE-2026-109619, hoje repetidos em várias coberturas — e ainda assim não confirmados pelo php.net. No momento desta publicação, os registros correspondentes não estão públicos nas bases do NVD e do MITRE.

Há também uma divergência de gravidade que vale registrar: enquanto o time do PHP atribui 9,2 pelo CVSS v4.0, a publicação vazada e a watchTowr descrevem as falhas como nota 10,0. Não há, até agora, cálculo publicado que explique a diferença.

Segundo a Sansec, junto do material vazado circulou a captura de tela de uma ferramenta de exploração batizada de PHP2Shell, creditada à Calif.IO, cujo banner afirma funcionar contra toda versão do PHP a partir da 5.4.0. O apelido pegou e hoje é como pesquisadores se referem ao conjunto. A Huntress, que também publicou análise preliminar, relata que um vídeo curto de exploração chegou a ser publicado e removido em seguida.

O alerta que mais circulou entre profissionais partiu de Andrew Case, pesquisador conhecido pelo trabalho em forense de memória e pelo projeto Volatility. A recomendação dele é direta: ter tudo pronto para aplicar a correção no minuto em que ela sair ou, alternativamente, considerar seriamente tirar a aplicação do ar até que isso seja possível.

O que ainda não se sabe

Esta é a parte que o leitor precisa levar a sério antes de tomar decisões:

Qual componente é vulnerável. As descrições públicas dizem “núcleo do PHP”, o que é vago. Não se sabe se a falha é alcançável por uma requisição web comum ou se exige configuração específica.
Quais versões são afetadas. A watchTowr acredita que PHP 5, 6, 7 e 8 estejam no escopo; a Sansec fala em todo servidor com PHP 5.4 ou superior. São estimativas baseadas no material vazado, não no aviso oficial.
Quais versões corrigidas serão publicadas. Circulam números específicos, de fonte única, que este texto não reproduz justamente por não haver confirmação.
Se há exploração em andamento. Até 20 de outubro, a Huntress informou não ter observado exploração na base de clientes, e a watchTowr também não relatou ataques. Isso pode mudar rapidamente.

Quem fica sem correção oficial

O PHP mantém suporte de segurança apenas para os ramos 8.2 e superiores — hoje nas versões 8.5.11, 8.4.26, 8.3.35 e 8.2.34. Quem roda PHP 8.1 ou anterior, incluindo os ainda numerosos servidores em PHP 7, não receberá correção oficial.

Para esses casos restam três caminhos, nenhum confortável: verificar se a distribuição Linux ou o provedor de hospedagem oferece backport da correção; migrar para um ramo suportado; ou retirar a aplicação do acesso público, colocando-a atrás de VPN enquanto a migração não acontece.

Vale lembrar que o PHP aparece em muito mais lugares do que o inventário costuma registrar: painéis de controle como cPanel e Plesk, imagens de contêiner, pipelines de integração contínua, appliances de fornecedores e, claro, a base de WordPress, Drupal, Joomla, Magento, Shopware e WooCommerce. A Sansec, que acompanha o ecossistema de comércio eletrônico, estima que ataques em massa comecem em até 15 minutos após a liberação — e avisa que mitigação em nível de aplicação tende a ser inútil, porque o ataque atinge o PHP antes de o código da loja ser executado.

O que fazer nas próximas horas

Inventariar onde o PHP roda: servidores web, contêineres, imagens de CI, appliances e estações de desenvolvimento. Anotar a versão de cada um.
Definir quem aplica a atualização. Em hospedagem gerenciada ou compartilhada, pergunte hoje ao provedor quando ele pretende aplicar. Em servidores próprios, reserve janela de manutenção logo após as 11h.
Identificar o que está exposto à internet e priorizar esses sistemas. O que puder sair do ar preventivamente deve sair.
Separar o que é fim de vida e decidir agora entre backport, migração ou desligamento.
Acompanhar a fonte primária, o anúncio no php.net, em vez de agir a partir de números que circulam em redes sociais.

Detecção enquanto a correção não chega

Como o vetor exato ainda não é público, não há regra específica a aplicar. O que existe é vigilância sobre o comportamento esperado de uma exploração de execução remota em PHP. A orientação publicada pela Huntress, assinada por John Hammond, é monitorar processos filhos inesperados criados por trabalhadores do PHP — php-fpm, php-cgi, httpd, apache2:

interpretadores e shells iniciados por esses processos (sh, bash, cmd.exe, powershell.exe, python, perl);
ferramentas de download e rede, como curl, wget, nc e certutil.exe;
padrões de shell reverso nas linhas de comando, como /dev/tcp/, fsockopen e mkfifo;
comandos de reconhecimento executados a partir do servidor web, como whoami, id, uname -a e ipconfig.

Vale também garantir desde já a retenção de logs do servidor web e do PHP. Se houver suspeita de comprometimento depois, serão eles a única fonte de reconstrução — e procurar por web shells, arquivos novos na raiz web, tarefas agendadas inéditas e contas recém-criadas será o primeiro passo.

Conclusão

O caso tem dois lados que não devem ser confundidos. O lado técnico ainda é desconhecido: ninguém fora do embargo sabe qual é a falha, e tratar estimativas de terceiros como fato seria repetir o erro que o vazamento já provocou. O lado operacional, esse sim, é acionável agora — inventário, responsabilidade pela atualização e decisão sobre o que fica exposto nas próximas horas.

A dinâmica lembra o que se viu em outros episódios recentes de falha crítica em plataformas de larga escala, como a falha no núcleo do WordPress batizada de wp2shell: janela curta entre divulgação e exploração em massa, e vantagem decisiva para quem já tinha inventário pronto. A diferença aqui é a amplitude — o PHP está abaixo de boa parte da web.

O que observar a seguir: o anúncio oficial das 14h UTC, com CVEs, componente afetado e versões corrigidas; a confirmação ou não do alcance a ramos fora de suporte; e os primeiros relatos de exploração. Esta matéria será atualizada após a publicação da correção.

Fontes e referências

PHP — [ANNOUNCE] Upcoming Critical PHP Security Release (Jakub Zelenka, 20 de outubro de 2026) e aviso na página inicial do php.net
BleepingComputer — PHP warns admins of two critical flaws, emergency patches coming tomorrow
Huntress — Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
Sansec — Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
Help Net Security — A critical PHP security release is coming today, so get ready to update!
Andrew Case (@attrc) — alerta publicado em 20 de outubro de 2026