Em resumo: se deve desligar um site por causa da falha do PHP depende de uma pergunta: o PHP neste servidor corre comprovadamente num estado corrigido e todos os processos foram reiniciados? Se sim, não é necessário desligar. Se a atualização não for possível de imediato, o BSI recomenda retirar temporariamente o servidor web da rede. Esperar só é defensável se o sistema não usar PHP, não for acessível ao público ou o fornecedor tiver confirmado o patch por escrito.
A situação em que tem de decidir
O PHP2Shell abrange duas vulnerabilidades no próprio PHP, CVE-2026-109618 e CVE-2026-109619, ambas avaliadas com CVSS v4.0 de 9,2. Permitem a execução remota de código malicioso sem autenticação. Versões corrigidas estão disponíveis desde 21/10/2026: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não existem atualizações oficiais.
O BSI emitiu o nível de alerta laranja e aconselha a atualização imediata e, em alternativa, o desligamento temporário. Segundo notícias dos media, a cidade de Mogúncia (Mainz), serviços do governo regional do Hessen e outras instituições públicas retiraram sites da rede por precaução; a chancelaria do Hessen não comunicou qualquer ataque. O que as empresas podem daqui retirar, vê-se em Autoridades retiram sites da rede.
Para os responsáveis nas empresas, a pergunta é mais prática: o que fazemos hoje com a nossa loja, o nosso portal, o site da empresa?
Desligar o site, aplicar patch ou esperar: as três opções comparadas
A tabela seguinte põe as opções lado a lado. Não substitui a avaliação do seu caso concreto, mas torna visível a ponderação.
| Critério | Aplicar patch de imediato | Desligar temporariamente | Esperar |
|---|---|---|---|
| Proteção contra o PHP2Shell | Elevada, se o patch e o reinício estiverem comprovados | Elevada durante o desligamento | Nenhuma, enquanto sem patch |
| Interrupção da atividade | Curta, para a atualização e o reinício | Horas a dias | Nenhuma |
| Pré-requisito | Versão do PHP suportada, acesso, janela de manutenção | Decisão da gerência, página de substituição estática | Motivo comprovado de que não há risco |
| Esforço | Baixo a médio | Baixo do ponto de vista técnico, elevado do organizacional | Baixo, mas com esforço de verificação para o comprovativo |
| Caso típico | Servidor com PHP 8.2 a 8.5 | Sistema antigo com PHP 8.1 ou anterior, estado pouco claro | Sistema sem PHP ou só acessível internamente |
| Risco residual | Intrusão anterior continua possível | Intrusão anterior continua possível | Totalmente subsistente |
Uma linha merece atenção: nem o patch nem o desligamento esclarecem se antes já aconteceu alguma coisa. Segundo notícias dos media, a primeira tentativa de ataque observada foi a 17/10/2026, ou seja, antes do patch. Um olhar sobre possíveis vestígios faz por isso parte de cada opção.
Em cinco perguntas até à decisão
Percorra as perguntas por ordem. A primeira resposta clara leva, em regra, à decisão.
- No sistema corre PHP e é acessível a partir da Internet? Se não, o sistema não é diretamente afetado pelo PHP2Shell. Documente como o apurou.
- O estado do patch está comprovado? Comprovado significa: versão corrigida ou backport com números CVE no changelog do pacote e reinício de todos os processos PHP. Uma indicação de versão no painel não basta. Como verificar, vê-se em Verificar corretamente a versão do PHP e o estado dos patches.
- A atualização pode ser instalada nas próximas horas? Se sim: aplicar patch, reiniciar, verificar. Até lá, podem ajudar medidas provisórias.
- Não é possível, por exemplo devido ao PHP 8.1 ou à falta de acesso? Então o desligamento temporário é, segundo o BSI, o caminho. As medidas provisórias do php.net reduzem o risco, mas não protegem por completo; os pormenores estão em Medidas imediatas se ainda não puder aplicar o patch.
- Há sinais de comprometimento? Então a pergunta já não é «patch ou desligar», mas «tratar o incidente». Desligar, preservar as provas, não apagar precipitadamente.
Se desligar: desligar bem
Um desligamento deve remover a superfície de ataque, e não apenas esconder a página inicial. Uma página de manutenção que continue a ser gerada pelo PHP não cumpre esse fim. Melhor é uma página HTML estática que o servidor web entregue sem PHP, ou um redirecionamento para outro servidor.
Pense em tudo o que depende do mesmo PHP: subpáginas, interfaces para aplicações ou gestão de mercadorias, áreas de administração, chamadas de retorno de pagamento. Fale de antemão com o fornecedor de pagamentos e a logística, se uma loja for afetada. E informe colaboradores e clientes em palavras claras: o site está offline por precaução, o contacto faz-se por telefone e e-mail. É melhor do que o silêncio, que alimenta especulações.
Importante é também o fim do desligamento. Defina em que condição o site volta a ficar online, por exemplo «PHP em estado corrigido, reinício verificado, primeira verificação de vestígios sem resultado». Assim, de um travão de emergência faz-se um procedimento ordenado.
Desligar não é uma derrota. Várias entidades públicas fizeram precisamente isso, segundo notícias dos media, sem que existisse um ataque. Um desligamento por precaução não significa automaticamente que um site foi invadido.
Quando não precisa de um prestador de serviços
Nem todas as decisões exigem ajuda externa. Se o seu site está num fornecedor de alojamento que confirma por escrito o estado do patch e o reinício, e não há anomalias, está bem posicionado com uma breve documentação. O mesmo vale se a sua própria TI conseguir aplicar ela própria o patch num servidor com versão do PHP suportada e dominar a verificação.
A ajuda compensa quando correm sistemas com versão antiga do PHP, o estado é pouco claro, vários servidores são afetados ou existem sinais de intrusão.
Como ajuda concretamente a PHP SOS?
- Esclarecemos consigo, em pouco tempo, que sistemas são afetados e que estado de patch está comprovado.
- Entregamos à gerência uma base de decisão numa página: opções, riscos, caminho recomendado.
- Executamos o caminho escolhido, isto é, patch com reinício, medidas provisórias ou um desligamento limpo com página de substituição estática, como parte da nossa ajuda imediata PHP2Shell.
- Verificamos vestígios desde 17/10/2026 e documentamos o resultado.
Conclusão
Aplicar patch é o caso normal, desligar é o travão de emergência certo, esperar só é defensável com comprovativo. Quem responde honestamente às cinco perguntas e regista a decisão por escrito age no espírito da recomendação do BSI e pode mostrar mais tarde porquê.
Perguntas frequentes
Tenho de desligar o meu site por causa do PHP2Shell?
Não, se o PHP já corre num estado corrigido e todos os processos foram reiniciados. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda o desligamento temporário para o caso de uma atualização imediata não ser possível.
O que custa mais num desligamento: faturação ou risco?
Só se pode responder caso a caso. Uma paralisação de horas é, em regra, mais fácil de planear do que uma intrusão cujas consequências e duração ninguém conhece. Registe a ponderação por escrito, independentemente do resultado.
Pode uma página de manutenção correr no mesmo servidor?
Sim, se for entregue como ficheiro estático sem PHP. Se a página de manutenção continuar a ser gerada pelo PHP, a superfície de ataque mantém-se.
Esperar é alguma vez a escolha certa?
Sim, em casos claramente delimitados: quando no sistema não corre PHP, quando não é acessível a partir da Internet ou quando o fornecedor confirmou por escrito o patch e o reinício. Esperar sem tais comprovativos não é uma opção, é um risco.
Quem deve tomar a decisão?
A pessoa que responde pelo risco do negócio, em regra a gerência ou o proprietário. A TI fornece os factos. Quem decide deve constar de antemão do plano de emergência.