# A janela de tempo entre o patch e o ataque

> A janela de tempo entre patch e ataque explicada: as fases no PHP2Shell, como medir a sua própria janela e que passos a encurtam de dias para horas.

Fonte: https://phpsos.de/pt/blog/zeitfenster-patch-angriff/  
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 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](https://phpsos.de/pt/ratgeber/php2shell-chronologie/).

## 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](https://phpsos.de/pt/php/release-zyklus/).

> **Agir de imediato:**
> 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](https://phpsos.de/pt/php2shell/php-fpm-neustart/). Se ainda correm processos anteriores à atualização, vê-se pelas horas de arranque:

```bash
# 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

1. **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.
2. **Definir a responsabilidade:** Para cada servidor, uma pessoa responsável com suplente.
3. **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](https://phpsos.de/pt/blog/automatische-sicherheitsupdates/).
4. **Planear o reinício:** O reinício dos serviços PHP faz parte fixa do procedimento, e não do acompanhamento posterior.
5. **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.
6. **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](https://phpsos.de/pt/blog/patch-management-prozess/).

## 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](https://phpsos.de/pt/leistungen/php-patch-service/).

## 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)