# O que é o PHP2Shell? A vulnerabilidade explicada de forma simples

> PHP2Shell explicado de forma simples: o que está por trás das duas vulnerabilidades críticas do PHP, que servidores estão afetados e que passos dar agora.

Fonte: https://phpsos.de/pt/php2shell/was-ist-php2shell/  
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:** PHP2Shell é o nome de duas vulnerabilidades de segurança críticas no próprio PHP, a CVE-2026-109618 e a CVE-2026-109619. Através delas, os atacantes podem executar código malicioso em servidores web vulneráveis sem autenticação. A única solução é a atualização para uma versão corrigida do PHP, seguida do reinício de todos os processos PHP.

## O que é o PHP2Shell?

O PHP é a linguagem de programação em que corre uma grande parte de todos os sites: páginas de empresas com WordPress ou TYPO3, lojas online com Shopware ou WooCommerce, portais internos e desenvolvimentos próprios. A 21 de outubro de 2026, o projeto PHP publicou atualizações de segurança para duas vulnerabilidades que ficaram conhecidas pelo nome PHP2Shell.

Ambas as vulnerabilidades têm CVSS v4.0 de 9,2, ou seja, são críticas. A consequência é, nos dois casos, a mesma: execução remota de código malicioso, sem que o atacante tenha de se autenticar. Os especialistas falam de “unauthenticated Remote Code Execution”. Quem consegue executar código no servidor pode, na pior das hipóteses, ler dados, instalar backdoors ou usar o servidor para outros ataques.

Importante para a compreensão: a vulnerabilidade não está num CMS ou num plugin em particular, mas no PHP. Uma atualização do WordPress, do Shopware ou do TYPO3 não a corrige, por isso.

## Porque é que a vulnerabilidade é tão grave?

Três pontos tornam o PHP2Shell particularmente delicado do ponto de vista das autoridades de segurança:

- **Dimensão:** estão afetados os modos de operação habituais do PHP, nomeadamente PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A Palo Alto Networks (Unit 42) contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis.
- **Não é preciso início de sessão:** o atacante não precisa de palavra-passe nem de conta de utilizador.
- **Momento precoce:** no Apache com mod_php, segundo a equipa do PHP, foi demonstrado um exploit antes sequer de o código da aplicação ser executado. As funções de proteção dentro do site não atuam então.

O BSI declarou o nível de alerta 3 (laranja). Recomenda a atualização imediata e, se esta não for possível de imediato, desligar temporariamente da rede os servidores web afetados.

## Que servidores estão afetados pelo PHP2Shell?

As vulnerabilidades estão corrigidas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Os níveis anteriores destes ramos estão afetados. Para o PHP 8.1 e anteriores já não existem atualizações oficiais; segundo a imprensa especializada, estão afetadas quase todas as versões até ao PHP 5.4. A visão geral completa encontra-a na página [Que versões do PHP estão afetadas?](https://phpsos.de/pt/php2shell/betroffene-php-versionen/).

Uma particularidade: as distribuições Linux e os fornecedores de alojamento aplicam por vezes as correções como backport. Então, o Plesk, por exemplo, continua a indicar 8.2.34, embora o erro esteja corrigido. O que conta é o estado do pacote e a confirmação do fornecedor. Como o verificar, explicamo-lo em [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/).

## O que está comprovado, o que está em aberto?

**Comprovados** estão os dois números CVE, as versões corrigidas e as medidas provisórias que o php.net publicou. A 23 de outubro juntou-se um aviso sobre mais uma vulnerabilidade, a CVE-2026-115560, que só atua numa configuração invulgar.

**Provável** é que os atacantes continuem a procurar ativamente servidores sem patch. Segundo notícias dos meios de comunicação, foi observada uma primeira tentativa de ataque já a 17 de outubro, ou seja, antes da publicação dos patches. A Cloudflare comunicou tentativas de ataque e disponibilizou regras de proteção, mas chama a atenção para o facto de as regras baseadas apenas nos dados do pedido não bastarem.

**Em aberto** está quantos servidores já foram atacados com sucesso. Segundo o BSI, não eram inicialmente conhecidos ataques bem-sucedidos em larga escala. Não existem indicadores de compromisso (IOCs) confirmados e publicados. Se um servidor foi afetado só se pode, por isso, avaliar através de uma análise de comportamento. A sequência temporal está resumida na [cronologia de 17 a 25 de outubro](https://phpsos.de/pt/ratgeber/php2shell-chronologie/).

## O que as empresas devem fazer agora

1. **Esclarecer quem é responsável:** servidor próprio, servidor gerido ou fornecedor de alojamento.
2. **Atualizar o PHP** para uma versão corrigida ou um backport confirmado.
3. **Reiniciar todos os processos PHP.** Ficheiros novos, só por si, não bastam enquanto processos antigos correrem na memória.
4. **Guardar os registos,** e isto desde 20 de outubro. A imprensa especializada aconselha a conservar esses dados.
5. **Verificar se há vestígios.** Um patch não remove software malicioso já introduzido e não prova que antes nada aconteceu. Indicações a esse respeito dá-as a página [Já estou comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

> **Importante:**
> Uma atualização fecha a porta, mas não arruma a casa. Se o seu servidor esteve acessível entre 17 de outubro e o patch, a verificação de vestígios é obrigação, e não um extra.

## Como ajuda concretamente a PHP SOS?

Com a [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/), assumimos os passos que muitas empresas não conseguem cobrir internamente em curto prazo:

- **Levantamento:** apuramos a versão do PHP, o modo de operação e o estado do pacote de cada servidor afetado.
- **Patch ou transição:** instalamos a atualização ou, onde isso ainda não é possível, aplicamos as medidas provisórias do php.net e esclarecemos a questão de saber se o servidor tem de sair temporariamente da rede.
- **Reinício e comprovativo:** reiniciamos todos os processos PHP e documentamos o estado antes e depois.
- **Verificação de vestígios:** preservamos os registos desde 20 de outubro e verificamos se há anomalias, até o incidente estar concluído e documentado.


## Perguntas frequentes

**O PHP2Shell é uma vulnerabilidade do WordPress?**  
Não. As vulnerabilidades estão no PHP, ou seja, na linguagem de programação em que correm o WordPress, o Shopware, o TYPO3 e muitos outros sistemas. Uma atualização do CMS não as corrige, por isso. O decisivo é o nível do PHP no servidor.

**Como cliente de um fornecedor de alojamento, tenho de fazer alguma coisa?**  
No alojamento partilhado, é em regra o fornecedor que instala a atualização do PHP. Deve, ainda assim, pedir confirmação por escrito de que a versão do PHP que utiliza tem o patch aplicado e foi reiniciada. Se algo aconteceu antes do patch, a atualização não o esclarece.

**De onde vem o nome PHP2Shell?**  
O nome descreve a consequência: através do PHP, um atacante pode, na pior das hipóteses, obter uma linha de comandos, ou seja, uma shell, no servidor. As designações oficiais são os números CVE-2026-109618 e CVE-2026-109619.

**O meu site já foi atacado se foi colocado offline?**  
Não necessariamente. Alguns fornecedores desligaram sites da rede por precaução, como recomenda o BSI (Gabinete Federal Alemão para a Segurança da Informação) quando uma atualização não é possível de imediato. É uma medida de proteção e não uma prova de um ataque.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)