# Cronologia PHP2Shell: date dal 17 al 25 ottobre 2026

> La cronologia PHP2Shell in sintesi: dal primo tentativo di attacco del 17/10 allo stato del 25/10/2026. Che cosa significa ogni data per i Suoi log.

Fonte: https://phpsos.de/it/ratgeber/php2shell-chronologie/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** la cronologia di PHP2Shell comprende finora quattro date documentate: un primo tentativo di attacco osservato il 17/10, il preavviso di php.net il 20/10, le patch il 21/10 alle 16:00 ora tedesca e un ulteriore avviso su CVE-2026-115560 il 23/10/2026. Per i gestori ne consegue: applicare la patch, riavviare tutti i processi PHP e mettere al sicuro i log al più tardi dal 20/10.

## Perché una cronologia di PHP2Shell conta per i gestori

Con una vulnerabilità di questa gravità non conta solo se il Suo server oggi è aggiornato. Conta anche per quanto tempo prima è stato vulnerabile. Questo intervallo determina quali log mettere al sicuro, quali file controllare e se si possa escludere con buone ragioni una compromissione.

PHP2Shell riguarda PHP stesso, non un singolo CMS. Due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, consentono l'esecuzione di codice dannoso da remoto senza autenticazione. Entrambe sono valutate con CVSS v4.0 9,2. Un'introduzione comprensibile è disponibile in [Che cos'è PHP2Shell?](https://phpsos.de/it/php2shell/was-ist-php2shell/).

La cronologia che segue contiene solo date documentate allo stato del 25/10/2026. Dove un'informazione si basa su notizie dei media, lo si indica.

| Data | Evento | Base |
|---|---|---|
| 17/10/2026 | Primo tentativo di attacco osservato (Amazon) | notizie dei media |
| 20/10/2026 | Preavviso da parte di php.net | php.net |
| 21/10/2026, 14:00 UTC | Pubblicazione delle patch (16:00 ora tedesca) | php.net |
| 23/10/2026 | Avviso su CVE-2026-115560 | php.net |
| 25/10/2026 | Stato di questa panoramica | – |

## 17 ottobre: il primo tentativo di attacco osservato

Secondo le notizie dei media, il 17/10/2026 è stato osservato un primo tentativo di attacco, segnalato da Amazon. Ciò è avvenuto quattro giorni prima delle patch. Ci fu quindi un periodo in cui si tentavano già attacchi, ma non esisteva ancora alcun aggiornamento.

Se e quanti attacchi abbiano avuto successo in questa fase non è documentato. Per il Suo controllo ne deriva una conseguenza importante: un server oggi aggiornato può essere stato compromesso in precedenza. Una patch non rimuove il malware introdotto e non dimostra che prima non sia successo nulla.

## 20 e 21 ottobre: preavviso e patch

Il 20/10/2026 il progetto PHP ha annunciato su php.net gli aggiornamenti di sicurezza. Il 21/10/2026 alle 14:00 UTC, cioè alle 16:00 ora tedesca, sono seguite le versioni corrette.

| Ramo | Ultimo stato vulnerabile | Corretta in |
|---|---|---|
| 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 |

Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali, solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4. Sono interessate le modalità di esecuzione PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto è indicato dal team PHP per mod_php, dove è stato dimostrato un exploit prima ancora che venga eseguito il codice dell'applicazione.

Distribuzioni e hoster inseriscono talvolta dei backport. In tal caso Plesk, ad esempio, continua a mostrare 8.2.34 anche se il server è aggiornato. Contano lo stato dei pacchetti e la conferma del fornitore, non il numero di versione visualizzato. Come verificarlo correttamente è spiegato in [Verificare correttamente la versione di PHP e lo stato delle patch](https://phpsos.de/it/php2shell/php-version-pruefen/).

## 23 ottobre: avviso su CVE-2026-115560

Il 23/10/2026 il progetto PHP ha pubblicato un ulteriore avviso, questa volta su CVE-2026-115560. Secondo questo, lo sfruttamento è possibile solo con una configurazione insolita: nella configurazione compare il serialize_handler `php_binary` o `php_serialize`, l'applicazione lo riporta a `php` con `ini_set()` prima di `session_start()` e il session upload progress è attivo.

La misura è semplice e va applicata a prescindere dal fatto che Lei conosca o meno questa situazione nel proprio sistema:

```ini
; nel php.ini, nel pool FPM o nella configurazione del server
; non tramite ini_set() o .user.ini
session.upload_progress.enabled = 0
```

Poi riavviare tutti i worker PHP. L'avviso completo dovrebbe seguire con il prossimo release regolare di correzione. Fino ad allora l'impostazione resta la soluzione provvisoria raccomandata.

## Stato al 25 ottobre: situazione e questioni aperte

Il BSI (Ufficio federale tedesco per la sicurezza informatica) ha dichiarato il livello di allerta 3 / arancione. Raccomanda l'aggiornamento immediato e, se non è possibile subito, di scollegare temporaneamente i server web dalla rete. Il BSI prevedeva uno sfruttamento rapido e su larga scala; secondo il BSI, attacchi riusciti confermati su vasta scala non erano inizialmente noti. L'inquadramento del BSI è riassunto nella pagina [Che cosa raccomanda il BSI su PHP2Shell](https://phpsos.de/it/compliance/bsi-empfehlungen/).

Cloudflare ha segnalato tentativi di attacco osservati e ha rilasciato regole di protezione, avvertendo però che le regole basate solo sui dati della richiesta non bastano. Palo Alto Networks (Unit 42) ha contato più di 22,6 milioni di istanze esposte e potenzialmente vulnerabili. Non sono stati pubblicati Indicators of Compromise confermati; il rilevamento si basa sull'analisi del comportamento.

Alcuni fornitori hanno messo offline i siti in via precauzionale. Ciò non significa automaticamente che questi siti siano stati violati. Allo stato di questa panoramica resta aperta soprattutto la questione di quanti server siano stati effettivamente compromessi nel periodo precedente alla patch.

## Che cosa significa la cronologia per i Suoi log e controlli

Dalle date risultano tre periodi: prima del 17/10, tra il 17/10 e il momento della Sua patch e del riavvio, e dopo. Il periodo intermedio è quello critico. Quanto più è durato nel Suo caso, tanto più accurato dovrebbe essere il controllo.

> **Importante:**
> La stampa specializzata consiglia di conservare i log del server a partire dal 20/10/2026. Metta al sicuro anche i log più vecchi ancora disponibili, prima che la rotazione automatica li cancelli.

Un modo semplice per salvare i log senza modificarli e documentare lo stato:

```bash
# Salvare i log in un archivio (adattare i percorsi al proprio sistema)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Checksum per la prova successiva
sha256sum /root/logs-sicherung-*.tar.gz
# Per quanto tempo il sistema conserva i log?
grep -R "rotate" /etc/logrotate.d/
```

Annoti inoltre quando esattamente l'aggiornamento è stato installato e quando i processi PHP sono stati riavviati. I file nuovi da soli non proteggono finché in memoria girano ancora vecchi processi. Come analizzare i log salvati è descritto nella guida [Analizzare i log del server web dopo un attacco](https://phpsos.de/it/ratgeber/logfiles-auswerten/).

## Come aiuta concretamente PHP SOS?

- Con Lei determiniamo l'effettiva finestra di vulnerabilità del Suo server: stato dei pacchetti, momento della patch, riavvio di tutti i worker.
- Mettiamo al sicuro log e stato del sistema in modo tracciabile, prima di modificare qualsiasi cosa.
- Verifichiamo la presenza di anomalie di comportamento come nuovi file PHP, processi estranei e connessioni in uscita insolite.
- Documentiamo il risultato in modo che direzione, responsabili della protezione dei dati e assicuratori possano lavorarci.

Il procedimento nei dettagli è descritto nel nostro [Pronto intervento PHP2Shell](https://phpsos.de/it/leistungen/php2shell-soforthilfe/).


## Domande frequenti

**Quando sono state pubblicate le patch di PHP2Shell?**  
Il progetto PHP ha pubblicato le versioni corrette il 21/10/2026 alle 14:00 UTC, cioè alle 16:00 ora tedesca. Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

**Da quale data dovrei conservare i log del server?**  
La stampa specializzata consiglia di conservare i log a partire dal 20/10/2026. Poiché secondo i media un primo tentativo di attacco è stato osservato già il 17/10, conviene mettere al sicuro anche i log più vecchi ancora disponibili, prima che la rotazione li cancelli.

**CVE-2026-115560 è pericolosa quanto le prime due vulnerabilità?**  
Secondo l'avviso del 23/10/2026 lo sfruttamento è possibile solo con una configurazione di sessione insolita. Come misura vale session.upload_progress.enabled=0, fino alla pubblicazione del prossimo release regolare di correzione.

**Esistono Indicators of Compromise confermati per PHP2Shell?**  
No, allo stato del 25/10/2026 non sono stati pubblicati Indicators of Compromise confermati. Il rilevamento si basa sull'analisi del comportamento, ad esempio processi insoliti, file nuovi e connessioni anomale.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Ufficio federale tedesco per la sicurezza informatica](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)