# O que o CERT-EU e o CERT-Bund recomendam sobre o PHP2Shell

> O que o CERT-EU, o CERT-Bund e o BSI recomendam sobre o PHP2Shell, onde as recomendações coincidem e como isolar aplicações PHP expostas ao público.

Fonte: https://phpsos.de/pt/blog/cert-eu-empfehlungen-php/  
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 CERT-EU aconselha, segundo notícias, a levantar as instalações PHP, aplicar o patch de imediato e isolar as aplicações acessíveis ao público se não puderem receber o patch em tempo útil. O CERT-Bund e o BSI recomendam no seu alerta a atualização imediata e, se esta não for possível, retirar temporariamente da rede os servidores web afetados. As recomendações coincidem no essencial: primeiro a atualização, o isolamento como solução de recurso, as medidas provisórias apenas como complemento.

## Quem alerta, e para quem?

No PHP2Shell, várias entidades oficiais reagiram em poucas horas. Para as empresas na Alemanha, o BSI com a sua equipa de resposta a emergências informáticas CERT-Bund é o primeiro endereço. O CERT-EU é o serviço de cibersegurança das instituições da UE; as suas indicações dirigem-se primeiro a estas, mas são lidas em toda a Europa. Segundo a BleepingComputer, também o National Cyber Security Centre britânico emitiu um alerta. Do setor privado pronunciaram-se, entre outras, a Huntress e a Cloudflare.

Para si, como operador, a origem é menos importante do que a concordância. Quando várias entidades independentes aconselham o mesmo, é um sinal forte.

## CERT-Bund, CERT-EU e outros: os alertas PHP em comparação

| Entidade | Recomendação central | Particularidade |
|---|---|---|
| BSI / CERT-Bund | atualizar de imediato, caso contrário retirar temporariamente o servidor web da rede | nível de alerta 3 / laranja |
| CERT-EU | levantar as instalações PHP, aplicar o patch de imediato, caso contrário isolar as aplicações públicas | considerou possível, segundo notícias, que versões a partir do PHP 5 estejam afetadas |
| UK NCSC | atualizar de imediato ou retirar da rede os sistemas afetados até ao patch | segundo a BleepingComputer |
| php.net | atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, medidas provisórias apenas como proteção parcial | fonte primária para versões e definições |

