# PHP2Shell em cinco minutos: briefing para a administração

> PHP2Shell em cinco minutos: a situação, o risco para o negócio, cinco perguntas à sua TI e as decisões que os gestores devem tomar hoje.

Fonte: https://phpsos.de/pt/blog/php2shell-briefing-geschaeftsfuehrung/  
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:** A falha de segurança PHP2Shell consiste em dois erros críticos no PHP, a base da maioria dos sites e lojas online. Através deles, os atacantes podem executar código malicioso em servidores web sem palavra-passe. O BSI alerta com o nível laranja e aconselha: atualizar de imediato, caso contrário retirar temporariamente da rede os servidores afetados. Para a administração, isto significa hoje: esclarecer a responsabilidade, exigir a atualização e o comprovativo, decidir sobre um desligamento e documentar tudo.

## A situação em três frases

A 21 de outubro de 2026, o projeto PHP publicou atualizações para duas vulnerabilidades críticas, conhecidas pelo nome PHP2Shell. Está afetado o próprio PHP, e não um produto específico, ou seja, potencialmente qualquer site, loja e portal que corra com PHP. O BSI declarou o nível de alerta 3 / laranja, empresas de segurança reportam tentativas de ataque e ataques bem-sucedidos em larga escala confirmados não eram, segundo o BSI, inicialmente conhecidos.

Autoridades como o BKA (o Gabinete Federal de Polícia Criminal alemão) e várias cidades desligaram os seus sites por precaução, segundo notícias dos media. Foi prudência, e não sinal de um ataque.

## O que a falha de segurança PHP significa para a administração e para as empresas

A pergunta não é se usa PHP. Quase todas as empresas o fazem em algum lado: site, loja, portal de candidaturas, área de clientes, intranet, sistema de tickets, microsite de agência. A pergunta é se esses sistemas estão atualizados e quem é responsável por eles.

Se um ataque for bem-sucedido, o atacante pode, no pior dos casos, tomar conta do servidor. As possíveis consequências são fuga de dados, conteúdos manipulados, redirecionamentos para sites fraudulentos, paragem da loja ou a utilização abusiva do servidor para outros ataques. Se puderem estar em causa dados pessoais, acrescentam-se obrigações de notificação; o prazo ao abrigo do Art. 33 do RGPD é, em regra, de 72 horas. Pormenores em [obrigação de notificação do RGPD](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/). Isto não é aconselhamento jurídico.

