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 voltei 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.

O centro estatal de TIC da Finlândia, Valtori, começou a desligar por precaução serviços web públicos da administração central pouco depois das 13:00, hora da Finlândia, de 21 de outubro, e o site do serviço finlandês de cadastro e cartografia, Maanmittauslaitos, já estava em baixo às 15:11 (Yle News). A Universidade de Friburgo anunciou às 10:39, hora local, que os seus sites e serviços principais iam ficar indisponíveis (centro de informática da Universidade de Friburgo).

Nos Países Baixos, a NOS noticiou às 11:10 CEST que a Tweede Kamer, o NCSC, a Autoriteit Persoonsgegevens e o Tweakers tinham desligado os seus sites, e que o NotuBiz, o sistema que cerca de cem municípios usam para as reuniões das assembleias municipais, tinha ficado indisponível nessa manhã (NOS). O site da Universidade de Viena e a wiki explain xkcd também estiveram temporariamente indisponíveis (ORF, explain xkcd). A W3Techs contabiliza o PHP em 69,3% dos sites cuja linguagem do lado do servidor conhece (dados de 23 de outubro de 2026). Por isso, um único erro no interpretador levou tantas organizações a desligar os sites ao mesmo tempo (W3Techs).

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 Automattic escreveu a 21 de outubro de 2026 que os sites alojados no WordPress.com, WordPress VIP, WP Cloud, Pressable e Tumblr já estão protegidos e que os proprietários não precisam de fazer nada (Automattic), pelo que a atualização diz respeito aos sites em que o PHP é gerido pelo próprio dono ou por outro alojamento.

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 minha 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). Se utiliza o repositório rpms.remirepo.net, mantido por voluntários, o php.net insta a mudar para os pacotes da distribuição ou a compilar a partir do código-fonte, para poder aplicar as atualizações de imediato, e avisou que o repositório não teria atualizações no dia do lançamento (php.net, 21 de outubro de 2026). 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 verifiquei, 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 minha: 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).

Os advisories do projeto PHP associam cada medida provisória a uma falha concreta. Para a CVE-2026-109618, definir e impor memory_limit=-1 é a principal mitigação na configuração. O advisory diz que não é completa, porque uma alocação de memória falhada ainda pode levar o PHP pelo caminho vulnerável, e desaconselha RLIMIT_AS e RLIMIT_DATA, que acionam precisamente esse caminho. Recomenda ainda um post_max_size contido, imposto também no servidor que está à frente do PHP, limites ao número de partes multipart, cabeçalhos e carregamentos, e o bloqueio aí dos pedidos multipart se a aplicação não os usar. Com a correção, o PHP lança um erro brando de falta de memória num ponto seguro e só termina o processo quando o consumo atinge um segundo limiar, mais alto (GHSA-w8hw-w9fx-j79w). A definição session.upload_progress.enabled=0 vem do advisory da CVE-2026-109619, que indica que cobre apenas o caminho no ciclo de vida da sessão ali demonstrado e não os restantes (GHSA-6wmf-4rv5-p3rp). Nota minha: o WordPress usa pedidos multipart para carregar ficheiros na biblioteca de multimédia e em muitos formulários, por isso bloqueá-los por completo estraga o painel e os formulários. Essa opção só serve sites que não recebem ficheiros.

Para a CVE-2026-109619 no PHP 8.5, o php.net indica ainda fatal_error_backtraces=0 com o reinício de todos os processos de trabalho, e diz que isto bloqueia apenas o caminho confirmado através do backtrace de erros fatais (php.net, 21 de outubro de 2026). O mesmo aviso recomenda 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 meu, 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.

Atualização de 24 de outubro de 2026. As versões de 21 de outubro não fecham todos os caminhos. A 23 de outubro, o php.net publicou um aviso informativo sobre mais um vetor de execução remota de código, a CVE-2026-115560. O projeto PHP considera-o pouco provável na prática, vai corrigi-lo na próxima versão regular de correção de erros e só então publicará o aviso completo. Abrange, portanto, também servidores já atualizados, mas exige três condições em simultâneo: a configuração define session.serialize_handler como php_binary ou php_serialize, a aplicação muda-o para php em tempo de execução com ini_set() antes de chamar session_start(), e o acompanhamento do progresso de carregamento na sessão continua ativo. As aplicações que nunca alteram o serializador em tempo de execução podem manter a funcionalidade ativa. Até essa versão, o php.net sugere session.upload_progress.enabled=0. Se já aplicou esta definição a 21 de outubro como mitigação da CVE-2026-109619, mantenha-a, e não precisa de fazer mais nada (php.net, 23 de outubro de 2026). A forma de a aplicar consta do aviso de 21 de outubro: no php.ini, num pool do FPM ou na configuração do servidor, não através de ini_set() nem de .user.ini, seguida do reinício de todos os processos de trabalho. Num alojamento partilhado, trata-se portanto de um pedido à empresa de alojamento. Nota minha: para saber se algum código no seu servidor muda o serializador, procure session.serialize_handler nos plugins, temas e código próprio, por exemplo com grep -rn "session.serialize_handler" wp-content/.

Reuni os pormenores destas definições para o administrador do servidor na secção sobre a versão crítica do PHP no meu 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.

