In breve: la finestra di tempo tra patch e attacco con PHP2Shell è stata negativa: secondo i rapporti dei media, c'è stato un primo tentativo di attacco già il 17 ottobre 2026, quattro giorni prima degli aggiornamenti. Per i gestori non conta quindi la domanda «Quanto tempo resta?», ma «Per quanto tempo il mio server è aperto?». Questa finestra personale termina solo quando l'aggiornamento è installato e tutti i processi PHP sono stati riavviati.
Il punto di partenza: attacchi prima della patch
Per lungo tempo è valsa un'ipotesi comoda: tra l'aggiornamento di sicurezza e i primi attacchi passano alcuni giorni, abbastanza tempo per la prossima finestra di manutenzione. PHP2Shell ha smentito questa ipotesi. Secondo i rapporti dei media che citano Amazon, un primo tentativo di attacco è stato osservato già il 17 ottobre. Anche Cloudflare ha riferito di attacchi precoci. Le patch sono arrivate il 21 ottobre alle 14:00 UTC.
Questo articolo spiega come nascono tali finestre di tempo e come accorciare la Sua. La sequenza esatta delle date è nella cronologia di PHP2Shell.
La finestra di tempo tra patch e attacco in fasi
Attorno a una vulnerabilità di sicurezza si possono distinguere più fasi. Con PHP2Shell si presentavano così:
| Fase | In generale | Con PHP2Shell |
|---|---|---|
| Prima della divulgazione | la vulnerabilità è nota solo agli scopritori e al produttore | sviluppo della correzione sotto embargo |
| Primi attacchi senza patch | gli aggressori sfruttano la vulnerabilità prima che esista un aggiornamento | secondo i rapporti dei media, primo tentativo il 17/10 |
| Preavviso | il produttore annuncia l'aggiornamento | 20/10, php.net annuncia il rilascio |
| Patch disponibile | escono aggiornamento e segnalazione di sicurezza | 21/10, 14:00 UTC |
| Analisi della patch | ricercatori e aggressori analizzano le modifiche | watchTowr ha riprodotto CVE-2026-109618 secondo le proprie dichiarazioni |
| Sfruttamento su larga scala | campagne automatizzate contro server privi di patch | atteso dal BSI; attacchi riusciti su larga scala confermati inizialmente non noti |
| La Sua patch | aggiornamento e riavvio sui Suoi server | individuale |
L'ultima riga è l'unica che Lei può influenzare. Tutto ciò che precede lo determinano altri.
Perché la patch stessa aumenta la pressione
Un aggiornamento di sicurezza chiude la vulnerabilità, ma al tempo stesso la rende visibile. Le modifiche al codice sorgente nei progetti open source come PHP sono pubbliche. Chi confronta le differenze tra la versione vecchia e quella nuova scopre dove si trovava l'errore. Non è un rimprovero al progetto PHP, ma la normalità del software aperto e il fondamento per cui le distribuzioni possono costruire backport.
Per i gestori ne consegue: a ogni giorno dopo la patch cresce il numero di chi sa come funziona la vulnerabilità. Allo stesso tempo scende il numero di server privi di patch. I rimanenti diventano così i bersagli più ovvi. Come PHP distribuisca gli aggiornamenti di sicurezza nell'ambito della cura delle versioni lo spiega l'articolo sul ciclo di rilascio di PHP.
Se il Suo server era raggiungibile tra il 17 ottobre e la Sua patch, serve una verifica delle tracce. Conservi i log dal 20 ottobre, prima che vadano persi per la rotazione.
Misurare la propria finestra di tempo
La Sua finestra personale inizia al più tardi con la pubblicazione delle patch e termina con il riavvio dell'ultimo processo PHP. Annoti per ogni server:
- Conoscenza: quando qualcuno in azienda è venuto a sapere della vulnerabilità?
- Disponibilità: quando era pronto il pacchetto della Sua distribuzione o del Suo hoster?
- Installazione: quando è stato installato?
- Riavvio: quando non giravano più vecchi processi PHP?
Proprio il riavvio viene spesso dimenticato. Un aggiornamento installato ha effetto solo quando i vecchi processi sono terminati. Come verificarlo lo descrive Riavviare PHP-FPM e tutti i processi PHP. Se girano ancora processi precedenti all'aggiornamento lo mostra uno sguardo agli orari di avvio:
# Mostrare l'orario di avvio di tutti i processi PHP
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Se l'orario di avvio è precedente all'installazione dell'aggiornamento, la finestra è ancora aperta.
Perché la Sua finestra dipende dal canale di approvvigionamento
Quanto in fretta può applicare la patch non dipende solo da Lei, ma anche da dove proviene il Suo PHP. Le distribuzioni hanno distribuito backport, secondo i rapporti, in parte già il 21 ottobre. Chi ottiene PHP da un repository di terze parti dipende dal suo ritmo. Chi usa container deve ricostruire e distribuire le immagini, un semplice aggiornamento nel container in esecuzione non basta. E con lo shared hosting è l'hoster a determinare il momento.
Se conosce il canale di approvvigionamento di ogni server, sa anche in quale punto la Sua finestra resta aperta più a lungo. Proprio lì la preparazione rende di più, ad esempio con un accordo con l'hoster o con una procedura collaudata per nuove immagini container.
Come accorciare la finestra di tempo la prossima volta
- Iscriversi alle segnalazioni: ricevere direttamente le segnalazioni di sicurezza di php.net e della Sua distribuzione, non solo tramite la stampa.
- Definire la responsabilità: per ogni server una persona responsabile con sostituto.
- Usare l'automazione dove si adatta: gli aggiornamenti di sicurezza della distribuzione possono essere installati automaticamente. Cosa lo favorisce e cosa lo sconsiglia lo descrive Aggiornamenti di sicurezza automatici.
- Pianificare il riavvio: il riavvio dei servizi PHP fa parte stabilmente della procedura, non del dopo.
- Preparare la via d'emergenza: pagina di emergenza e decisione su uno spegnimento temporaneo, se un aggiornamento non è subito possibile.
- Tenere la prova: documentare gli orari di installazione e riavvio, per poter poi dimostrare la Sua finestra.
Un processo permanente che riunisce questi punti è descritto nell'articolo sul processo di patch management.
Come aiuta concretamente PHP SOS?
- Patch e riavvio: installiamo l'aggiornamento e ci assicuriamo che non girino più vecchi processi PHP.
- Documentare la finestra: documentiamo installazione e riavvio di ogni server con l'orario.
- Verifica delle tracce: per il periodo in cui il Suo server era aperto conserviamo i log e cerchiamo anomalie.
- Processo per il futuro: definiamo con Lei canali di segnalazione, responsabilità e procedure di aggiornamento.
Maggiori informazioni nel servizio patch PHP.
Conclusione
Con PHP2Shell non c'è stato alcun periodo di tolleranza. La finestra di tempo tra patch e attacco è oggi, con le vulnerabilità critiche, spesso nulla o addirittura negativa. Ciò che può controllare è la Sua finestra: termina con il riavvio, e con la preparazione si può accorciare da giorni a ore.
Domande frequenti
Quanto tempo resta dopo un aggiornamento di sicurezza prima degli attacchi?
Non esiste un termine fisso. Con PHP2Shell, secondo i rapporti dei media, un primo tentativo di attacco è stato osservato già il 17 ottobre, quindi quattro giorni prima delle patch. Con vulnerabilità critiche in software diffuso dovrebbe partire dal presupposto che non esista praticamente alcun periodo di tolleranza.
Che cos'è uno zero-day?
Una vulnerabilità che viene attaccata prima che sia disponibile un aggiornamento. Il produttore ha avuto, per così dire, zero giorni per correggerla. In seguito si parla spesso di vulnerabilità nota o N-day, per la quale esiste già una patch.
Perché dopo una patch gli attacchi spesso aumentano?
Con la patch diventa pubblico dove si trovava l'errore. Ricercatori di sicurezza e aggressori possono analizzare le modifiche. Allo stesso tempo molti server restano ancora per giorni o settimane privi di patch e quindi bersagli redditizi.
Quando il mio server è davvero protetto?
Quando l'aggiornamento è installato e tutti i processi PHP sono stati riavviati. I nuovi file da soli non hanno effetto finché girano vecchi processi in memoria. La fine della Sua finestra personale è quindi il riavvio, non il download.