PHP2Shell: o meu site WordPress está em risco e o que fazer

Qualquer site WordPress que funcione com PHP do php.net anterior a 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 está vulnerável à PHP2Shell (os pacotes das distribuições Linux têm números de versão próprios, ver mais abaixo). Estas quatro versões do PHP saíram a 21 de outubro de 2026 e corrigem duas vulnerabilidades críticas que permitem executar código remotamente sem iniciar sessão. A falha está no PHP, por isso atualizar o WordPress, o tema ou os plugins não a elimina. É preciso atualizar o PHP no servidor ou confirmar que o alojamento já o fez.

O aviso de cada uma das quatro versões no php.net contém a mesma frase:

Não existem medidas de mitigação completas, a atualização é a única escolha segura.

(tradução própria, php.net, anúncios das versões de 21 de outubro de 2026)

#O que é a PHP2Shell

A PHP2Shell assenta em dois erros no motor do PHP que, segundo a página dos próprios investigadores, foram descobertos pela Calif, pela OpenAI e pela Wiz. A investigação e a descrição são de Ryan Austin, da Calif, e os erros foram encontrados no âmbito da iniciativa Patch the Planet da OpenAI (Calif). A Wiz Research publicou a sua própria análise (Wiz). O projeto PHP regista-os como duas vulnerabilidades:

Ambas são erros de segurança de memória do tipo use-after-free no tratamento de erros fatais pelo PHP, incluindo erros de falta de memória, e um pedido HTTP manipulado pode desencadeá-los antes de ser executado qualquer código do WordPress. As entradas na base de dados GitHub Security Advisories do repositório php-src foram publicadas a 21 de outubro de 2026, às 13:34 UTC. Indicam como vulneráveis todas as versões inferiores a 8.2.35, 8.3.36, 8.4.27 e 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Segundo a cronologia publicada pela Calif, os investigadores comunicaram o primeiro erro ao projeto PHP a 11 de agosto de 2026, o PHP confirmou a 15 de agosto que a prova de conceito de execução remota de código funcionava, e as versões corrigidas saíram a 21 de outubro de 2026 (Calif).

Na véspera, a 20 de outubro, a equipa de segurança do PHP anunciou o lançamento para 21 de outubro às 14:00 UTC e indicou que ambas as vulnerabilidades têm a classificação 9.2 na escala CVSS v4.0 (php.net, anúncio de 20 de outubro).

Por volta das 15:05, hora de Lisboa (14:05 UTC), o site da Wordfence mostrava apenas uma mensagem: “Os serviços da Wordfence estão temporariamente indisponíveis enquanto implementamos medidas de mitigação para a vulnerabilidade PHP2Shell, que ainda não foi corrigida. Obrigado pela sua paciência.” (tradução própria, site wordfence.com, estado a 21 de outubro de 2026 por volta das 15:05, hora de Lisboa). Quando voltámos a verificar, às 16:16, hora de Lisboa (15:16 UTC), o site continuava a mostrar apenas esta mensagem. Até um fornecedor de segurança para WordPress desligou os próprios serviços durante esse período para implementar proteções.

Da publicação da Wiz Research, três conclusões interessam ao proprietário de um site:

• são vulneráveis as versões do PHP desde a 5.4,
• nos testes da Wiz, a execução remota de código sem autenticação funcionou na imagem de contentor wordpress:latest, e também no Drupal e no Joomla,
• um erro separado permite ler um fragmento da memória do processo PHP, onde podem estar palavras-passe, tokens de autenticação, chaves de API e certificados, mesmo quando a aplicação nem sequer inicia uma sessão (session_start()).

A Wiz assinala ainda que, além dos quatro erros descritos, existem outras variantes do mesmo problema, e que a correção do projeto PHP elimina todas (Wiz).

#O meu site WordPress está vulnerável

Sim, se funcionar com uma versão do PHP inferior à versão corrigida do respetivo ramo. Segundo o php.net, está em risco qualquer instalação de PHP que processe pedidos web: PHP-FPM, Apache com o módulo mod_php, php-cgi, FrankenPHP e LiteSpeed. O php.net atribui o risco mais elevado às configurações com mod_php, para as quais existe um exploit demonstrado que é desencadeado por um pedido sem autenticação, antes de o código da aplicação arrancar (php.net).

