php2shell: com que rapidez as hospedagens fecharam a vulnerabilidade crítica do PHP

Em 20 de outubro, o projeto PHP anunciou para o dia seguinte um lançamento de segurança crítico, às 14:00 UTC. Em 21 de outubro, às 16:00 no horário alemão, o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 estavam disponíveis. O que acontece depois disso já não está nas mãos da maioria de quem administra um site: quem usa hospedagem compartilhada ou WordPress gerenciado fica vulnerável até que a hospedagem leve a atualização para os seus servidores.

Cuidamos de vários sites e aplicações em diferentes hospedagens, nossos e de clientes. Em 27 deles, anotamos naquela noite quando a nova versão chegou. O resultado não é um teste de hospedagens, mas um olhar honesto sobre como o ritmo varia de uma para outra.

O que é o php2shell

Segundo o aviso de segurança do projeto PHP, o nome esconde dois erros no gerenciamento de memória entre duas requisições. No CVE-2026-109618, uma interrupção por falta de memória pode deixar dados num estado pela metade, que o PHP considera válidos ao fazer a limpeza. No CVE-2026-109619, o estado interno de uma requisição permanece depois que a memória dele já foi liberada, e a requisição seguinte, no mesmo processo, acessa esse estado. Ambos recebem CVSS 9.2 e, no pior caso, permitem executar código próprio no servidor.

Todo PHP que atende requisições web é afetado: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior com mod_php. O invasor não precisa de login, e o ataque age antes de o WordPress ou qualquer plugin executar código. Por isso, um plugin de segurança não enxerga nada disso.

Até onde os ataques já chegaram, as fontes avaliam de formas diferentes. O Cyber Centre canadense relatou em 21 e 23 de outubro uma prova de conceito pública, mas nenhuma exploração constatada (alerta AL26-026). Segundo a Help Net Security, a Amazon viu uma tentativa de exploração já em 17 de outubro, quatro dias antes da publicação.

Nossa medição: 27 sistemas, sete hospedagens e um servidor próprio

Medimos de fora e só em leitura. A maioria das hospedagens informa a versão do PHP no cabeçalho de resposta X-Powered-By. Consultamos esse cabeçalho na Hostinger e na STRATO a cada cinco minutos, em wp-login.php, porque essa página nunca vem do cache e o PHP certamente roda nela. Na Raidboxes, a versão constava no relatório do sistema do WooCommerce. A All-Inkl oculta o cabeçalho de resposta; ali, um arquivo de teste de uma linha exibiu a versão e foi apagado logo em seguida. Na united-domains e na CheckDomain não foi possível ler a versão de fora.

Duas ressalvas são necessárias. Medimos as nossas próprias contas, não uma amostra de todos os servidores de uma hospedagem. Grandes provedores costumam distribuir atualizações servidor por servidor, e outros clientes podem ter sido atendidos mais cedo ou mais tarde. E entre 22 e 26 de outubro não medimos a Hostinger, por isso não sabemos quando exatamente chegou a 8.3.36.

O que tiramos disso

A diferença é grande, e você não a vê

Entre a hospedagem mais rápida e a mais lenta da nossa medição passam pelo menos 13 horas, uma noite inteira. De fora, não dá para saber se o servidor de um site já foi corrigido. Quem não confere por conta própria não sabe.

O servidor próprio é tão rápido quanto o seu passo mais lento

No nosso servidor próprio roda uma aplicação em Docker, construída sobre a imagem oficial do PHP. A imagem com o número 8.4.27 saiu às 17:45, a versão para servidores Intel e AMD comuns só às 18:47. Nossa reconstrução rodou às 18:51. Para que ela puxasse a nova imagem base e não reaproveitasse a antiga do cache, tivemos de alterar as instruções de build. Desde então, cada build busca a imagem atual.