Nenhuma das entidades recomenda confiar apenas numa Web Application Firewall ou em definições no `php.ini`. Todas indicam a atualização como a verdadeira solução. O que o BSI recomenda para além disso, em pormenor, encontra-se na página [O que o BSI recomenda sobre o PHP2Shell](https://phpsos.de/pt/compliance/bsi-empfehlungen/).

## A questão das versões: o que significa “a partir do PHP 5”

O CERT-EU considerou possível, segundo notícias, que estejam afetadas versões a partir do PHP 5. Para isso, a entidade apoiou-se, segundo notícias especializadas, em informações que circulavam antes do anúncio oficial. A imprensa especializada fala de quase todas as versões até ao PHP 5.4.

Na prática, o limite exato pouco altera. Para o PHP 8.1 e anteriores, o projeto PHP já não fornece atualizações oficiais. Existem backports mínimos do código-fonte para 7.4, 8.0 e 8.1, mas não há lançamentos. Quem ainda opera PHP 5 ou 7 depende de distribuições, de fornecedores terceiros ou de uma migração. Se a sua distribuição entregou uma correção, é mostrado pelas suas próprias páginas de segurança, como o Debian Security Tracker, os Ubuntu Security Notices ou as indicações da Red Hat. Existem também ofertas comerciais de suporte de longo prazo para versões antigas do PHP; se cobrem o PHP2Shell, deve pedir ao fornecedor uma confirmação por escrito. Pormenores sobre os ramos encontram-se em [Que versões do PHP estão afetadas?](https://phpsos.de/pt/php2shell/betroffene-php-versionen/) e [PHP 8.1 e anteriores](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/).

## Isolar: como aplicar a recomendação

“Isolar” soa abstrato. Quer dizer que os pedidos vindos da Internet deixam de chegar à aplicação PHP vulnerável. Consoante a aplicação, há vários níveis:

1. **Desligar por completo:** O site é substituído por uma página de emergência estática sem PHP. É a variante mais segura.
2. **Restringir o acesso:** A aplicação continua em funcionamento, mas só é acessível por VPN ou para endereços IP definidos, por exemplo para portais internos.
3. **Autenticação prévia:** Uma autenticação ao nível do servidor web ou do proxy, antes da aplicação. Atenção: no mod_php foi demonstrado um exploit antes de o código da aplicação ser executado. A autenticação tem, por isso, de atuar antes do PHP, e não na aplicação.
4. **Bloquear o acesso direto à origem:** Quem usa um serviço de proxy ou CDN deve garantir que o servidor não é também diretamente acessível.

Uma restrição no servidor web pode ter este aspeto, como configuração inofensiva para o Apache:

```apache
# Permitir o acesso apenas a partir da rede interna (adaptar o intervalo de exemplo)
<Location "/">
    Require ip 192.0.2.0/24
</Location>
```

Teste o efeito a partir do exterior, por exemplo através de uma ligação móvel. Um isolamento que só foi testado na rede do escritório não é um isolamento testado.

> **Dica:**
> Isolar é uma solução de ponte. Ao isolar, defina logo até quando chega a atualização e quem a aplica. Caso contrário, a solução de recurso torna-se um estado permanente.

## O que as recomendações exigem em comum: um inventário

Todas as entidades oficiais partem do princípio de que sabe onde corre PHP. É exatamente aqui que muitas empresas falham: microsites de campanhas antigas, um portal de clientes esquecido, um sistema de teste com endereço público, uma aplicação num NAS. O CERT-EU indica expressamente o levantamento das instalações PHP como primeiro passo.

Os sistemas esquecidos encontram-se mais facilmente por três vias: as zonas DNS dos seus domínios, a lista dos certificados TLS emitidos e os contratos com agências, fornecedores de alojamento e fornecedores de software. Qualquer entrada sobre a qual ninguém saiba dizer de imediato o que lá corre deve entrar na lista de verificação. São precisamente esses sistemas que, numa situação como a do PHP2Shell, são perigosos, porque ninguém lhes aplica patches e ninguém dá pela sua falta quando são comprometidos.

Um inventário utilizável contém, por sistema: endereço, finalidade, operador, versão do PHP e modo de operação, origem dos pacotes e o interlocutor para atualizações. Como o construir e mantê-lo atualizado é mostrado no artigo [Inventário de todos os sites e servidores](https://phpsos.de/pt/blog/inventar-websites-server/).

## Como ajuda concretamente a PHP SOS?

- **Levantamento:** Identificamos os seus sistemas PHP acessíveis ao público e ordenamo-los por risco.
- **Patch ou isolamento:** Aplicamos atualizações ou isolamos as aplicações que não podem receber o patch de imediato, e verificamos o efeito a partir do exterior.
- **Versões antigas:** Para sistemas com PHP 8.1 e anterior, planeamos consigo o caminho para uma versão suportada.
- **Comprovativo:** Recebe uma documentação das recomendações aplicadas por sistema.

Como levamos aplicações antigas para versões suportadas é descrito no serviço [migração de PHP para sistemas legados](https://phpsos.de/pt/leistungen/php-migration-legacy/).

## Conclusão

O CERT-EU, o CERT-Bund, o BSI e o projeto PHP falam a uma só voz: atualizar e, onde isso não for possível de imediato, isolar. As diferenças estão em pormenores como o limite das versões. Para a sua prática conta o primeiro passo que todos pressupõem: saber onde corre PHP.


## Perguntas frequentes

**Qual é a diferença entre o CERT-Bund e o CERT-EU?**  
O CERT-Bund é a equipa de resposta a emergências informáticas do BSI (Gabinete Federal Alemão para a Segurança da Informação) e alerta na Alemanha para vulnerabilidades. O CERT-EU é o serviço de cibersegurança das instituições e organismos da União Europeia. Ambos emitem recomendações que também são úteis para empresas.

**O que significa isolar uma aplicação PHP?**  
A aplicação deixa de estar livremente acessível a partir da Internet. Isso é possível através de uma página de emergência, de acesso apenas por VPN ou por determinados endereços IP, ou de um desligamento completo. O decisivo é que os pedidos vindos do exterior deixem de chegar ao processo PHP vulnerável.

**Segundo o CERT-EU, também as versões PHP 5 estão afetadas?**  
Segundo notícias, o CERT-EU considerou possível que estejam afetadas versões a partir do PHP 5, apoiando-se em informações que circulavam antes do anúncio oficial. A imprensa especializada fala de quase todas as versões até ao PHP 5.4. Para versões tão antigas não existem atualizações oficiais.

**Existem indicadores oficiais para reconhecer ataques?**  
Não. Até agora não há Indicators of Compromise confirmados e publicados sobre o PHP2Shell. A deteção baseia-se na análise de comportamento, por exemplo em processos do servidor web que iniciam shells ou em novos ficheiros PHP em pastas de uploads.

## 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/)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)