A versão do WordPress, do tema e dos plugins não conta aqui, porque o erro está no interpretador PHP e as atualizações automáticas do WordPress não mexem no PHP do servidor. A qualidade do código do site também não protege: segundo a Wiz, até uma aplicação simples do tipo “Hello World” numa versão vulnerável do PHP pode ser alvo de ataque. Um plugin de segurança funciona dentro do WordPress, e o pedido pode desencadear o erro antes de o WordPress carregar.

Uma loja WooCommerce tem mais a perder nesta situação do que um site institucional. Na base de dados e na configuração estão dados de clientes, encomendas e chaves dos gateways de pagamento, e a exposição da memória do processo afeta precisamente este tipo de segredos.

A Calif confirmou a execução remota de código sem autenticação no WordPress 7.1.2 e, entre outras aplicações, também no Magento 2.4.9, no phpMyAdmin 5.2.3 e no WHMCS (Calif). Na nossa avaliação, um phpMyAdmin ou um painel de cliente que corra no PHP do mesmo servidor fica exposto da mesma forma, por isso o servidor precisa da atualização do PHP mesmo que o próprio WordPress não esteja acessível.

Os sites estáticos estão fora do alcance desta falha. Se o site for gerado em ficheiros HTML e o servidor não executar PHP ao processar pedidos, o aviso do php.net não se aplica, porque descreve instalações de PHP que processam pedidos web.

#Como verificar a versão do PHP num site WordPress

O caminho mais simples passa pelo painel do WordPress:

1. Inicie sessão como administrador.
2. Abra Ferramentas, Diagnóstico do site.
3. Passe para o separador Informações e expanda a secção Servidor.
4. Leia a linha da versão do PHP.

Compare o número com a tabela:

As datas de suporte vêm da tabela de versões suportadas no php.net.

A versão do PHP visível no Diagnóstico do site é a que serve o site. O painel do alojamento pode mostrar outra versão para a linha de comandos ou para outro domínio na mesma conta, por isso o que decide é a leitura feita no WordPress.

A exceção são os pacotes das distribuições Linux. Segundo o php.net, as distribuições e os fornecedores de suporte LTS receberam as correções mais cedo e publicam pacotes próprios (php.net). Uma distribuição aplica a correção na sua própria versão do PHP e mantém o seu número. O Ubuntu 24.04 LTS corrigiu o PHP com o pacote 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), por isso um site corrigido num servidor destes continua a mostrar 8.3.6 no Diagnóstico do site. O Debian 13 (trixie) recebeu o php8.4 na versão 8.4.27-1~deb13u1 (DSA-6574-1), enquanto o rastreador de segurança do Debian ainda indicava o php8.2 do Debian 12 (bookworm) como vulnerável quando verificámos, a 21 de outubro de 2026 às 15:14 UTC (Debian security tracker). Num VPS com PHP do repositório da distribuição, o número da versão, por si só, não esclarece a questão. Verifique no aviso de segurança da distribuição ou no registo de alterações do pacote se a atualização inclui as correções para CVE-2026-109618 e CVE-2026-109619 e, num alojamento, pergunte à empresa de alojamento.

#O que fazer se o alojamento ainda não atualizou o PHP

No alojamento partilhado, quem atualiza o PHP é a empresa de alojamento. O proprietário do site tem quatro passos ao seu alcance:

1. Mudar a versão no painel. Muitos painéis de alojamento permitem escolher a versão do PHP por domínio. Se já houver na lista uma versão com correção, mude o site para essa versão e confirme no Diagnóstico do site.
2. Contactar o alojamento. Escreva ao suporte técnico com os números CVE-2026-109618 e CVE-2026-109619 e pergunte quando é que o servidor vai receber o PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou um pacote com estas correções.
3. Cópia de segurança antes da mudança. A passagem para um ramo mais recente do PHP pode desativar um plugin ou tema antigo. Uma cópia dos ficheiros e da base de dados feita antes da mudança encurta o regresso a um site funcional.
4. Desligar o site até à atualização. Se não for possível atualizar o PHP depressa, desligue o site ou mostre no seu lugar uma página estática de manutenção servida sem PHP. Nota nossa: um plugin de modo de manutenção do WordPress não chega, porque o pedido continua a chegar ao PHP. John Mueller, da Google, escreveu a 21 de outubro: “Se está a desligar sites em PHP para ganhar tempo para lidar com atualizações não planeadas, use HTTP 503 em vez de deixar as respostas expirarem ou devolverem 404 ou 500. Pode fazê-lo fora do PHP, apontar o DNS para outro lado ou usar uma CDN.” (tradução própria, John Mueller, Bluesky). A página de manutenção com o código 503 é então servida pelo servidor web, pela CDN ou por outro servidor após uma mudança de DNS, sem PHP, porque uma página de manutenção com o código 200, tempos de espera esgotados, 404 ou 500 podem prejudicar a indexação. A Google Search Central recomenda 503 quando é preciso desativar um site com urgência durante 1 a 2 dias, uma página inicial indexável com o código 200 para uma pausa mais longa, e desaconselha devolver 503 no ficheiro robots.txt (Google Search Central).

