# Cronologia do PHP2Shell: de 17 a 25 de outubro de 2026

> A cronologia do PHP2Shell em resumo: da primeira tentativa de ataque a 17/10 até ao estado de 25/10/2026. O que cada data significa para os seus registos.

Fonte: https://phpsos.de/pt/ratgeber/php2shell-chronologie/  
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 cronologia do PHP2Shell conta, até agora, quatro datas comprovadas: uma primeira tentativa de ataque observada a 17/10, o pré-aviso do php.net a 20/10, os patches a 21/10 às 16:00 na hora alemã e um novo aviso sobre o CVE-2026-115560 a 23/10/2026. Para os operadores, daqui resulta: aplicar o patch, reiniciar todos os processos PHP e guardar os registos o mais tardar a partir de 20/10.

## Porque é que uma cronologia do PHP2Shell importa aos operadores

Perante uma vulnerabilidade desta gravidade, não conta apenas se o seu servidor está hoje corrigido. Decisivo é também durante quanto tempo esteve vulnerável antes. Esta janela determina que registos deve guardar, que ficheiros deve verificar e se pode excluir um comprometimento com boas razões.

O PHP2Shell afeta o próprio PHP, não um CMS em particular. Duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, permitem a execução remota de código malicioso sem autenticação. Ambas têm a classificação 9,2 no CVSS v4.0. Uma introdução compreensível encontra-a em [O que é o PHP2Shell?](https://phpsos.de/pt/php2shell/was-ist-php2shell/).

A cronologia seguinte contém apenas datas comprovadas a 25/10/2026. Quando uma indicação se baseia em notícias dos meios de comunicação, isso fica assinalado.

| Data | Acontecimento | Base |
|---|---|---|
| 17/10/2026 | Primeira tentativa de ataque observada (Amazon) | Notícias dos meios de comunicação |
| 20/10/2026 | Pré-aviso do php.net | php.net |
| 21/10/2026, 14:00 UTC | Publicação dos patches (16:00 na hora alemã) | php.net |
| 23/10/2026 | Aviso sobre o CVE-2026-115560 | php.net |
| 25/10/2026 | Estado desta vista geral | – |

## 17 de outubro: a primeira tentativa de ataque observada

Segundo notícias dos meios de comunicação, a 17/10/2026 foi observada uma primeira tentativa de ataque, comunicada pela Amazon. Isto aconteceu quatro dias antes dos patches. Houve, portanto, um período em que já se tentavam ataques, mas ainda não existia atualização.

Não está comprovado se, nem quantos, ataques tiveram êxito nesta fase. O que importa é a consequência para a sua própria verificação: um servidor que hoje está corrigido pode ter sido comprometido antes. Um patch não remove software malicioso introduzido e não prova que antes não aconteceu nada.

## 20 e 21 de outubro: pré-aviso e patches

A 20/10/2026, o projeto PHP anunciou no php.net as atualizações de segurança. A 21/10/2026 às 14:00 UTC, ou seja, às 16:00 na hora alemã, seguiram-se as versões corrigidas.

| Ramo | Última versão vulnerável | Corrigido em |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |

Para o PHP 8.1 e anteriores já não existem atualizações oficiais, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Segundo a imprensa especializada, quase todas as versões até ao PHP 5.4 estão afetadas. Estão afetados os modos de operação PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O maior risco, segundo a equipa do PHP, está no mod_php, onde foi demonstrado um exploit antes sequer de correr código da aplicação.

As distribuições e os fornecedores de alojamento instalam por vezes backports. Nesse caso, o Plesk, por exemplo, continua a mostrar 8.2.34, embora o servidor esteja corrigido. O que conta é o estado dos pacotes e a confirmação do fornecedor, não o número de versão apresentado. Como o verificar corretamente, vê-se em [Verificar corretamente a versão do PHP e o nível de patch](https://phpsos.de/pt/php2shell/php-version-pruefen/).

## 23 de outubro: aviso sobre o CVE-2026-115560

A 23/10/2026, o projeto PHP publicou um novo aviso, desta vez sobre o CVE-2026-115560. Segundo este, a exploração só é possível com uma configuração invulgar: na configuração consta o serialize_handler `php_binary` ou `php_serialize`, a aplicação muda-o para `php` com `ini_set()` antes de `session_start()` e o session upload progress está ativo.

A mitigação é simples e deve ser aplicada independentemente de conhecer ou não esta constelação no seu caso:

```ini
; no php.ini, no pool FPM ou na configuração do servidor
; não através de ini_set() nem de .user.ini
session.upload_progress.enabled = 0
```

Depois, reinicie todos os workers do PHP. O aviso completo deverá seguir com a próxima versão regular de correção de erros. Até lá, esta definição continua a ser a solução transitória recomendada.

## Estado a 25 de outubro: situação e questões em aberto

O BSI declarou o nível de alerta 3 / laranja. Recomenda a atualização imediata e, se esta não for possível de imediato, retirar temporariamente os servidores web da rede. O BSI (Serviço Federal Alemão para a Segurança da Informação) esperava uma exploração rápida e em larga escala; ataques bem-sucedidos confirmados em grande número não eram, segundo o BSI, inicialmente conhecidos. A avaliação do BSI está resumida na página [O que o BSI recomenda sobre o PHP2Shell](https://phpsos.de/pt/compliance/bsi-empfehlungen/).

A Cloudflare comunicou tentativas de ataque observadas e lançou regras de proteção, mas avisa que regras baseadas apenas nos dados do pedido não são suficientes. A Palo Alto Networks (Unit 42) contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis. Não há Indicators of Compromise confirmados publicados; a deteção assenta na análise de comportamento.

Alguns fornecedores retiraram sites do ar por precaução. Isso não significa automaticamente que esses sites tenham sido pirateados. Na data desta vista geral, a questão sobretudo em aberto é quantos servidores foram realmente comprometidos no período anterior ao patch.

## O que a cronologia significa para os seus registos e verificações

Dos dados resultam três períodos: antes de 17/10, entre 17/10 e o momento do seu próprio patch e reinício, e depois. O período intermédio é o crítico. Quanto mais tempo durou no seu caso, mais minuciosa deve ser a verificação.

> **Importante:**
> A imprensa especializada aconselha a guardar os registos do servidor a partir de 20/10/2026. Proteja também os registos mais antigos que existam, antes de a rotação automática os apagar.

Uma forma simples de guardar os registos sem os alterar e de registar o estado:

```bash
# Guardar os registos de uma só vez (adapte os caminhos ao seu sistema)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Soma de verificação para comprovação posterior
sha256sum /root/logs-sicherung-*.tar.gz
# Durante quanto tempo o sistema conserva registos?
grep -R "rotate" /etc/logrotate.d/
```

Anote também quando exatamente a atualização foi instalada e quando os processos PHP foram reiniciados. Ficheiros novos não protegem enquanto processos antigos correrem na memória. Como analisar os registos guardados, descreve-o o guia [Analisar os registos do servidor web após um ataque](https://phpsos.de/pt/ratgeber/logfiles-auswerten/).

## Como ajuda concretamente a PHP SOS?

- Determinamos consigo a janela real de vulnerabilidade do seu servidor: estado dos pacotes, momento do patch, reinício de todos os workers.
- Guardamos registos e estado do sistema de forma rastreável, antes de alterar o que quer que seja.
- Verificamos comportamentos invulgares, como novos ficheiros PHP, processos estranhos e ligações de saída anormais.
- Documentamos o resultado de modo a que a gestão, os encarregados da proteção de dados e as seguradoras possam trabalhar com ele.

O procedimento em pormenor está descrito na nossa [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).


## Perguntas frequentes

**Quando foram publicados os patches do PHP2Shell?**  
O projeto PHP publicou as versões corrigidas a 21/10/2026 às 14:00 UTC, ou seja, às 16:00 na hora alemã. Foram corrigidas as versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

**A partir de que data devo guardar os registos do servidor?**  
A imprensa especializada aconselha a guardar os registos a partir de 20/10/2026. Como, segundo relatos dos meios de comunicação, já a 17/10 foi observada uma primeira tentativa de ataque, vale a pena proteger também os registos mais antigos que ainda existam, antes de a rotação os apagar.

**O CVE-2026-115560 é tão perigoso como as duas primeiras vulnerabilidades?**  
Segundo o aviso de 23/10/2026, a exploração só é possível com uma configuração de sessão invulgar. Como medida de mitigação, aplica-se session.upload_progress.enabled=0 até sair a próxima versão regular de correção de erros.

**Existem Indicators of Compromise confirmados para o PHP2Shell?**  
Não. Em 25/10/2026 não há Indicators of Compromise confirmados publicados. A deteção assenta na análise de comportamento, por exemplo processos invulgares, ficheiros novos e ligações suspeitas.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI (Serviço Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)