PHP2Shell, perché applicare le patch non basta a mettere in sicurezza i sistemi

Le correzioni per PHP2Shell sono disponibili, ma tra aggiornare un pacchetto e rendere sicuro un servizio c’è una differenza concreta.

Dall’inventario dei runtime alle immagini container, dai controlli dopo il rilascio all’analisi degli accessi sospetti, ecco le verifiche che servono alle organizzazioni per non fermarsi alla sola installazione degli aggiornamenti.

La patch è disponibile. Ma è davvero arrivata in produzione

Quando viene annunciata una vulnerabilità critica, la prima domanda è quasi sempre la stessa: «È uscita la patch?».

È una domanda necessaria, ma non sufficiente. Una correzione può essere già disponibile, persino installata su un server, senza essere stata caricata dal processo che continua a rispondere alle richieste degli utenti. Oppure può aver raggiunto una parte dell’infrastruttura, lasciando indietro una replica, un container o un servizio gestito da un fornitore esterno.

PHP2Shell rende particolarmente evidente questa distanza tra aggiornare e verificare.

Il 21 ottobre 2026 il progetto PHP ha corretto le vulnerabilità CVE-2026-109618 e CVE-2026-109619, entrambe classificate con un punteggio CVSS v4.0 di 9,2.

In determinate configurazioni possono consentire l’esecuzione di codice da remoto senza autenticazione. Il problema riguarda il runtime PHP, non necessariamente il codice di un sito o di un gestionale.

Secondo CERT-EU, devono quindi essere valutate tutte le installazioni che gestiscono richieste web, comprese quelle basate su Apache con mod_php, PHP-FPM e altre modalità di esecuzione. [1][2]

Le versioni ufficiali che contengono le correzioni sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i rami meno recenti, ormai fuori dal supporto ordinario del progetto, occorre verificare eventuali backport distribuiti dal fornitore oppure pianificare la migrazione.

Non tutti gli ambienti condividono la stessa facilità di sfruttamento, ma per quelli esposti a Internet la verifica non può essere rimandata. [1][2]

La questione centrale, a questo punto, non è ripetere come funzionano le due falle. È capire come un’organizzazione possa dimostrare che i servizi realmente utilizzati non le espongano più.

L’Europa concentra i tentativi di sfruttamento: i Paesi più colpiti

Secondo Check Point Research, il 22 ottobre 2026 i tentativi di sfruttamento di PHP2Shell hanno coinvolto il 10% delle organizzazioni considerate nel mondo: il 14% in Europa, il 6% in Nord America, America Latina e Asia-Pacifico e il 4% in Africa. Si tratta di tentativi rilevati, non di compromissioni accertate.

Tra i Paesi con l’incidenza più elevata figurano Ungheria (38%), Danimarca (32%) e Austria (28%), seguite da Svezia e Romania (22% ciascuna). Portogallo, Serbia e Thailandia registrano il 17%, Germania il 16% e Paesi Bassi il 15%. Seguono India (14%), Norvegia e Ucraina (13%); Repubblica Ceca, Polonia, Spagna, Svizzera e Regno Unito si attestano al 12%. Dei 18 Paesi con i valori più alti, 16 sono europei.

L’Italia registra il 10%, come Irlanda e Brasile, in linea con il dato mondiale.

Queste cifre descrivono l’attività osservata da un fornitore di sicurezza; la pubblicazione non fornisce elementi metodologici sufficienti per considerarle una misura rappresentativa di tutte le organizzazioni di ogni Paese.

Sono utili per comprendere la rapidità e la diffusione dei tentativi, ma non sostituiscono la valutazione tecnica del singolo ambiente.

Anche dove la percentuale risulta inferiore, la priorità va determinata in base ai servizi raggiungibili da Internet, alle versioni PHP effettivamente in uso e agli eventuali indizi di attacco.

Il primo errore è cercare PHP soltanto dove ci si aspetta di trovarlo

Una ricognizione che si limiti al sito istituzionale rischia di perdere buona parte del problema.

PHP può essere presente in portali interni, applicazioni sviluppate anni fa, strumenti amministrativi, interfacce fornite da terzi e prodotti nei quali il linguaggio non è immediatamente visibile a chi li utilizza.