O WordPress.org escreveu a 21 de outubro que as falhas não são específicas do WordPress e que não é necessária nem está prevista nenhuma atualização do WordPress (WordPress.org). A mesma publicação aconselha quem gere o próprio servidor com PHP anterior a 8.2 a ponderar desligá-lo enquanto prepara a atualização e remete para o NCSC britânico. O NCSC recomenda ponderar desligar o sistema até estar totalmente protegido, se as medidas temporárias não puderem ser aplicadas com rapidez suficiente (NCSC). O CERT Polska recomendou, ainda antes do lançamento, desligar temporariamente os serviços PHP acessíveis a partir da Internet (CERT Polska, 195/2026) e indica valores próprios para o php.ini no comunicado 196/2026. A Patchstack dá o mesmo conselho para sites de alto risco e alerta contra plugins de “correção” não oficiais e excertos de código copiados, que “não são verificados e podem avariar o seu site” (tradução própria, Patchstack). Um plugin corre dentro do PHP, por isso não consegue corrigir uma falha no próprio PHP.

O php.net descreve definições temporárias de servidor para administradores que não conseguem atualizar o PHP de imediato. Incluem, entre outras, limites de tamanho dos pedidos e a desativação do acompanhamento do progresso de envio de ficheiros na sessão. Estas definições só funcionam ao nível da configuração do servidor: o php.net ressalva que, para a definição de sessão, não basta ini_set() nem um ficheiro .user.ini na pasta do site. O aviso sublinha também que nenhuma destas definições torna a instalação segura:

Embora só uma atualização seja uma solução completa, as medidas seguintes reduzem a exposição a vias de ataque específicas, mas não tornam uma instalação segura.

(tradução própria, php.net, aviso de segurança de 21 de outubro de 2026)

Como medida temporária e parcial, a Calif indica session.upload_progress.enabled=0 em conjunto com memory_limit=-1 para o PHP-FPM e apenas memory_limit=-1 para o mod_php, e avisa que o valor -1 retira o limite de memória do PHP, o que aumenta o risco de a memória se esgotar (Calif).

O php.net recomenda também remover definições de PHP inválidas ou obsoletas aplicadas a cada pedido que gerem mensagens antes da inicialização, e esconder as mensagens com error_reporting, display_errors ou @ não ajuda. Exemplo nosso, não do php.net: desde o PHP 8.3, todas as definições INI assert.* estão obsoletas, por isso, no PHP 8.3 e versões mais recentes, verifique o .htaccess, os pools do FPM e o php.ini à procura de entradas assert.* que tenham ficado, por exemplo php_value assert.active.

Reunimos os pormenores destas definições para o administrador do servidor na secção sobre a versão crítica do PHP no nosso guia de proteção do WordPress.

Se o tráfego do site passa pela Cloudflare (nuvem laranja no registo DNS), existe uma camada adicional. Segundo a Cloudflare, desde as 04:02 de 21 de outubro de 2026, hora de Lisboa (03:02 UTC), os clientes com o WAF gratuito ou pago ficaram protegidos contra a PHP2Shell por predefinição, incluindo o plano Free, e nos planos Pro, Business e Enterprise convém confirmar que o Managed Ruleset está em modo de bloqueio (Cloudflare). A Patchstack ressalva que estas regras só ajudam se o servidor aceitar tráfego exclusivamente da Cloudflare (Patchstack). Se o servidor responder a qualquer pessoa, um pedido enviado diretamente para o seu endereço IP contorna o WAF. A Cloudflare refere ainda que observou tráfego de ataque dirigido aos seus clientes antes do lançamento oficial, depois de a vulnerabilidade ter sido divulgada antecipadamente, e atacantes a alterar o conteúdo dos ataques para contornar as regras. A cronologia da Patchstack regista às 07:34 UTC “vários incidentes de exploração ativa comunicados à Patchstack por parceiros de alojamento” (tradução própria, Patchstack), enquanto a Huntress escreveu que não tinha visto exploração entre os seus parceiros até às 10:00, hora da costa leste dos EUA (14:00 UTC), de 21 de outubro (Huntress). A própria Cloudflare apresenta o WAF como camada adicional de defesa e recomenda atualizar o PHP na mesma, e restringir os carregamentos de ficheiros e o seu tamanho também não substitui a correção.