Atualização de 23 de outubro de 2026. Um dia depois das correções, a Wordfence escreveu que não tinha observado nenhum comprometimento confirmado através destas duas vulnerabilidades nos mais de cinco milhões de sites WordPress que protege, enquanto a firewall da empresa tinha intercetado mais de 74 000 tentativas de ataque e de sondagem. Numa amostra de pedidos de 20 a 22 de outubro, que a própria Wordfence diz não ser representativa de todo o tráfego, os pedidos tentam ler .env e wp-config.php, executar comandos como id e uname -a e gravar uma shell PHP chamada wp2s.php em pastas graváveis de carregamentos, plugins ou temas. Mostram intenção, não ataques bem-sucedidos. A Wordfence acrescenta que a ausência de comprometimentos confirmados nos dados da empresa não torna seguro um servidor por atualizar, porque algumas falhas ocorrem fora do WordPress e dos respetivos registos (Wordfence, 22 de outubro de 2026). Nos servidores Debian e Ubuntu que instalam o PHP a partir do repositório deb.sury.org, os pacotes são preparados por Ondřej Surý, programador do Debian em cujo trabalho se baseiam os pacotes PHP oficiais do Debian e do Ubuntu. Ele escreve que faz este trabalho sobretudo nas horas livres (deb.sury.org). Quando verifiquei a 23 de outubro, o repositório para o Debian 12 já tinha as versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12, compiladas a 21 de outubro (packages.sury.org). Isto vale para qualquer aplicação em PHP, seja uma loja, um CRM ou outro CMS: confirme quem compila os pacotes PHP do seu servidor e se o ramo de versões em uso ainda recebe correções, compare a versão instalada com a versão corrigida e reinicie todos os processos PHP depois da atualização. Acompanhar isto nos servidores dos clientes faz parte da minha manutenção de sites WordPress.

#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.

Atualização, 28 de outubro de 2026. Uma semana depois das correções, a Wordfence continua a não conhecer nenhum site WordPress comprometido através do PHP2Shell, e a sua equipa de limpeza de sites não tratou nenhum caso desses. As tentativas continuam: uma regra de monitorização própria registou entre 23 e 27 de outubro cerca de 77 600 pedidos relacionados, vindos de mais de 2000 endereços IP, e nenhum parecia tráfego normal de visitantes. As ferramentas feitas para estas falhas surgiram nos dados da Wordfence a 21 de outubro, cerca de quatro horas antes do anúncio público. No laboratório da Wordfence, um exploit de teste executou código numa compilação de PHP configurada de propósito, mas numa compilação normal e otimizada da mesma versão apenas fez o processo falhar. O exploit tem de ser adaptado a cada servidor, o que abranda os ataques em massa e não corrige nada (Wordfence, 28 de outubro de 2026). Num servidor próprio, verifique duas coisas. find wp-content -name "*.php" -newermt 2026-10-17 lista os ficheiros PHP criados ou alterados desde 17 de outubro, e em wp-content/uploads não deve haver nenhum. cat /proc/sys/kernel/randomize_va_space deve devolver 2, ou seja, aleatorização completa do espaço de endereços (ASLR). Guarde os registos do servidor web, do PHP e da firewall desde 17 de outubro até ao dia em que o PHP foi atualizado e reiniciado. Se encontrar um ficheiro que não colocou ou uma conta de administrador que não reconhece, trate o site como comprometido: primeiro uma cópia do estado atual como prova, depois uma nova palavra-passe da base de dados e novas chaves no wp-config.php. Se houver dados pessoais afetados, o artigo 33.º do RGPD dá 72 horas para notificar a CNPD. É assim que trabalho na remoção de malware em WordPress.

#É 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 minha, 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.

Atualização de 27 de outubro de 2026. Na passagem para um ramo mais recente do PHP há uma avaria com um aspeto especialmente estranho: em vez da página, o navegador descarrega um ficheiro, normalmente index.php. O servidor deixou de entregar os ficheiros .php ao interpretador e envia-os como ficheiros comuns. No Apache, a causa costuma ser uma linha AddHandler no .htaccess que associa .php ao handler de uma versão do PHP que o alojamento removeu (Apache, mod_mime). Um comando confirma o diagnóstico: curl -sI https://example.com/ devolve Content-Type: application/octet-stream em vez de text/html. A correção é escolher uma versão suportada no painel do alojamento e apagar a linha AddHandler antiga, não repor uma cópia de segurança. O que a maioria dos guias omite: enquanto o PHP não corre, qualquer ficheiro .php pode ser descarregado como código-fonte, incluindo o wp-config.php com a palavra-passe da base de dados e as chaves. Se a avaria durou mais do que um instante, verifique depois no registo de acessos se alguém pediu esse ficheiro (grep "wp-config.php" access.log). Se encontrar pedidos, ou se não tiver registo, altere a palavra-passe do utilizador da base de dados e gere novas chaves e salts (gerador do WordPress.org). Os novos salts terminam a sessão de todos os utilizadores, que é o que se pretende aqui. Faço a mudança de versão do PHP com esta verificação no âmbito da manutenção de sites WordPress.

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

Situação a 22 de outubro de 2026, por volta das 08:00 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 Automattic, da Patchstack e da Huntress. O aviso informativo do php.net de 23 de outubro (CVE-2026-115560) foi acrescentado a 24 de outubro de 2026.