Em resumo: A janela de tempo entre o patch e o ataque foi negativa no PHP2Shell: segundo notícias dos media, houve uma primeira tentativa de ataque logo a 17 de outubro de 2026, quatro dias antes das atualizações. Para os operadores, não conta por isso a pergunta “Quanto tempo temos?”, mas “Durante quanto tempo está o meu servidor aberto?”. Esta janela pessoal só termina quando a atualização está instalada e todos os processos PHP foram reiniciados.
O ponto de partida: ataques antes do patch
Durante muito tempo vigorou uma suposição cómoda: entre a atualização de segurança e os primeiros ataques passam alguns dias, tempo suficiente para a próxima janela de manutenção. O PHP2Shell refutou esta suposição. Segundo notícias dos media que citam a Amazon, uma primeira tentativa de ataque foi observada logo a 17 de outubro. A Cloudflare também relatou ataques precoces. Os patches saíram a 21 de outubro às 14:00 UTC.
Este artigo explica como surgem tais janelas de tempo e como encurtar a sua. A sequência exata das datas encontra-se na cronologia do PHP2Shell.
A janela de tempo entre patch e ataque por fases
Em torno de uma vulnerabilidade de segurança distinguem-se várias fases. No PHP2Shell foram assim:
| Fase | Em geral | No PHP2Shell |
|---|---|---|
| Antes de ser conhecida | A vulnerabilidade é só conhecida de quem a descobriu e do fabricante | Desenvolvimento da correção sob embargo |
| Primeiros ataques sem patch | Os atacantes usam a vulnerabilidade antes de existir uma atualização | segundo notícias dos media, primeira tentativa a 17/10 |
| Pré-aviso | O fabricante anuncia a atualização | 20/10, o php.net anuncia a versão |
| Patch disponível | Surgem a atualização e o aviso de segurança | 21/10, 14:00 UTC |
| Análise do patch | Investigadores e atacantes analisam as alterações | a watchTowr reproduziu a CVE-2026-109618, segundo as suas próprias declarações |
| Exploração em larga escala | campanhas automatizadas contra servidores sem patch | esperada pelo BSI; ataques bem-sucedidos em larga escala confirmados inicialmente desconhecidos |
| O seu patch | Atualização e reinício nos seus servidores | individual |
A última linha é a única que pode influenciar. Tudo o que vem antes é determinado por outros.
Porque é que o próprio patch aumenta a pressão
Uma atualização de segurança fecha a vulnerabilidade, mas ao mesmo tempo torna-a visível. As alterações ao código-fonte em projetos de código aberto como o PHP são públicas. Quem compara as diferenças entre a versão antiga e a nova fica a saber em que ponto estava o erro. Isto não é uma censura ao projeto PHP, mas o caso normal do software aberto e a base para que as distribuições possam criar backports.
Para os operadores, daqui decorre: a cada dia depois do patch cresce o número dos que sabem como a vulnerabilidade funciona. Ao mesmo tempo, diminui o número de servidores sem patch. Os que restam tornam-se assim os alvos óbvios. Como o PHP entrega atualizações de segurança no âmbito da sua manutenção de versões é explicado no artigo sobre o ciclo de lançamento do PHP.
Se o seu servidor esteve acessível entre 17 de outubro e o seu patch, faz parte uma verificação de vestígios. Guarde os registos desde 20 de outubro, antes que se percam por rotação.
Medir a sua própria janela de tempo
A sua janela de tempo pessoal começa, o mais tardar, com a publicação dos patches e termina com o reinício do último processo PHP. Registe para cada servidor:
- Conhecimento: Quando é que alguém na empresa soube da vulnerabilidade?
- Disponibilidade: Quando estava disponível o pacote da sua distribuição ou do seu fornecedor de alojamento?
- Instalação: Quando foi aplicado?
- Reinício: Quando deixou de haver processos PHP antigos em execução?
Precisamente o reinício é muitas vezes esquecido. Uma atualização instalada só produz efeito quando os processos antigos terminam. Como o verificar é descrito em Reiniciar o PHP-FPM e todos os processos PHP. Se ainda correm processos anteriores à atualização, vê-se pelas horas de arranque:
# Mostrar a hora de arranque de todos os processos PHP
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Se a hora de arranque for anterior à instalação da atualização, a janela ainda está aberta.
Porque é que a sua janela depende da via de obtenção
A rapidez com que consegue aplicar o patch não depende só de si, mas também de onde vem o seu PHP. As distribuições entregaram, segundo notícias, backports em parte ainda a 21 de outubro. Quem obtém o PHP de um repositório de terceiros depende do ritmo deste. Quem usa contentores tem de reconstruir e distribuir imagens, não basta uma simples atualização no contentor em execução. E no alojamento partilhado é o fornecedor que determina o momento.
Se conhecer a via de obtenção de cada servidor, sabe também em que ponto a sua janela fica aberta durante mais tempo. É aí que a preparação mais compensa, por exemplo com um acordo com o fornecedor de alojamento ou um procedimento testado para novas imagens de contentores.
Como encurtar a janela de tempo da próxima vez
- Subscrever avisos: Receber diretamente os avisos de segurança do php.net e da sua distribuição, e não só através da imprensa.
- Definir a responsabilidade: Para cada servidor, uma pessoa responsável com suplente.
- Usar automatismos onde fizerem sentido: As atualizações de segurança da distribuição podem ser aplicadas automaticamente. O que a favor e o que contra é descrito em Atualizações de segurança automáticas.
- Planear o reinício: O reinício dos serviços PHP faz parte fixa do procedimento, e não do acompanhamento posterior.
- Preparar a via de emergência: Página de emergência e decisão sobre um desligamento temporário, caso uma atualização não seja possível de imediato.
- Manter o comprovativo: Documentar as horas de instalação e de reinício, para poder comprovar mais tarde a sua janela.
Um processo duradouro que reúna estes pontos é descrito no artigo sobre o processo de gestão de patches.
Como ajuda concretamente a PHP SOS?
- Patch e reinício: Aplicamos a atualização e garantimos que já não correm processos PHP antigos.
- Comprovar a janela de tempo: Documentamos a instalação e o reinício de cada servidor com data e hora.
- Verificação de vestígios: Para o período em que o seu servidor esteve aberto, guardamos registos e procuramos anomalias.
- Processo para o futuro: Configuramos consigo canais de comunicação, responsabilidades e procedimentos de atualização.
Mais informações em serviço de patches PHP.
Conclusão
No PHP2Shell não houve período de carência. A janela de tempo entre o patch e o ataque é hoje, em vulnerabilidades críticas, muitas vezes zero ou até negativa. O que pode controlar é a sua própria janela: termina com o reinício e pode, com preparação, ser encurtada de dias para horas.
Perguntas frequentes
Quanto tempo há depois de uma atualização de segurança até aos ataques?
Não há um prazo fixo. No PHP2Shell, segundo notícias dos media, uma primeira tentativa de ataque foi observada logo a 17 de outubro, ou seja, quatro dias antes dos patches. Em vulnerabilidades críticas em software muito difundido, deve partir do princípio de que praticamente não há período de carência.
O que é um zero-day?
Uma vulnerabilidade que é atacada antes de existir uma atualização. O fabricante teve, por assim dizer, zero dias para a corrigir. Depois fala-se muitas vezes de uma vulnerabilidade conhecida ou N-Day, para a qual já existe um patch.
Porque é que os ataques aumentam muitas vezes depois de um patch?
Com o patch torna-se público em que ponto estava o erro. Investigadores de segurança e atacantes podem analisar as alterações. Ao mesmo tempo, muitos servidores continuam sem patch durante dias ou semanas e, portanto, são alvos compensadores.
Quando é que o meu servidor está realmente protegido?
Quando a atualização está instalada e todos os processos PHP foram reiniciados. Os novos ficheiros, por si só, não produzem efeito enquanto processos antigos correrem na memória. O fim da sua janela de tempo pessoal é, portanto, o reinício, e não a transferência.