PHP agenda correções urgentes para duas falhas críticas: o que fazer

Principais pontos

• A equipe de segurança do PHP agendou uma versão de segurança fora do ciclo para quarta-feira, 21 de outubro de 2026, às 14h UTC, para corrigir duas vulnerabilidades, cada uma com nota 9.2 (Crítica) na escala CVSS v4.0.
• O PHP diz que pode liberar as correções antes se os detalhes técnicos se tornarem públicos ou se houver evidência de exploração ativa. As versões afetadas e corrigidas só serão informadas quando a versão for publicada.
• O CERT-EU identifica as falhas como CVE-2026-109618 e CVE-2026-109619 e afirma que elas podem levar à execução remota de código. Nenhum detalhe técnico foi divulgado oficialmente.
• Pesquisadores associaram pelo menos uma das falhas ao recurso session.upload_progress do PHP, que vem ativado por padrão. O PHP não confirmou isso, e desativar essa configuração é uma medida paliativa não oficial que pode não cobrir as duas falhas.
• Atualmente, apenas o PHP 8.2, 8.3, 8.4 e 8.5 recebem correções de segurança. Servidores em ramificações mais antigas não devem receber patches oficiais.

O que o projeto PHP anunciou

Na terça-feira, 20 de outubro de 2026, às 19h33 UTC, o gerente de versões do PHP Jakub Zelenka publicou um aviso na lista de e-mails oficial do projeto, a php.announce, com o título "Upcoming Critical PHP Security Release". O aviso diz que a versão tratará de "duas vulnerabilidades críticas (ambas com CVSS v4.0 9.2, Crítica)" e marca o lançamento para as 14h UTC de quarta-feira, 21 de outubro de 2026.

O anúncio é curto. Não cita as ramificações afetadas, os componentes vulneráveis nem qualquer solução alternativa. Pede que os usuários se preparem desde já para atualizar assim que a versão estiver disponível e observa que a equipe se reserva o direito de publicá-la antes se os detalhes vazarem ainda mais ou se atacantes começarem a explorar as falhas. O mesmo aviso prévio aparece na página inicial do php.net, que informa que as versões afetadas e corrigidas serão listadas com o lançamento.

Anunciar uma versão de segurança com antecedência é incomum para o PHP. Suas atualizações de segurança regulares costumam sair com pouca divulgação prévia. As mais recentes chegaram em 24 de setembro de 2026, como PHP 8.5.11, 8.4.26, 8.3.35 e 8.2.34. Um aviso separado, com horário definido, indica que os mantenedores esperam uma resposta rápida e ampla dos operadores de servidores.

Por que o alerta veio antes

Segundo as cronologias publicadas pelas empresas de segurança Sansec e Huntress, uma postagem no fórum Hacker News por volta das 15h20 UTC de 20 de outubro descreveu duas divulgações futuras de execução remota de código no PHP. A postagem foi removida depois, mas capturas de tela circularam. Huntress e Sansec relatam que a empresa de segurança watchTowr confirmou que as falhas eram reais, e a Huntress diz que a watchTowr reproduziu uma delas, a CVE-2026-109618. A Sansec relata que a data agendada ficou um dia antes do planejado originalmente.

O serviço de cibersegurança da UE para suas instituições, o CERT-EU, emitiu o Security Advisory 2026-018 sobre as duas CVEs. O órgão afirma que elas "podem levar à execução remota de código" e que as notas indicam possível exploração sem autenticação. O CERT-EU acrescenta que ainda não há detalhes técnicos públicos.

Quais versões e recursos podem ser afetados

Esta é a maior questão em aberto, e a resposta oficial só virá com o lançamento. O que as fontes dizem até agora:

• PHP (oficial): as versões afetadas e corrigidas serão publicadas com o lançamento.
• CERT-EU: citando outra fonte, diz que as falhas podem afetar todas as versões do PHP a partir do PHP 5.
• Sansec: diz que uma captura de tela vazada de uma ferramenta de exploração chamada "PHP2Shell" alega funcionar contra todas as versões a partir do PHP 5.4.0. Essa alegação vem do próprio banner da ferramenta e não foi verificada de forma independente.
• Huntress: diz que os relatos apontam para o PHP 5 ao 8, mas que nenhuma causa raiz foi publicada. A empresa espera correções apenas para as ramificações do PHP 8 com suporte.

Sobre o componente específico, o site japonês de notícias de segurança Lilting reuniu análises de pesquisadores que associam pelo menos uma das falhas ao manipulador do session.upload_progress, descrita como um heap use-after-free. Trata-se de um tipo de bug de corrupção de memória em que um programa continua usando a memória depois de liberá-la. Um pesquisador independente localiza o bug na função php_session_rfc1867_callback e diz que a segunda falha fica em outro lugar, no analisador de requisições multipart. A GMO Flatt Security, também citada pelo Lilting, alerta que sua própria análise pode conter imprecisões. Nenhuma dessas atribuições foi confirmada pelo projeto PHP ou pelo CERT-EU, e os leitores devem tratá-las como provisórias.

