# PHP2Shell e Log4Shell: o que as vulnerabilidades têm em comum

> PHP2Shell e Log4Shell em comparação: o que liga as vulnerabilidades, onde diferem e que lições de 2021 as empresas podem aproveitar hoje.

Fonte: https://phpsos.de/pt/blog/php2shell-und-log4shell/  
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:** O PHP2Shell e o Log4Shell têm em comum o facto de serem vulnerabilidades críticas num componente de base muito difundido, através das quais os atacantes podem executar código sem autenticação. Diferem na visibilidade, na classificação e na situação quanto a ataques conhecidos. A lição mais importante do Log4Shell continua a valer hoje sem alterações: quem sabe onde corre o componente afetado age em horas e não em semanas.

## Porque é que a comparação aparece agora por todo o lado

Em dezembro de 2021, o Log4Shell manteve o mundo da TI em suspenso durante semanas. O BSI declarou então o nível de alerta mais alto, vermelho. Quase cinco anos depois, o mesmo nome surge em muitos artigos sobre o PHP2Shell, muitas vezes ligado à pergunta: “Vai ser outra vez tão mau?”

A comparação é óbvia e é útil se for bem conduzida. Mostra que padrões se repetem e que experiências as empresas podem aproveitar diretamente hoje. Como o BSI classifica a situação atual é explicado no artigo [Nível de alerta laranja do BSI](https://phpsos.de/pt/blog/bsi-warnstufe-orange-erklaert/).

## PHP2Shell e Log4Shell em comparação direta

| Característica | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Software afetado | biblioteca Java Log4j | o próprio tempo de execução PHP |
| Identificador | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Classificação | CVSS 10,0 (v3) | CVSS v4.0 9,2 |
| Efeito | execução de código sem autenticação | execução de código sem autenticação |
| Nível de alerta do BSI | 4 / vermelho | 3 / laranja |
| Situação aquando do alerta | segundo notícias da época, comprometimentos conhecidos | tentativas de ataque noticiadas, segundo o BSI inicialmente sem ataques bem-sucedidos em larga escala confirmados |
| Visibilidade | muitas vezes escondido no fundo das aplicações | visível no servidor, mas o nível de patch é difícil de ler devido aos backports |
| Avisos posteriores | várias outras CVE em poucas semanas | aviso sobre a CVE-2026-115560 a 23/10 |

## O que as duas vulnerabilidades têm em comum

**Um componente de base, inúmeras aplicações.** O Log4j estava em software Java de todos os tipos, o PHP sustenta WordPress, Shopware, TYPO3 e inúmeros desenvolvimentos próprios. Em ambos os casos, não é um produto que está afetado, mas um alicerce.

**Sem necessidade de início de sessão.** Ambas as vulnerabilidades permitem a execução de código à distância sem autenticação. Isso torna-as atrativas para ataques automatizados.

**O patch não é o fim.** No Log4Shell verificou-se que muitos sistemas já tinham sido atacados antes da atualização. Também no PHP2Shell vale: um patch não remove software malicioso introduzido. Segundo notícias dos media, uma primeira tentativa de ataque foi observada logo a 17 de outubro.

**Avisos posteriores.** Depois do Log4Shell surgiram, em poucas semanas, outras CVE sobre o Log4j. No PHP, dois dias depois dos patches veio o aviso sobre a CVE-2026-115560. Porque são prováveis mais avisos é explicado em [Depois do PHP2Shell: porque são prováveis mais avisos](https://phpsos.de/pt/blog/weitere-php-meldungen/).

## Onde a comparação falha

A maior diferença está na visibilidade. O Log4j estava muitas vezes integrado como parte de uma aplicação, por vezes com vários níveis de aninhamento. Muitos operadores simplesmente não sabiam que o usavam. O PHP, pelo contrário, não é segredo num servidor web. Em compensação, no PHP2Shell surge outra incerteza: as distribuições e os fornecedores de alojamento aplicam correções como backport, e o número de versão apresentado mantém-se igual. Vê-se o PHP, mas não de imediato se tem patch.

Uma segunda diferença é o ponto de partida da atualização. No Log4Shell, muitas vezes tinham de ser primeiro os fabricantes de aplicações especializadas a fornecer novas versões. No PHP2Shell estão disponíveis atualizações para todos os ramos suportados. A dificuldade surge com o PHP 8.1 e anteriores, para os quais o projeto PHP já não publica atualizações oficiais.

Uma terceira diferença diz respeito ao local do ataque. No Log4Shell, qualquer ponto em que uma aplicação registasse entradas podia ser perigoso, incluindo sistemas internos que só indiretamente recebiam dados da Internet. No PHP2Shell, o centro é o servidor web, que recebe diretamente os pedidos. Isso torna a procura de sistemas afetados um pouco mais clara: primeiro vêm todos os serviços PHP acessíveis ao público, depois as aplicações internas.

Por fim, a situação quanto à exploração é diferente. Para o Log4Shell circularam cedo ferramentas de ataque simples e, segundo notícias da época, os comprometimentos eram já conhecidos à data do alerta. No PHP2Shell, a Cloudflare e a Patchstack reportam tentativas de ataque, a watchTowr reproduziu uma das vulnerabilidades segundo as suas próprias declarações e o BSI não comunicou inicialmente ataques bem-sucedidos em larga escala confirmados. Isso pode mudar. É, porém, uma razão pela qual a comparação não serve como prognóstico.

> **Dica:**
> Aproveite internamente as experiências do Log4Shell: que listas, procedimentos e contactos ajudaram então? Muito disso pode ser reutilizado diretamente para o PHP2Shell.

## Cinco lições do Log4Shell que ajudam hoje

1. **Inventário antes do patch:** Quem tinha em 2021 uma lista atualizada dos seus sistemas foi mais rápido. Hoje vale o mesmo. Uma orientação é oferecida pelo artigo [Inventário de todos os sites e servidores](https://phpsos.de/pt/blog/inventar-websites-server/).
2. **Conhecer as dependências:** Uma lista de materiais dos componentes de software, abreviadamente SBOM, responde à pergunta “Onde é que usamos isto?” em minutos. Para aplicações PHP, ajuda olhar para o Composer, como descreve [Verificar dependências do Composer](https://phpsos.de/pt/ratgeber/composer-abhaengigkeiten-pruefen/).
3. **Conservar os registos:** Depois do Log4Shell, muitas empresas já não conseguiam esclarecer se tinham sido afetadas, porque faltavam registos. A imprensa especializada aconselha, no PHP2Shell, guardar os registos desde 20 de outubro.
4. **Verificar a posteriori:** Um patch não responde ao que aconteceu antes. Uma verificação de vestígios faz parte.
5. **Estar preparado para avisos posteriores:** A primeira atualização raramente é a última. Quem montou uma vez corretamente a via de atualização repete-a depressa.

## Como ajuda concretamente a PHP SOS?

- **Levantamento:** Apuramos onde corre PHP na sua empresa, em que versão e modo de operação.
- **Patch e reinício:** Aplicamos atualizações e comprovamos o estado de cada sistema.
- **Verificação de vestígios:** Guardamos registos e procuramos anomalias desde 17 de outubro.
- **Observação contínua:** Mantemos os seus sistemas debaixo de olho para que os avisos posteriores não comecem outra vez do zero.

Como é a monitorização contínua é descrito em [Monitorização de segurança para servidores web](https://phpsos.de/pt/leistungen/security-monitoring/).

## Conclusão

O PHP2Shell não é o Log4Shell, mas rima. Ambos atingem um alicerce, ambos exigem mais do que um patch. As empresas que de 2021 retiraram inventário, conservação de registos e vias de atualização estão hoje em vantagem. Para todas as outras, é agora o momento de recuperar o atraso.


## Perguntas frequentes

**O PHP2Shell é tão grave como o Log4Shell?**  
Ambas são vulnerabilidades críticas em software muito difundido, através das quais os atacantes podem executar código sem autenticação. O BSI (Gabinete Federal Alemão para a Segurança da Informação) classificou o Log4Shell em 2021 com vermelho e o PHP2Shell com laranja. Uma diferença importante: no Log4Shell, segundo notícias da época, já eram conhecidos comprometimentos aquando do alerta; no PHP2Shell, segundo o BSI, inicialmente não havia ataques bem-sucedidos em larga escala confirmados.

**O que foi o Log4Shell?**  
O Log4Shell foi uma vulnerabilidade crítica na biblioteca Java Log4j, que se tornou conhecida em dezembro de 2021 e é registada como CVE-2021-44228. O Log4j fazia parte, como componente, de muitíssimas aplicações, muitas vezes sem que os operadores o soubessem.

**Virão mais vulnerabilidades depois do PHP2Shell?**  
É possível. Depois do Log4Shell seguiram-se, em poucas semanas, outras CVE sobre o Log4j. No PHP houve a 23 de outubro um aviso sobre a CVE-2026-115560, que só atua com uma configuração invulgar. Conte com avisos posteriores.

**O que é uma SBOM?**  
Uma Software Bill of Materials é uma lista de materiais de todos os componentes de software de que uma aplicação é composta. Com ela, perante uma nova vulnerabilidade, é possível apurar rapidamente onde o componente afetado é utilizado.

## Fontes

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