Per questo CERT-EU rimanda anche alle informazioni operative raccolte dal centro nazionale di cybersicurezza dei Paesi Bassi, utili a individuare prodotti che incorporano PHP. [1][3]

L’inventario, però, deve andare oltre il nome dell’applicazione. Per ogni servizio è necessario ricostruire quale runtime lo esegue, dove si trova, come viene aggiornato e chi ne risponde.

Se il traffico passa attraverso un bilanciatore, bisogna conoscere tutte le istanze che possono riceverlo. Se sono presenti più pool PHP-FPM, non basta controllarne uno solo. E il comando php -v, spesso usato come prima verifica, può mostrare la versione dell’interprete da riga di comando anziché quella impiegata dal web server.

È una distinzione importante anche quando l’installazione di una patch sembra essere andata a buon fine.

Il pacchetto presente sul disco e il processo ancora in esecuzione non coincidono necessariamente: un worker avviato prima dell’aggiornamento potrebbe continuare a usare componenti già caricati.

Riavvii controllati e controlli sul servizio attivo fanno parte della correzione, non sono un dettaglio da lasciare alla fine.

Quando un rilascio successivo può riportare indietro la sicurezza

Immaginiamo un portale aziendale distribuito su più istanze. Gli amministratori aggiornano i server e il sito continua a funzionare. L’intervento sembra concluso.

Qualche giorno dopo, una normale distribuzione applicativa crea però nuove istanze partendo da un’immagine che contiene ancora il vecchio PHP.

La vulnerabilità, appena corretta, rientra nell’ambiente di produzione.

È un esempio ipotetico, ma descrive un rischio concreto dei processi di distribuzione: non basta correggere ciò che è in esecuzione se rimangono vulnerabili gli elementi con cui lo si ricrea.

Vanno controllate le immagini container, i template delle macchine virtuali, le dipendenze delle pipeline di integrazione e distribuzione continua e le eventuali copie di ripristino destinate a tornare online.

Google Cloud richiama esplicitamente la necessità di ricostruire e ridistribuire le immagini gestite dal cliente quando contengono un runtime vulnerabile. [4]

La verifica dopo un aggiornamento dovrebbe quindi seguire due percorsi. Il primo riguarda il presente: tutte le istanze che servono gli utenti eseguono PHP corretto? Il secondo riguarda il prossimo rilascio: le sorgenti da cui nasceranno nuove istanze contengono già la stessa correzione? Senza questa seconda risposta, la chiusura del problema è soltanto temporanea.

Per le installazioni che usano pacchetti con correzioni retroportate, la prova non coincide sempre con un numero di versione più alto. In questi casi contano il bollettino del distributore, l’identificativo della build e la verifica dell’effettiva presenza delle modifiche di sicurezza.

Anche per questo una semplice schermata con la versione installata può risultare insufficiente.

Il cloud non elimina la responsabilità di controllare gli aggiornamenti

L’utilizzo di un servizio cloud può semplificare la manutenzione, ma non implica che ogni componente venga aggiornato automaticamente.

La distinzione è documentata da Google Cloud: alcuni runtime gestiti di App Engine Standard ricevono le nuove immagini di base in modo automatico; in altri ambienti, come App Engine Flexible o servizi basati su immagini personalizzate, il cliente deve intervenire e ridistribuire.

Anche per Cloud Run il comportamento dipende dalle opzioni di aggiornamento dell’immagine di base e dalla modalità di distribuzione scelta. [4]

Il punto non è quale piattaforma sia migliore. È sapere chi aggiorna il runtime e come viene verificato il risultato.

La stessa applicazione può richiedere procedure differenti se passa da un
servizio interamente gestito a un container costruito internamente. Quando sono coinvolti fornitori di hosting, società di sviluppo o gestori di piattaforme, è quindi necessario distinguere chiaramente le rispettive attività.

Una risposta come «il provider si occupa della sicurezza» non basta per chiudere un rischio specifico. Occorre conoscere l’ambiente interessato, la correzione applicata, l’eventuale riavvio o nuova distribuzione e l’esito delle verifiche. È un’esigenza operativa prima ancora che contrattuale.