#Como detetar uma tentativa de ataque nos registos do servidor

A Wiz chama a atenção para o facto de os erros atuarem abaixo da camada da aplicação, pelo que os registos do WordPress podem mostrar pouco. Até à atualização, procure três sinais nos registos do servidor (Wiz):

• pedidos multipart invulgares seguidos de erros por excesso do limite de memória ou de respostas HTTP 500 repetidas,
• cookies PHPSESSID inesperadamente grandes ou malformados nas respostas do servidor,
• reinícios inexplicados dos processos de trabalho do PHP.

Estes sinais indicam por onde começar a verificação. A sua ausência não significa que não houve ataque, e a sua presença não substitui a atualização.

#É preciso mudar as palavras-passe depois da atualização

O aviso do php.net não exige a mudança de palavras-passe. É uma recomendação nossa, com base na conclusão da Wiz: a falha permite ler a memória do processo PHP, onde podem estar palavras-passe, tokens e chaves de API de outros pedidos (Wiz). Um site que funcionou durante algum tempo numa versão vulnerável pode ter exposto um segredo destes sem deixar rasto no painel do WordPress.

Os segredos só se mudam depois da atualização do PHP, porque uma nova palavra-passe definida num servidor sem correção pode ser divulgada pela mesma via que a antiga.

O que mudar:

• As chaves e os salts no wp-config.php. O gerador oficial do WordPress.org cria um novo conjunto das oito constantes. Depois da substituição, todos os utilizadores com sessão iniciada terminam a sessão.
• A palavra-passe da base de dados. Mude-a no painel do alojamento e introduza a nova no wp-config.php como DB_PASSWORD.
• As palavras-passe das contas de administrador e de outras contas com permissões de edição.
• As chaves de API: chaves da REST API do WooCommerce, chaves dos gateways de pagamento, credenciais SMTP e tokens de serviços externos guardados nas definições dos plugins.

#E o PHP 7.4, 8.0 e 8.1

O projeto PHP já não lança correções para o PHP 8.1 e anteriores. O aviso do php.net aponta dois caminhos: algumas distribuições e fornecedores de LTS disponibilizam correções adaptadas, e os restantes devem passar para uma versão suportada. Dada a gravidade das falhas, a equipa de segurança do PHP disponibilizou patches mínimos de código-fonte para o PHP 7.4, 8.0 e 8.1, destinados a quem compila o PHP a partir do código-fonte ou não tem acesso a um fornecedor de LTS (php.net).

Para o proprietário de um site em alojamento partilhado, os patches de código-fonte não mudam nada, porque num servidor deste tipo quem compila e instala o PHP é o alojamento. A escolha real é passar para o PHP 8.3, 8.4 ou 8.5 na versão com correção. O PHP 8.2 também recebeu a correção, mas o seu suporte de segurança termina a 31 de dezembro de 2026 (php.net), por isso escolher a 8.2 significa nova mudança daqui a dois meses.

A tabela de compatibilidade entre versões do WordPress e do PHP está no artigo vale a pena atualizar o WordPress. Se um tema ou plugin antigo impede a passagem para um PHP mais recente, o plano de migração está no guia de modernização de bases de código WordPress legadas. Se uma loja WooCommerce deixou de aceitar encomendas ou mostra erros críticos depois da mudança de versão do PHP, o sprint de recuperação WooCommerce ajuda. A revisão da configuração do servidor, da versão do PHP e das contas depois de um incidente faz parte da auditoria de segurança WordPress.

#Lista de verificação para proprietários de sites WordPress e lojas WooCommerce

Situação a 21 de outubro de 2026, por volta das 17:30 UTC, com base no aviso do php.net, nas entradas do GitHub Security Advisories, nas publicações da Calif e da Wiz Research e nos avisos do Ubuntu, do Debian, do WordPress.org, do NCSC, do CERT Polska, da Patchstack e da Huntress.