A correção para o PHP2Shell já está disponível, mas, para a maioria dos sites que dela precisam, não há nenhum botão em que possam clicar. As falhas estão no próprio PHP, o motor que faz funcionar todas as páginas de WordPress, Joomla e Drupal, abaixo do CMS, dos respetivos plugins e do ecrã de início de sessão. Atualizar o WordPress não resolve o problema. O interpretador corrigido tem de chegar através de quem gere o servidor: a empresa de alojamento, os pacotes da distribuição Linux ou a imagem do contentor. Até isso acontecer, o site fica à espera, independentemente do que o seu proprietário faça.

É esta a parte da história que os títulos do género «aplique já a correção» deixam de fora. A equipa do PHP fez o seu trabalho. A chegada dessa correção a cada servidor depende de uma cadeia de distribuição que avança à velocidade do seu elo mais lento, e o primeiro dia mostrou a distância que separa esses elos. Quem não sabe de onde vem o PHP do seu site não consegue perceber até que ponto continua exposto.

Porque é que uma atualização do WordPress não resolve o problema

Como os erros estão no interpretador, o aviso de segurança do PHP abrange todas as instalações que recebem pedidos da Web, desde o PHP-FPM e o mod_php do Apache até ao php-cgi, ao FrankenPHP e ao LiteSpeed. O The Hacker News observa que até uma página simples com a mensagem «Hello World», numa versão vulnerável, pode ser atacada. O pior cenário é o do mod_php: um único pedido de alguém sem conta pode desencadear o ataque antes de ser executado qualquer código da aplicação, pelo que nenhum plugin de segurança ou ecrã de início de sessão chega sequer a detetá-lo.

A Wordfence, empresa de segurança para WordPress, informou os proprietários de sites, segundo noticiou o The Verge, de que a correção não pode chegar através das atualizações automáticas e de que precisam de descobrir quem é responsável pelo PHP que utilizam. A Laravel Forge transmitiu a mesma informação aos seus clientes sobre os respetivos servidores: as atualizações automáticas de segurança não corrigem o PHP, e as atualizações automáticas do Ubuntu só instalam pacotes do repositório do próprio Ubuntu, não dos pacotes de terceiros a partir dos quais a Forge instala o PHP.

Essas fontes de pacotes não foram atualizadas em simultâneo. No dia do lançamento, o serviço de gestão de sites mySites.guru informou que o EasyApache 4 da cPanel disponibilizara versões corrigidas poucos minutos depois dos avisos, enquanto a PPA de Ondřej Surý — a fonte de pacotes do Ubuntu de que a própria Laravel Forge depende — e o repositório da Remi ainda não tinham nenhuma. A InMotion Hosting disse que os seus servidores partilhados e de WordPress aguardavam pelas versões da CloudLinux. Entre os sites ativos monitorizados pela mySites.guru, 0,08% indicavam uma versão corrigida do PHP às 13:52 UTC.

O número da versão pode induzir em erro

Verificar se está tudo atualizado não é tão simples como consultar um número. O Ubuntu, o Debian e o Red Hat aplicam correções de segurança a versões anteriores sem alterar a versão original, pelo que um servidor Ubuntu 24.04 corrigido continua a indicar um pacote 8.3.6. O The Hacker News, citando o Debian, recomenda que se procure o CVE no registo de alterações do pacote, em vez de confiar na indicação da versão. A mySites.guru aponta para outra armadilha: o binário do PHP que responde ao comando php -v na linha de comandos muitas vezes não é o que serve as páginas, por isso é preciso verificar a versão indicada pelo próprio site.

Depois, é preciso carregar a correção. Tanto o aviso do PHP como a Forge sublinham que é necessário reiniciar o Apache, o PHP-FPM e todos os processos de longa duração. Os processos de fila e outros processos em segundo plano continuam a usar o interpretador antigo até serem reiniciados, mesmo que os ficheiros corrigidos já estejam no disco.

Quem fica sem uma correção oficial