Que custos surgem tipicamente numa emergência é explicado no artigo [Custos de um ataque informático](https://phpsos.de/pt/blog/kostenposten-eines-hacks/).

### Onde o PHP é muitas vezes esquecido nas empresas

A maioria tem o site principal debaixo de olho. Esquecem-se mais facilmente os sistemas na periferia: o portal de candidaturas de um fornecedor externo, a landing page de uma campanha anterior, uma área de parceiros para revendedores, o sistema de tickets do suporte, uma cloud de ficheiros em servidor próprio ou a interface web de um armazenamento em rede. Também os sistemas de teste de agências são muitas vezes acessíveis ao público e correm no mesmo servidor que o site real.

Para a administração, a lição é simples: a pergunta à TI não é “O nosso site tem o patch aplicado?”, mas “Todos os nossos sistemas com PHP têm o patch aplicado, incluindo os de prestadores de serviços?”. A diferença entre as duas perguntas é muitas vezes precisamente o ponto em que um ataque tem êxito.

### O que a situação não é

Igualmente importante é o enquadramento para baixo. O PHP2Shell não é motivo para um ativismo que perturbe a operação mais do que o necessário. Quem aplicou o patch de forma comprovada, reiniciou todos os processos PHP e não encontra anomalias na verificação pode regressar ao funcionamento normal. Um desligamento temporário é uma opção para os casos por esclarecer, e não uma obrigação para todos.

## Cinco perguntas à sua TI ou ao seu prestador de serviços

Pode fazer estas perguntas hoje. As respostas devem vir por escrito.

1. **Que sistemas nossos correm com PHP?** Uma lista com endereço, finalidade e operador.
2. **Cada sistema tem o patch aplicado?** Versão corrigida 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou um backport confirmado pelo fornecedor.
3. **Todos os processos PHP foram reiniciados?** Sem reinício, a atualização não produz efeito.
4. **E os sistemas com PHP 8.1 ou anterior?** Para esses não há atualizações oficiais. Qual é o plano?
5. **Verificou-se se algo aconteceu antes da atualização?** Registos desde 20 de outubro guardados, vestígios procurados?

Se o seu site está num fornecedor de alojamento, ajuda um pedido formal. Um modelo é oferecido pelo guia [Pedir confirmação da atualização PHP ao fornecedor de alojamento](https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/).

## As decisões que devem ser tomadas hoje

| Decisão | Opções | Base |
|---|---|---|
| Quem lidera? | uma pessoa responsável interna, um parceiro externo | a responsabilidade tem de ser inequívoca |
| Sistemas sem patch | aplicar o patch de imediato, medidas provisórias, desligar temporariamente | recomendação do BSI, situação dos dados, relevância para as vendas |
| Verificação de vestígios | interna, externa, só em caso de anomalias | necessidade de proteção dos dados no servidor |
| Comunicação | informar internamente, preparar os clientes, aguardar | situação após a verificação |
| Sistemas antigos | planear migração, isolar, desligar | PHP 8.1 e anteriores sem atualizações oficiais |

> **Importante:**
> Registe quem decidiu o quê, quando e com que base de informação. Basta uma nota curta e datada. Posteriormente, perante seguradoras, clientes ou entidades de supervisão, vale muitas vezes mais do que qualquer explicação a posteriori.

Porque é que esta documentação é importante para a direção é explicado na página [Responsabilidade da gerência em caso de falhas de segurança informática](https://phpsos.de/pt/compliance/geschaeftsfuehrer-haftung/). Isto é informação geral e não aconselhamento jurídico.

## O que não deve acreditar

Três afirmações que os gestores ouvem atualmente com frequência são todas falsas:

- **“Atualizámos o WordPress, por isso estamos seguros.”** A vulnerabilidade está no PHP, e não no CMS. Uma atualização do CMS não a fecha.
- **“Somos demasiado pequenos, ninguém nos ataca.”** Os ataques são automatizados. Procuram-se servidores vulneráveis, e não nomes conhecidos.
- **“A atualização está instalada, o assunto está resolvido.”** Um patch não remove software malicioso introduzido antes e não prova que nada aconteceu.

## Como ajuda concretamente a PHP SOS?

- **Panorama para a direção:** Elaboramos uma breve visão geral dos seus sistemas PHP com o estado e a recomendação para cada um.
- **Execução:** Aplicamos o patch, reiniciamos ou aplicamos medidas provisórias onde ainda não é possível atualizar.
- **Verificação:** Guardamos registos e procuramos vestígios de um ataque.
- **Comprovativo:** Recebe uma documentação que pode usar internamente e perante terceiros.

O procedimento é descrito na [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).

## Conclusão

O PHP2Shell é uma vulnerabilidade técnica com uma tarefa de gestão. A técnica fica para os especialistas. A administração assegura que alguém é responsável, que as cinco perguntas são respondidas e que as decisões são tomadas de forma consciente e documentadas. Cabe numa manhã, se começar hoje.


## Perguntas frequentes

**A administração tem de se ocupar pessoalmente do PHP2Shell?**  
Da execução técnica, não; da coordenação, sim. A administração deve garantir que as responsabilidades estão claras, que a recomendação do BSI (Gabinete Federal Alemão para a Segurança da Informação) é aplicada e que decisões como um desligamento temporário são tomadas de forma consciente e documentadas.

**Como explico a vulnerabilidade numa frase?**  
No PHP, o software em que correm a maioria dos sites e lojas, há dois erros críticos através dos quais estranhos podem iniciar programas no servidor sem palavra-passe; existe uma atualização disponível e tem de ser aplicada.

**Quanto custa não fazer nada?**  
Não se pode quantificar de forma geral. As possíveis consequências de um ataque bem-sucedido são tempos de paralisação, fuga de dados, obrigações de notificação, custos de limpeza e de análise forense e perda de confiança dos clientes. Uma atualização com verificação é, em regra, bastante menos dispendiosa.

**Basta o fornecedor de alojamento tratar do assunto?**  
No alojamento partilhado, é em regra o fornecedor que aplica a atualização. Peça-lhe uma confirmação por escrito, incluindo o reinício dos processos PHP. A confirmação não esclarece se algo aconteceu antes da atualização; para isso é necessária uma verificação do site.

## 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/)
- [RGPD Art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)