Aggiornare rapidamente, senza compromettere la continuità del servizio

La necessità di intervenire con urgenza non elimina il problema della disponibilità. Per un portale sanitario, una piattaforma di prenotazione o un gestionale utilizzato durante la giornata lavorativa, un aggiornamento mal pianificato può causare un’interruzione.

Rinviare indefinitamente, però, significa lasciare aperta l’esposizione.

La risposta più efficace è trattare l’operazione come un cambiamento controllato.

Dove l’architettura lo consente, si può verificare la compatibilità della nuova versione in un ambiente di test e poi distribuire progressivamente l’aggiornamento, controllando che le funzionalità essenziali continuino a operare.

Per i servizi con più repliche, un rilascio graduale può aiutare a ridurre l’interruzione, purché non lasci inutilmente in servizio nodi vulnerabili.

Anche il piano di ripristino va preparato con attenzione. Tornare a una vecchia immagine non corretta potrebbe riportare online proprio la vulnerabilità che si voleva eliminare.

In caso di problemi applicativi, la soluzione dovrebbe essere ripristinare una configurazione funzionante che mantenga le correzioni di sicurezza, oppure adottare misure di contenimento concordate mentre si completa l’intervento.

La logica è coerente con l’impostazione del NIST: il patch management non si esaurisce nell’installazione, ma comprende identificazione, priorità, distribuzione e verifica delle correzioni.

La continuità operativa non è un motivo per rinunciare alla sicurezza; è una condizione da governare durante l’intervento. [5]

Se non si può applicare subito la patch, occorre dichiarare il rischio residuo

l’isolamento delle applicazioni esposte dalle reti pubbliche fino alla correzione verificata.

Il PHP Security Team indica inoltre mitigazioni temporanee per alcuni percorsi di attacco, tra cui limitazioni delle dimensioni delle richieste e modifiche a specifiche opzioni di PHP.

Sono interventi che possono ridurre l’esposizione, ma non eliminano entrambe le vulnerabilità. [1][2]

Alcune impostazioni richiedono particolare prudenza. La configurazione memory_limit=-1, per esempio, viene indicata per ostacolare una specifica condizione di errore, ma può cambiare il comportamento del servizio rispetto al consumo di memoria.

Anche la disattivazione di session.upload_progress.enabled agisce soltanto su percorsi di sfruttamento confermati e deve essere applicata nel punto corretto della configurazione, con riavvio dei processi. Copiare queste indicazioni senza valutarne gli effetti potrebbe introdurre altri problemi. [2]

I firewall applicativi web, o WAF, possono aggiungere una difesa utile. Cloudflare ha annunciato regole specifiche per PHP2Shell; Google Cloud, parlando di Cloud Armor, ricorda però che richieste particolarmente grandi possono superare i limiti di ispezione configurati.

Le nuove regole vanno quindi testate e accompagnate da controlli sulle dimensioni del traffico, senza considerarle una garanzia assoluta. [4][6]

In termini di gestione, ogni eccezione dovrebbe avere un responsabile, una motivazione, misure compensative e una scadenza.

La formula «protetto dal WAF» non dovrebbe mai sostituire la risposta alla domanda «quando sarà applicata la correzione?».

Cercare gli attacchi anche prima del giorno della divulgazione

Una delle indicazioni più importanti emerse dopo la pubblicazione delle patch riguarda il periodo da analizzare.

Amazon Threat Intelligence ha riferito di aver osservato, attraverso la propria rete di sistemi-esca MadPot, un tentativo di sfruttamento riconducibile a PHP2Shell già il 17 ottobre 2026, quattro giorni prima della divulgazione pubblica.

Amazon ha inoltre segnalato ulteriori tentativi nei giorni successivi. Si tratta di osservazioni del fornitore su sistemi predisposti per rilevare attività ostili, non della prova che quei tentativi abbiano compromesso server di organizzazioni reali. [7]

Questa distinzione è essenziale, ma lo è anche la conseguenza pratica: per stabilire da quando esaminare i log non basta prendere come punto di partenza il giorno in cui è uscita la patch.

Dove i dati sono disponibili, ha senso includere nella ricerca almeno la finestra temporale indicata dalle prime osservazioni pubbliche e ampliarla se emergono indizi precedenti o specifici per l’ambiente.

