# Aplicar patch, desligar ou esperar? Uma ajuda à decisão perante a falha do PHP

> Desligar o site por causa da falha do PHP? Uma ajuda à decisão entre aplicar patch, desligar e esperar, com critérios, procedimento e limites honestos.

Fonte: https://phpsos.de/pt/blog/patchen-abschalten-abwarten/  
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:** 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](https://phpsos.de/pt/blog/behoerden-webseiten-offline/).

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.

1. **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.
2. **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](https://phpsos.de/pt/php2shell/php-version-pruefen/).
3. **A atualização pode ser instalada nas próximas horas?** Se sim: aplicar patch, reiniciar, verificar. Até lá, podem ajudar medidas provisórias.
4. **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](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-patch/).
5. **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.

> **Importante:**
> 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?

1. Esclarecemos consigo, em pouco tempo, que sistemas são afetados e que estado de patch está comprovado.
2. Entregamos à gerência uma base de decisão numa página: opções, riscos, caminho recomendado.
3. 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](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).
4. 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.

## Fontes

- [BSI: aviso sobre o PHP2Shell](https://www.bsi.bund.de/)
- [php.net: avisos de segurança](https://www.php.net/)
- [hessenschau: sites de autoridades no Hessen desligados](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: falha de segurança no PHP](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)