Em resumo: estar ou não afetado pelo PHP2Shell depende de três coisas: da versão do PHP, do modo de operação e de ter sido aplicado o patch, e de que forma. Se tem dúvidas, contacte-nos agora. Está afetado? Ligue-nos. Nós ajudamos. Esclarecemos isso remotamente, no próprio servidor e não por palpite, e fechamos a vulnerabilidade se estiver aberta.
Não apague nada nem reinstale nada agora. Mesmo que só queira esclarecer se está afetado: se o servidor já tiver sido atacado, precisamos dos ficheiros e dos registos inalterados. Comunicar uma emergência; percorremos a verificação em conjunto consigo.
Está afetado? Estes casos pertencem à lista de verificação
O PHP2Shell são duas vulnerabilidades críticas no próprio PHP (CVE-2026-109618 e CVE-2026-109619, ambas com a pontuação máxima de 9,2 segundo o CVSS v4.0). Permitem a execução de código malicioso remotamente, sem autenticação. Todos os modos de operação podem estar afetados: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Verifique cada um destes sistemas:
- servidores próprios, vServers e servidores root com PHP
- pacotes de alojamento e servidores geridos, mesmo que não tenha acesso à configuração
- contentores e serviços de plataforma que trazem uma imagem PHP
- sistemas de teste, ambientes de staging e sistemas antigos esquecidos que são acessíveis a partir da Internet
- NAS, appliances ou software de prestadores de serviços que usam PHP internamente
São precisamente os sistemas esquecidos que constituem o risco. Segundo a Unit 42, existem mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis, e o BSI (Gabinete Federal Alemão para a Segurança da Informação) esperava uma exploração rápida e em larga escala.
O que fazer já
- Criar um inventário. Anote todos os servidores, domínios e contratos de alojamento em que corre PHP, e quem é responsável por eles.
- Determinar a versão do PHP em cada sistema. Nos servidores, com
php -v. Tenha em conta que a linha de comandos pode usar uma versão diferente da do servidor web. - Esclarecer o modo de operação. O PHP corre como PHP-FPM, como mod_php ou através do LiteSpeed? Com mod_php, a equipa do PHP avalia o risco como o mais elevado.
- Perguntar ao fornecedor de alojamento e aos prestadores. Por escrito: que versão está a correr, a correção foi aplicada, todos os processos foram reiniciados?
- Conservar os registos. A imprensa especializada aconselha a conservar os registos a partir de 20/10/2026.
- Não esperar muito. Se um sistema estiver aberto e o patch não for possível de imediato, o BSI recomenda retirar temporariamente o servidor web da rede.
Como ajuda concretamente a PHP SOS?
Esclarecemos se está afetado remotamente e com provas.
- Levantar a situação: deixamos que nos descreva o seu inventário e ordenamos os sistemas por acessibilidade e risco.
- Preservar e fechar: onde estiver aberto, preservamos primeiro o estado e depois fechamos a vulnerabilidade com a atualização e o respetivo reinício. Onde isso não for possível de imediato, aplicamos medidas provisórias, que não constituem uma proteção completa.
- Verificar e limpar: verificamos se a vulnerabilidade foi explorada antes do patch e limpamos, se necessário. Separamos claramente se um servidor está afetado e se, eventualmente, já foi atacado.
- Reforçar e relatar: recebe uma lista por sistema: versão, modo de operação, prova do patch, pontos em aberto.
Como comprovar que está afetado
Um número de versão, por si só, não basta, porque os fornecedores fazem backports das correções. O Ubuntu 24.04, por exemplo, segundo relatos, continua a mostrar 8.3.6 mesmo depois da atualização. Há três vias fiáveis:
| Via | O que mostra | Limite |
|---|---|---|
| Comparar a versão com os níveis de correção | 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou superior está corrigido | só vale para versões originais, não para backports |
Teste de memory_hard_limit_percent |
bool(false) significa: diretiva desconhecida, logo afetado |
executar individualmente por versão e modo de operação |
| Pesquisar números CVE no changelog do pacote | comprova backports nas distribuições | a fonte é o arquivo de segurança do fornecedor |
O teste é assim:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Como verificar corretamente a versão e o nível de patch, explica-o a página Verificar corretamente a versão do PHP e o nível de patch. Uma panorâmica dos ramos é dada em Que versões do PHP estão afetadas?. Porque é que a indicação pode parecer antiga apesar do patch, explica-o o artigo php -v mostra um número antigo.
Afetado e já sem patch possível: PHP 8.1 e anteriores
Para o PHP 8.1 e anteriores já não existem atualizações oficiais do projeto PHP, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Quem usa uma destas versões tem, em geral, dois caminhos: um fornecedor com backport comprovado ou a migração para uma versão mantida. Existem ofertas comerciais de suporte de longo prazo; se e quando cobrem o PHP2Shell, o fornecedor tem de o confirmar por escrito. Ajudamos a enquadrar o caso em PHP 8.1 e anteriores: o que se aplica agora e na execução através do serviço de patches PHP.
O que nos deve enviar
- Lista dos seus servidores, domínios e fornecedores de alojamento
- Versão do PHP em cada sistema, na medida do conhecido
- Modo de operação e servidor web, na medida do conhecido
- Indicação de se a Cloudflare ou outra proteção está colocada à frente e de se o servidor de origem é diretamente acessível
- Respostas do seu fornecedor de alojamento, se já as tiver pedido
- Pessoa de contacto para autorizações e reinícios
Porquê a PHP SOS
Trabalhamos com qualidade Made in Germany e, há mais de 25 anos, estamos especializados em segurança informática com a nossa rede de parceiros de profissionais de cibersegurança. Tem um interlocutor que percorre o seu inventário e comprova cada afirmação, em vez de se limitar a ler números de versão. Trabalhamos remotamente, sem deslocações, e documentamos o que verificámos. Uma afirmação como «seguro» só a damos na medida em que possa ser comprovada. Para ambientes maiores, pode ser considerada a ajuda urgente PHP2Shell.
Está afetado? Ligue-nos. Nós ajudamos.
Se não sabe se está afetado, isso é motivo suficiente para nos contactar agora. Ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem e esclarecemo-lo consigo no servidor. Comunicar já uma emergência.
Perguntas frequentes
Estou afetado pelo PHP2Shell se só uso WordPress ou uma loja online?
Possivelmente sim. As vulnerabilidades estão no PHP, não no CMS. O que conta é a versão do PHP e o modo de operação que realmente servem o seu site; uma atualização do WordPress não altera isso.
O número da versão basta para saber se tenho o patch?
Nem sempre. As distribuições e os fornecedores de alojamento aplicam por vezes as correções como backport, e então o número mantém-se. Têm valor probatório o changelog do pacote com os números CVE ou a confirmação escrita do seu fornecedor.
Existe um teste rápido para saber se a minha versão do PHP inclui a correção?
Segundo o manual do PHP, uma versão que não conhece a diretiva memory_hard_limit_percent está afetada. O teste tem de ser feito individualmente para cada versão do PHP e modo de operação, porque a linha de comandos pode usar uma versão diferente da do servidor web.
As versões mais antigas do PHP, como 7.4 ou 8.0, também estão afetadas?
Segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4. Para a 8.1 e anteriores, o projeto PHP já não disponibiliza atualizações oficiais, apenas backports mínimos do código-fonte. Se um fornecedor os aplicou, tem de o confirmar.
A Cloudflare protege-me se estiver afetado?
Em parte. A Cloudflare disponibilizou regras de proteção, mas avisa ela própria de que não substituem a atualização. Se o seu servidor de origem for diretamente acessível, a proteção é contornada.