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. Isto não é aconselhamento jurídico.
Que custos surgem tipicamente numa emergência é explicado no artigo Custos de um ataque informático.
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.
- Que sistemas nossos correm com PHP? Uma lista com endereço, finalidade e operador.
- 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.
- Todos os processos PHP foram reiniciados? Sem reinício, a atualização não produz efeito.
- E os sistemas com PHP 8.1 ou anterior? Para esses não há atualizações oficiais. Qual é o plano?
- 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.
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 |
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. 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.
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.