As versões corrigidas são a PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que resolvem as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas classificadas com 9,2 no CVSS v4.0. O projeto PHP não disponibiliza qualquer correção para a PHP 8.1 e versões anteriores, além de correções mínimas do código-fonte para as versões 7.4, 8.0 e 8.1, destinadas a quem compila o PHP por conta própria. Alguns fornecedores colmatam essa lacuna: a InMotion afirma que a cPanel aplicou correções retroativas aos seus pacotes das versões 7.4 a 8.1 e que a CloudLinux está a corrigir todas as versões que distribui, enquanto o CentOS 7 não recebe qualquer correção.

Este grupo de versões antigas não é pequeno. Na véspera do lançamento, 22,7% dos sites ativos de Joomla e WordPress monitorizados pela mySites.guru usavam a PHP 8.1 ou uma versão anterior, e 16,6% continuavam na PHP 7 ou numa versão ainda mais antiga. A empresa atribui parte do problema ao próprio WordPress, que recomenda a PHP 8.3, mas continua a indicar a já há muito descontinuada 7.4 como compatível. A PHP 8.2 recebeu esta correção, mas o suporte de segurança termina a 31 de dezembro de 2026.

O que bloqueia a configuração provisória

A solução temporária que circulou antes do lançamento — definir session.upload_progress.enabled=0 — é válida, mas apenas em parte. O PHP afirma que bloqueia os caminhos confirmados através de sessões que levam à CVE-2026-109619, mas não outras variantes, e que tem de ser definida no php.ini ou na configuração do servidor ou do conjunto de processos, seguindo-se o reinício de todos os processos. Na PHP 8.5, a opção fatal_error_backtraces=0 fecha mais um caminho confirmado. Nenhuma das duas resolve a CVE-2026-109618, para a qual o PHP sugere um memory_limit=-1 que não possa ser substituído, um valor baixo para post_max_size e limites ao tamanho dos pedidos no servidor Web ou no proxy. A formulação do próprio PHP é clara: não existem medidas de mitigação completas. A InMotion observa que o WordPress, o Joomla, o Drupal, o Magento e o PrestaShop não usam o progresso dos carregamentos, pelo que desativá-lo não causa qualquer problema nesses sistemas.

A Cloudflare ativou regras de firewall em todos os planos, uma medida que o seu diretor de tecnologia, Dane Knecht, descreveu como provisória. Como salienta a mySites.guru, estas regras só ajudam se o servidor por detrás delas recusar o tráfego que contorna a Cloudflare e se liga diretamente ao respetivo endereço IP.

Ataques até ao momento

A watchTowr afirma que os seus honeypots registaram tentativas de exploração de ambas as falhas no dia do lançamento, e a Cloudflare detetou atacantes a alterar as cargas úteis para contornar as suas regras. Nenhuma fonte confirmou uma intrusão bem-sucedida num servidor específico. Alguns operadores preferiram não correr riscos: o The Hacker News noticia que a BambooHR retirou o seu serviço do ar e que serviços públicos neerlandeses, incluindo o DigiD, ficaram indisponíveis por precaução. A CERT da UE e o Centro Nacional de Cibersegurança do Reino Unido recomendaram às organizações que não conseguem aplicar a correção que isolassem as aplicações expostas ou as retirassem do ar.

As falhas foram descobertas pela Wiz Research, por Calif e pela equipa Codex Security da OpenAI. Segundo a PHP Foundation, os primeiros indícios da falha de memória surgiram numa auditoria de 2024, mas a correção ficou bloqueada durante meses, um atraso que a fundação descreveu como «uma falha estrutural». Os investigadores afirmam que os modelos de IA ajudaram a transformar erros com uma década em explorações funcionais no espaço de cerca de uma semana.

Para disponibilizar esta correção, o PHP precisou de uma auditoria, de meses de impasse e de uma fuga. Para um site em alojamento partilhado, o último passo é abrir um pedido de assistência.

Etiquetas: Cloudflare, PHP, PHP2Shell, vulnerabilidades, WordPress