O Coolify, a plataforma com a qual administramos esse servidor, publicou a sua atualização com o PHP corrigido apenas doze minutos depois do lançamento. Mesmo assim, para nós ela só chegou com a atualização automática noturna. Fornecedores rápidos de pouco adiantam se a atualização fica parada no seu sistema.

Séries antigas do PHP não recebem mais nada

Um sistema ainda rodava o PHP 8.1. Para o 8.1 e anteriores, o projeto PHP não publica mais versões, só correções mínimas no código-fonte para quem compila o PHP por conta própria. Em hospedagem compartilhada, ali só ajuda migrar para uma série com suporte. Outro sistema já estava, antes do lançamento de segurança, cinco versões atrás, na 8.2.29 em vez da 8.2.34. A boa notícia: o lançamento de segurança o puxou junto, e na nova medição ele rodava a 8.2.35.

Sem PHP, sem vulnerabilidade do PHP

O nosso site principal, hafenstudios.com, não foi afetado, porque consiste em arquivos HTML estáticos. Para um site WordPress isso não é uma opção, mas mostra por que partes que não precisam de PHP também não deveriam executá-lo.

Como verificar a versão do PHP no WordPress

1. No painel: Ferramentas, Diagnóstico, aba Informação, e depois expanda a seção Servidor. Ali aparece a versão do PHP com a qual o WordPress está rodando.
2. Compare com a tabela: sua série está corrigida a partir do número da coluna “Corrigida a partir de”.
3. Leia bem os sufixos: depois do número pode haver uma abreviação da hospedagem, como 8.3.36-nmm1. Vale o número que vem antes.

Uma exceção: algumas distribuições Linux e hospedagens incorporam a correção à sua própria versão sem mudar o número. Se você vê um número mais antigo e a sua hospedagem diz que já corrigiu, não há contradição. Nesse caso vale a informação dela por escrito.

Quem cuida de muitos sites pode, a partir do WordPress 6.9, consultar também pela interface REST, com uma senha de aplicativo e só em leitura: /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run devolve, entre outras informações, a versão do PHP.

Se a sua hospedagem ainda não corrigiu

• Perguntar. Uma frase curta ao suporte basta: quando chega o PHP 8.x.y com a correção do CVE-2026-109618 e do CVE-2026-109619? A resposta também mostra o quanto a sua hospedagem leva o assunto a sério.
• Mudar de série. Muitas hospedagens oferecem várias versões do PHP à escolha. Se outra série já estiver corrigida, você pode mudar para ela depois de um teste rápido. Antes, faça um backup; depois, percorra a página inicial, o login e os formulários.
• Um firewall como ponte. A Cloudflare publicou regras contra os caminhos de ataque conhecidos, inclusive no plano gratuito. O projeto PHP, porém, escreve com clareza que não existe mitigação completa. O firewall não substitui a atualização.
• Em servidores próprios: atualize os pacotes, reconstrua os contêineres com uma imagem base nova e depois reinicie todos os processos do PHP. As configurações com que o projeto PHP permite cobrir o tempo até a atualização estão no aviso de segurança.

Em 23 de outubro saiu um adendo: uma terceira vulnerabilidade, CVE-2026-115560, está no acompanhamento do progresso de uploads em sessões. Ela só age se uma aplicação alterar, em tempo de execução, o formato de armazenamento das suas sessões PHP. O próprio WordPress não usa sessões PHP; só entrariam em questão plugins que o fazem. A correção vem com o próximo lançamento regular e, até lá, o projeto PHP recomenda session.upload_progress.enabled=0. Em hospedagem compartilhada, só a hospedagem pode definir isso.

E, se você já está arrumando a casa: as atualizações do PHP são só metade do trabalho. Por que plugins desatualizados são o problema maior e mais duradouro está no nosso artigo sobre como atualizar plugins do WordPress. O quanto ainda são antigos os requisitos mínimos no diretório de plugins mostra a nossa análise: 8.131 plugins ainda indicam o PHP 5 (em inglês).

Perguntas frequentes