O recurso de progresso de upload da sessão permite que o PHP registre quanto de um upload de arquivo já chegou, para que uma página web possa exibir uma barra de progresso. Segundo o manual do PHP, session.upload_progress.enabled tem valor padrão "1" (ativado) e pode ser alterado por diretório (INI_PERDIR). Isso significa que ele não pode ser desligado de dentro de uma aplicação com ini_set().

Os números: ramificações do PHP e exposição

Os números da W3Techs importam porque cerca de um terço dos sites com PHP em seu levantamento roda PHP 7 ou PHP 5. Essas ramificações deixaram de receber correções oficiais há anos. Se as falhas de fato alcançarem versões tão antigas, esses sites não receberão um patch do projeto PHP.

O que os administradores de servidores devem fazer agora

A única correção oficial é instalar a versão corrigida do PHP assim que for publicada. Até lá, as orientações do PHP, do CERT-EU, da Huntress e da Sansec se resumem aos passos a seguir.

1. Faça um inventário de todas as instalações do PHP. A Huntress ressalta que o PHP costuma vir embutido em appliances de fornecedores, painéis de controle de hospedagem e pacotes de CMS, e não apenas instalado como pacote independente.
2. Prepare-se para corrigir primeiro os sistemas expostos à internet. Acompanhe a página inicial do php.net e a lista php.announce para saber os números das versões corrigidas. Se você depende de pacotes de uma distribuição Linux, verifique o rastreador de segurança da sua distribuição, porque correções retroportadas podem ter números de versão diferentes.
3. Fale com sua hospedagem. A Sansec observa que a correção é feita no nível do servidor e não pode ser aplicada pelo código da aplicação, então donos de lojas em Magento, Shopware ou WooCommerce que não administram os próprios servidores devem pedir ao provedor que aplique a atualização assim que ela sair.
4. Resolva o PHP sem suporte. A Huntress recomenda atualizar, tirar do ar ou restringir por trás de uma VPN ou de um firewall de aplicações web qualquer servidor com PHP 5, 7, 8.0 ou 8.1. O CERT-EU recomenda isolar aplicações expostas à internet se a correção não puder ser feita rapidamente.
5. Avalie com cuidado a medida paliativa não oficial. Vários pesquisadores sugerem definir session.upload_progress.enabled = 0 no php.ini, no .user.ini ou na configuração do servidor web. Os uploads de arquivos continuam funcionando; apenas o acompanhamento do progresso para. Isso não é uma orientação do PHP, e pelo menos um pesquisador afirma que bloqueia apenas uma das duas falhas.
6. Fique atento a sinais de comprometimento. A Huntress cita o pesquisador de detecção Florian Roth, que espera que a exploração apareça como "processos filhos suspeitos criados pelo PHP". Ou seja, workers do PHP, como php-fpm ou apache2, iniciando shells ou ferramentas de download. Se houver suspeita de invasão, isole o servidor e preserve os logs da web e do PHP antes de fazer a limpeza.

O que ainda não se sabe

Até as informações públicas mais recentes antes do lançamento agendado, o PHP não havia publicado as versões afetadas, a causa raiz nem qualquer solução alternativa oficial. A Huntress disse que não havia observado exploração real nos ambientes de seus parceiros até 20 de outubro, e nenhum código de exploração público era conhecido. A Sansec espera que ataques em massa comecem cerca de 15 minutos após o lançamento, uma estimativa e não uma observação. Também não foi confirmado se as falhas podem ser acionadas sem autenticação nem em quais configurações de servidor (mod_php, PHP-FPM, CGI).

O que significa

O PHP é a linguagem de servidor por trás da maior parte da web, incluindo plataformas de gestão de conteúdo e de comércio eletrônico amplamente usadas, por isso uma falha explorável remotamente no próprio PHP pode ter um alcance enorme. Diferentemente de um bug em plugin, ela não pode ser corrigida com a atualização de uma única aplicação. Cada servidor precisa ser atualizado no nível do runtime. O aviso prévio dá aos operadores uma janela estreita para organizar a manutenção e contatar os provedores de hospedagem. O maior risco de longo prazo está no grande número de sites que ainda usam versões do PHP sem suporte, que podem continuar expostos depois de hoje se não forem atualizados ou protegidos. Os administradores devem tratar as notas oficiais de lançamento do PHP, e não vazamentos ou alegações em redes sociais, como a referência oficial sobre o que é afetado e o que foi corrigido.

Fontes

• PHP php.announce #509: Upcoming Critical PHP Security Release (20 Oct 2026)
• PHP.net front page: news and security announcements
• PHP.net: Supported versions
• PHP manual: Session runtime configuration
• PHP manual: Session upload progress
• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Huntress: Rapid Response, php2shell leaked critical PHP vulnerabilities
• Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619
• Lilting: Disabling session.upload_progress before the php2shell patch lands
• W3Techs: Usage statistics of PHP for websites