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

1. 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.
2. 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.
3. Identificar o que está exposto à internet e priorizar esses sistemas. O que puder sair do ar preventivamente deve sair.
4. Separar o que é fim de vida e decidir agora entre backport, migração ou desligamento.
5. 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