A correção para o PHP2Shell já foi lançada, mas, para a maioria dos sites que precisam dela, não há nenhum botão a apertar. As falhas estão no próprio PHP, o mecanismo que executa todas as páginas de WordPress, Joomla e Drupal, abaixo do CMS, dos plugins e da tela de login. Atualizar o WordPress não resolve o problema. O interpretador corrigido precisa vir de quem administra o servidor: a empresa de hospedagem, o pacote da distribuição Linux ou a imagem do contêiner. Até isso acontecer, o site fica esperando, independentemente do que seu proprietário faça.

Esse é o aspecto da história que as manchetes do tipo “corrija agora” deixam de fora. A equipe do PHP fez a parte dela. Levar esse trabalho a cada servidor depende de uma cadeia de distribuição que avança no ritmo de seu elo mais lento, e o primeiro dia mostrou o quanto esses elos estão distantes uns dos outros. Quem não sabe de onde vem o PHP do próprio site não consegue avaliar o quanto ele ainda está exposto.

Por que atualizar o WordPress não resolve

Como os bugs estão no interpretador, o alerta de segurança do PHP abrange todas as instalações que atendem a solicitações da web, de PHP-FPM e mod_php do Apache a php-cgi, FrankenPHP e LiteSpeed. O The Hacker News observa que até uma página “Hello World” simples, em uma versão vulnerável, pode ser atacada. O pior cenário é o mod_php: uma única solicitação de alguém sem conta pode disparar o ataque antes mesmo de qualquer código da aplicação ser executado. Assim, nenhum plugin de segurança ou tela de login chega a detectá-lo.

A Wordfence, empresa de segurança para WordPress, avisou os proprietários de sites, segundo informou o The Verge, que a correção não pode chegar por meio de atualizações automáticas e que eles precisam descobrir quem é responsável pelo PHP. A Laravel Forge transmitiu o mesmo recado a seus clientes sobre os servidores da plataforma: as atualizações automáticas de segurança não corrigem o PHP, e as atualizações autônomas do Ubuntu buscam pacotes apenas no repositório do próprio Ubuntu, não nos repositórios de terceiros dos quais a Forge instala o PHP.

Essas fontes de pacotes não foram atualizadas ao mesmo tempo. No dia do lançamento, o serviço de gerenciamento de sites mySites.guru informou que o EasyApache 4 da cPanel já tinha versões corrigidas poucos minutos após os alertas, enquanto o PPA de Ondřej Surý — a fonte de pacotes do Ubuntu da qual a própria Laravel Forge depende — e o repositório da Remi ainda não tinham nenhuma. A InMotion Hosting disse que seus servidores compartilhados e de WordPress aguardavam as versões da CloudLinux. Entre os sites ativos monitorados pela mySites.guru, apenas 0,08% informavam uma versão corrigida do PHP às 13h52 UTC.

O número da versão pode enganar

Verificar a correção não é tão simples quanto conferir um número. Ubuntu, Debian e Red Hat aplicam correções de segurança retroativamente, sem alterar a versão original do PHP; por isso, um servidor Ubuntu 24.04 corrigido ainda informa que usa o pacote 8.3.6. O The Hacker News, citando o Debian, recomenda procurar o CVE no registro de alterações do pacote, em vez de confiar no número da versão. A mySites.guru aponta outra armadilha: o binário do PHP que responde ao comando php -v no terminal muitas vezes não é o mesmo que serve as páginas. Portanto, confira a versão informada pelo próprio site.

Depois, é preciso carregar a correção. O alerta do PHP e a Forge enfatizam que é necessário reiniciar o Apache, o PHP-FPM e todos os processos de longa duração. Processos de filas e outros serviços em segundo plano continuam usando o interpretador antigo até serem reiniciados, mesmo que os arquivos corrigidos já estejam no disco.

Quem não recebe uma correção oficial

As versões corrigidas são 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 com nota 9,2 no CVSS v4.0. O projeto PHP não oferece nada para o PHP 8.1 e versões anteriores, além de correções mínimas no 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 cobrem essa lacuna: a InMotion diz que a cPanel adaptou correções para seus pacotes das versões 7.4 a 8.1 e que a CloudLinux está corrigindo todas as versões que distribui, enquanto o CentOS 7 não receberá correção alguma.

Esse grupo de versões antigas não é pequeno. No dia anterior ao lançamento, 22,7% dos sites ativos de Joomla e WordPress monitorados pela mySites.guru usavam PHP 8.1 ou anterior, e 16,6% ainda estavam no PHP 7 ou em versões mais antigas. A empresa atribui parte do problema ao próprio WordPress, que recomenda o PHP 8.3, mas ainda lista a versão 7.4, descontinuada há muito tempo, como compatível. O PHP 8.2 recebeu essa correção, mas seu suporte de segurança termina em 31 de dezembro de 2026.

O que a configuração provisória bloqueia

A solução alternativa que circulou antes do lançamento, definir session.upload_progress.enabled=0, funciona, mas é parcial. O PHP diz que ela bloqueia os caminhos confirmados por sessão que levam à CVE-2026-109619, mas não outras variantes, e precisa ser configurada no php.ini ou na configuração do servidor ou do pool. Depois, é necessário reiniciar todos os processos. No PHP 8.5, fatal_error_backtraces=0 fecha mais um caminho confirmado. Nenhuma das duas medidas afeta a CVE-2026-109618. Para essa falha, o PHP sugere definir um memory_limit=-1 que não possa ser sobrescrito, manter um post_max_size baixo e limitar o tamanho das solicitações no servidor web ou proxy. A formulação usada pelo próprio projeto é que não existem medidas de mitigação completas. A InMotion observa que WordPress, Joomla, Drupal, Magento e PrestaShop não usam o recurso de progresso de upload; portanto, desativá-lo não causa problemas nessas plataformas.

A Cloudflare ativou regras de firewall em todos os planos, uma medida provisória, segundo Dane Knecht, diretor de tecnologia da empresa. Como aponta a mySites.guru, elas só ajudam se o servidor por trás delas bloquear o tráfego que contorna a Cloudflare e acessa diretamente o endereço IP do servidor.

Ataques até agora

A watchTowr diz que seus honeypots registraram tentativas de exploração das duas falhas no dia do lançamento, e a Cloudflare observou atacantes alterando os payloads para escapar de suas regras. Nenhuma fonte confirmou uma invasão bem-sucedida de um servidor específico. Alguns operadores preferiram não correr riscos: o The Hacker News informa que a BambooHR tirou seu serviço do ar e que serviços públicos dos Países Baixos, incluindo o DigiD, ficaram indisponíveis por precaução. A CERT da União Europeia e o National Cyber Security Centre do Reino Unido orientaram organizações que não conseguem aplicar a correção a isolar os aplicativos expostos ou tirá-los do ar.

As falhas foram encontradas pela Wiz Research, por Calif e pela equipe Codex Security da OpenAI. Segundo a PHP Foundation, indícios da falha de memória surgiram em uma auditoria de 2024, mas a correção ficou parada por meses, um atraso que a entidade chamou de “uma falha estrutural”. Os pesquisadores dizem que modelos de IA ajudaram a transformar bugs com uma década de existência em exploits funcionais em cerca de uma semana.

O PHP precisou de uma auditoria, meses de impasse e um vazamento para lançar essa correção. Para um site em hospedagem compartilhada, a última etapa é abrir um chamado de suporte.

Tags: Cloudflare, PHP, PHP2Shell, vulnerabilidades, WordPress