PHP2Shell: a falha crítica do PHP e o que fazer no seu site
PHP2Shell: falha crítica no PHP põe milhões de sites em risco. Que versão instalar, como saber se o site está afectado e o que pedir ao alojamento esta semana.

A 21 de Outubro de 2026, a equipa do PHP publicou correcções de emergência para duas falhas críticas que permitem a um atacante, sem qualquer login, correr código no servidor de um site. Ficaram conhecidas como PHP2Shell. O PHP está por trás de cerca de 70% dos sites do mundo, segundo estimativas citadas pela Associated Press, incluindo quase todos os sites em WordPress, as lojas em WooCommerce e PrestaShop e muitas áreas de cliente feitas à medida.
Se a sua empresa tem um site, é muito provável que esta notícia lhe diga respeito. Explicamos o que aconteceu, como saber se está afectado e o que fazer esta semana.
Prefere ver? Explicamos a falha e o que fazer em quatro minutos neste vídeo:
O que aconteceu
Segundo o aviso de segurança do PHP, há duas falhas, ambas com nota 9,2 em 10 (CVSS 4.0):
- CVE-2026-109618: quando o PHP fica sem memória a meio de um pedido, deixa dados internos meio preparados, que a limpeza do pedido depois trata como válidos. Um pedido preparado para isso pode levar à execução de código.
- CVE-2026-109619: restos de um pedido anterior ficam a apontar para memória já libertada, e um pedido seguinte no mesmo processo pode usá-los. Também aqui o resultado pode ser a execução de código, ou a fuga de dados da memória.
Em termos práticos, quem explorar a falha passa a correr comandos no servidor com as permissões do site: pode ler a base de dados, roubar dados de clientes, instalar código malicioso ou usar o servidor para atacar outros. A Calif, uma das equipas que descobriu as falhas, confirmou ataques sem autenticação contra versões concretas de WordPress, Drupal, Joomla e Magento, de acordo com a Tenable. A falha mais antiga vem do PHP 5.4, lançado em 2012.
As falhas foram encontradas pela Calif, pela OpenAI e pela Wiz, com a ajuda de modelos de inteligência artificial. A data da divulgação foi antecipada um dia, depois de os números das falhas terem circulado na Internet.
A reacção foi invulgarmente forte
Segundo o Jornal de Negócios, com a Lusa, a NSA norte-americana recomendou retirar da Internet os sites em PHP ainda por actualizar, e vários países europeus desligaram sites públicos por precaução, entre eles os de todos os municípios de França. A Palo Alto Networks contou 22 milhões de plataformas expostas. Em Portugal, o Centro Nacional de Cibersegurança reiterou o alerta e pediu que se aplique a actualização a partir das fontes oficiais.
No Reino Unido, o centro nacional de cibersegurança descreveu a escala da falha como "sem precedentes" e retirou 32 serviços do Estado do ar, mas, segundo o 24 Notícias, não tinha recebido relatos de ataques bem-sucedidos.
Já está a ser explorada?
Há tentativas, e começaram cedo. A Amazon registou uma tentativa de ataque a 17 de Outubro, quatro dias antes da divulgação, e mais tentativas de vários grupos a 21. A Cloudflare contou dezenas de milhares de tentativas nos primeiros 45 minutos depois da divulgação. Ao mesmo tempo, a Rapid7 nota que os ataques públicos conhecidos só funcionam em combinações específicas de sistema, versão do PHP e servidor web, e a agência norte-americana CISA ainda não tinha a falha na sua lista de vulnerabilidades exploradas a 22 de Outubro.
Ou seja: não há motivo para pânico, mas há para pressa. Quando uma falha destas fica pública, os robôs que varrem a Internet à procura de servidores vulneráveis chegam em horas, não em semanas, como vimos com a falha crítica do WordPress em Setembro.
Está afectado?
Qualquer site em PHP que responde a pedidos da Internet está em risco, seja qual for a forma como o PHP corre no servidor (PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP ou LiteSpeed). O risco é maior com o mod_php, onde o ataque acontece antes de o código do site correr. A solução é ter uma destas versões ou posterior:
| Ramo do PHP | Versão corrigida |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 7.4, 8.0 e 8.1 | Sem versão oficial: só correcções mínimas ao código-fonte ou pacotes do fornecedor do sistema |
| 5.4 a 7.3 | Sem correcção |
Não chega saber o ramo. Um site "em PHP 8.4" com a 8.4.26 continua vulnerável. Para ver a versão exacta:
- WordPress: no painel, em Ferramentas → Saúde do site → Informação → Servidor.
- cPanel ou Plesk: o painel mostra o ramo escolhido, mas a versão exacta depende do alojamento. Pergunte ao fornecedor por escrito se o PHP do seu plano já está nas versões da tabela.
- Servidor próprio (VPS):
php -vna linha de comandos, e confirmar também a versão que o servidor web usa, que pode ser outra.
O que fazer esta semana
- Actualize o PHP. A equipa do PHP é clara: só a actualização resolve. Num alojamento partilhado, isto é trabalho do fornecedor; peça a confirmação. Num servidor próprio, instale os pacotes da distribuição (que receberam as correcções antes da divulgação) e reinicie todos os processos do PHP.
- Se está no PHP 8.1 ou anterior, planeie a mudança. Estas versões já não recebem correcções oficiais. É altura de passar para o 8.4 ou o 8.5, testando primeiro o site e os plugins numa cópia.
- Se não pode actualizar já, reduza a exposição. O aviso do PHP lista medidas temporárias, como desligar o
session.upload_progress.enabled, desligar ofatal_error_backtracesno PHP 8.5 e limitar o tamanho dos pedidos no servidor web. Reduzem o risco, mas não tornam o site seguro. A Cloudflare activou regras de firewall contra os ataques conhecidos, incluindo no plano gratuito, mas só protegem o tráfego que passa por ela. - Confirme as cópias de segurança. Se o pior acontecer, é a cópia que traz o site de volta. Explicámos como testar em Cópias de segurança: como saber se o site volta.
- Esteja atento a sinais estranhos. Utilizadores de administração novos, ficheiros alterados, redireccionamentos para outros sites ou um servidor lento sem razão. A ausência de erros nos registos não prova que o site está limpo.
A lição que fica
A maior parte dos sites de PME não é atacada por alguém que os escolheu. É atacada por robôs que procuram versões antigas. Esta falha mostra que não são só os plugins: a própria linguagem por baixo do site tem de estar numa versão suportada e actualizada, e alguém tem de estar a vigiar quando sai uma correcção urgente. Se ninguém na empresa sabe dizer em que versão do PHP está o site, esse é o primeiro problema a resolver. Se acontecer um incidente, ajuda ter o plano de resposta preparado antes.
Quer saber se o seu site está protegido?
A MarcaWeb trata da cibersegurança de sites e lojas online: actualizações, monitorização e cópias de segurança, com resposta quando sai uma falha destas. Comece pela auditoria gratuita ou fale connosco: escreva para info@marcaweb.pt ou ligue para o +351 920 260 897.
Fontes: aviso de segurança do PHP (21-10-2026), Tenable, Rapid7, Jornal de Negócios e 24 Notícias (22-10-2026). Artigo actualizado a 23-10-2026.


