Oltre l'Aggiornamento: La Guida Completa per Mettere in Sicurezza i Servizi PHP dopo le Vulnerabilità "PHP2Shell"
Le correzioni per le vulnerabilità critiche note come PHP2Shell sono state rilasciate, ma è fondamentale comprendere che l'installazione di una patch è solo il primo passo per garantire la sicurezza di un servizio. C'è una differenza sostanziale tra aggiornare un pacchetto software e rendere effettivamente sicuro un intero ecosistema applicativo. Dalla gestione dell'inventario dei runtime alla messa in sicurezza delle immagini container, dai controlli post-rilascio all'analisi degli accessi sospetti, ecco una guida completa sulle verifiche indispensabili per le organizzazioni che non vogliono fermarsi alla sola installazione degli aggiornamenti.
La patch è disponibile, ma è davvero in produzione?
Quando viene annunciata una vulnerabilità critica, la prima reazione è spesso la ricerca febbrile della patch. È una domanda cruciale, ma non sufficiente. Una correzione può essere disponibile, persino installata su un server, senza essere stata caricata dal processo attivo 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 mette in luce proprio 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 con un punteggio CVSS v4.0 di 9,2. In determinate configurazioni, queste falle possono consentire l'esecuzione di codice da remoto senza autenticazione. Il problema riguarda il runtime PHP stesso, non necessariamente il codice di un sito o di un'applicazione specifica. Secondo il CERT-EU, è necessario valutare tutte le installazioni che gestiscono richieste web, comprese quelle basate su Apache con mod_php, PHP-FPM e altre modalità di esecuzione. Le versioni ufficiali contenenti le correzioni sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i rami più vecchi, ormai fuori dal supporto ordinario, occorre verificare eventuali backport distribuiti dai fornitori o pianificare una migrazione.
Sebbene non tutti gli ambienti presentino la stessa facilità di sfruttamento, per quelli esposti a Internet la verifica è indifferibile. La questione centrale non è quindi replicare il funzionamento delle falle, ma capire come un'organizzazione possa dimostrare che i servizi realmente utilizzati non siano più esposti.
L'Europa nel mirino: i Paesi più colpiti
Secondo Check Point Research, il 22 ottobre 2026 i tentativi di sfruttamento di PHP2Shell hanno coinvolto il 10% delle organizzazioni monitorate a livello globale: il 14% in Europa, il 6% in Nord America, America Latina e Asia-Pacifico, e il 4% in Africa. È importante sottolineare che si tratta di tentativi rilevati, non di compromissioni confermate. 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%, la Germania il 16% e i Paesi Bassi il 15%. Seguono India (14%), Norvegia e Ucraina (13%); Repubblica Ceca, Polonia, Spagna, Svizzera e Regno Unito si attestano al 12%. Sorprendentemente, 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 riflettono l'attività osservata da un fornitore di sicurezza e, pur non essendo una misura rappresentativa di tutte le organizzazioni a livello globale, sono utili per comprendere la rapidità e la diffusione dei tentativi di attacco. Non sostituiscono, tuttavia, la valutazione tecnica del singolo ambiente. Anche dove la percentuale è inferiore, la priorità va data ai servizi raggiungibili da Internet, alle versioni PHP effettivamente in uso e agli eventuali indizi di attacco.
I settori più colpiti
Il tasso di impatto più alto, pari al 20% (il doppio della media globale), riguarda le telecomunicazioni, seguite dall'istruzione (18%). Media e intrattenimento e associazioni non profit registrano il 16% ciascuno. Agricoltura, trasporti e logistica si fermano al 14%, seguiti da software e sanità (13%). L'IT registra il 12% e i servizi alle imprese l'11%. Immobiliare, noleggio, automotive, aerospazio, produzione industriale e pubblica amministrazione registrano il 9% ciascuno. Hardware, beni di consumo, servizi finanziari e costruzioni si fermano all'8%. Commercio e grande distribuzione registrano il 7%, mentre energia e utility, ospitalità e attività ricreative il 6%. Biotecnologie e farmaceutica registrano il tasso più basso, pari al 5%.
Il primo errore: cercare PHP solo dove ci si aspetta di trovarlo
Una ricognizione limitata al sito istituzionale rischia di tralasciare una parte significativa del problema. PHP può essere presente in portali interni, vecchie applicazioni, strumenti amministrativi, interfacce fornite da terzi e prodotti in cui il linguaggio non è immediatamente visibile. Per questo motivo, il CERT-EU rimanda anche alle informazioni operative raccolte dal centro nazionale di cybersicurezza dei Paesi Bassi, utili per individuare prodotti che incorporano PHP.
L'inventario, tuttavia, deve andare oltre il semplice nome dell'applicazione. Per ogni servizio è necessario ricostruire quale runtime lo esegue, dove si trova, come viene aggiornato e chi ne è responsabile. 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. Spesso il comando php -v, utilizzato come prima verifica, mostra 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 utilizzare 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ò compromettere 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 nuove istanze partendo da un'immagine che contiene ancora il vecchio PHP vulnerabile. La vulnerabilità, appena corretta, rientra nell'ambiente di produzione. Questo esempio ipotetico 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. La verifica dopo un aggiornamento dovrebbe quindi seguire due percorsi. Il primo riguarda il presente: tutte le istanze che servono gli utenti eseguono il 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 è solo temporanea. Per le installazioni che utilizzano 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 motivo, 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 automaticamente; 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.
Il punto non è quale piattaforma sia migliore, ma 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, è necessario distinguere chiaramente le rispettive attività. Una risposta come "il provider si occupa della sicurezza" non è sufficiente 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à del servizio. 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, tuttavia, 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.
Mitigazioni temporanee e gestione del rischio residuo
Se non si può applicare subito la patch, occorre dichiarare il rischio residuo, motivando la decisione e definendo misure compensative. Il CERT-EU e altri organismi di sicurezza raccomandano, in assenza di patch, 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à.
Alcune impostazioni richiedono particolare prudenza. La configurazione memory_limit=-1, ad 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 solo 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. I firewall applicativi web (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.
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.
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.
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.
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.
