# Está afetado pelo PHP2Shell? Esclareça já

> Servidores afetados pelo PHP2Shell? Verificamos versão, modo de operação e nível de patch remotamente. Ligue ou escreva-nos por WhatsApp.

Fonte: https://phpsos.de/pt/soforthilfe/php2shell-betroffen/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

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

> **Agir de imediato:**
> **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](https://phpsos.de/pt/notfall/); 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á

1. **Criar um inventário.** Anote todos os servidores, domínios e contratos de alojamento em que corre PHP, e quem é responsável por eles.
2. **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.
3. **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.
4. **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?
5. **Conservar os registos.** A imprensa especializada aconselha a conservar os registos a partir de 20/10/2026.
6. **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.

1. **Levantar a situação:** deixamos que nos descreva o seu inventário e ordenamos os sistemas por acessibilidade e risco.
2. **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.
3. **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.
4. **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:

```bash
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](https://phpsos.de/pt/php2shell/php-version-pruefen/). Uma panorâmica dos ramos é dada em [Que versões do PHP estão afetadas?](https://phpsos.de/pt/php2shell/betroffene-php-versionen/). Porque é que a indicação pode parecer antiga apesar do patch, explica-o o artigo [php -v mostra um número antigo](https://phpsos.de/pt/blog/php-v-zeigt-alte-nummer/).

## 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](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/) e na execução através do [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).

## 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](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).

## 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](https://phpsos.de/pt/notfall/).


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

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [Manual do PHP: configuração do núcleo (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [PHP: versões suportadas](https://www.php.net/supported-versions.php)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)