Anche Cloudflare ha dichiarato di aver rilevato richieste di attacco e tentativi di adattarle alle proprie protezioni. [6][7]

La ricerca non dovrebbe affidarsi a un solo indicatore. Richieste HTTP anomale, errori ripetuti, riavvii inattesi dei processi, file modificati senza motivo e connessioni in uscita insolite possono giustificare ulteriori verifiche. Nessuno di questi segnali, isolatamente, dimostra una compromissione. L’analisi diventa più affidabile quando si collegano i dati del web server, del WAF, del sistema operativo e degli strumenti di sicurezza dei server.

Patch applicata e incidente chiuso sono due cose diverse

Se emergono elementi credibili di intrusione, l’attività non può fermarsi all’aggiornamento di PHP.

La correzione impedisce lo sfruttamento delle falle sistemate, ma non cancella file eventualmente modificati, credenziali sottratte o accessi persistenti introdotti in precedenza.

In una situazione del genere, la priorità è preservare i dati utili all’indagine, definire il possibile periodo di esposizione, verificare l’integrità del sistema e comprendere quali risorse fossero accessibili al processo compromesso.

Se necessario, occorre valutare la sostituzione di password, token e chiavi, e ripristinare il servizio su un ambiente attendibile.

L’approccio rispecchia le raccomandazioni del NIST sull’integrazione della risposta agli incidenti nei processi di gestione del rischio e ripristino. [8]

Anche qui la documentazione conta. È utile registrare le verifiche svolte, le evidenze raccolte, le decisioni prese e le ragioni per cui un evento è stato classificato come innocuo o sospetto.

Non serve trasformare ogni errore del server in un incidente; serve poter spiegare perché un segnale sia stato approfondito oppure escluso.

La vera chiusura è una prova, non una dichiarazione

Alla fine dell’emergenza, per ogni servizio interessato dovrebbe essere possibile rispondere a poche domande concrete: quale componente PHP era presente, quale correzione è stata applicata, quali processi o immagini sono stati sostituiti, chi ha verificato il funzionamento e se siano stati esaminati eventuali segnali di attacco.

Se una parte del sistema rimane esposta, bisogna sapere perché, per quanto tempo e con quali controlli temporanei.

Queste informazioni possono essere raccolte in un semplice registro di intervento condiviso tra responsabili IT, sicurezza, sviluppatori e fornitori. Non servono documenti inutilmente complessi.

Serve però una traccia verificabile, capace di distinguere i sistemi corretti da quelli ancora in attesa e di impedire che una versione vulnerabile venga reintrodotta al rilascio successivo.

PHP2Shell, in definitiva, mette in evidenza una fragilità che va ben oltre PHP: la distanza tra la disponibilità di una soluzione tecnica e la capacità di portarla, verificarla e mantenerla in tutti gli ambienti che erogano un servizio.

Una vulnerabilità non è davvero gestita quando qualcuno dichiara di aver aggiornato, ma quando l’organizzazione può dimostrare che la correzione
è operativa e che l’eventuale esposizione precedente è stata valutata.

Fonti e riferimenti

Informazioni tecniche e segnalazioni aggiornate al 22 ottobre 2026. Le indicazioni organizzative rappresentano una proposta operativa elaborata sulla base delle fonti riportate.

1. CERT-EU, Security Advisory 2026-018 – Critical Vulnerabilities in PHP, 21 ottobre 2026.
2. PHP Security Team, Critical remote code execution vulnerabilities, update now, 21 ottobre 2026.
3. NCSC-NL, php2shell – Operational information regarding the 2026 vulnerabilities.
4. Google Cloud, Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619, 21 ottobre 2026.
5. NIST, SP 800-40 Rev. 4 – Guide to Enterprise Patch Management Planning, aprile 2022.
6. Cloudflare, Cloudflare deploys protections against php2shell vulnerability, 21 ottobre 2026.
7. Amazon Threat Intelligence, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, 21 ottobre 2026.
8. NIST, SP 800-61 Rev. 3 – Incident Response Recommendations and Considerations for Cybersecurity Risk Management, aprile 2025.