Il 21 ottobre è uscita la correzione per due vulnerabilità di PHP, il linguaggio su cui gira una parte enorme dei siti che usiamo ogni giorno, e nel giro di poche ore se ne è parlato ovunque, anche fuori dagli ambienti tecnici. Le hanno battezzate PHP2Shell, e il motivo di tanto rumore è semplice: sono due falle gravi, sfruttabili da chiunque senza bisogno di una password, e qualcuno aveva già iniziato a sfruttarle prima che la correzione fosse disponibile.
Cosa è successo
Le due vulnerabilità (CVE-2026-109618 e CVE-2026-109619, entrambe con punteggio di gravità 9,2 su 10) sono nel motore di PHP, non nel codice di un singolo sito. Questo cambia parecchio le cose: un sito scritto benissimo, con un'amministrazione protetta e tutti i plugin aggiornati, può essere comunque esposto, perché il problema si presenta prima ancora che il codice del sito entri in gioco. Secondo l'analisi di Sansec il codice coinvolto esiste dalla versione 5.4, cioè dal 2012.
La cronologia è la parte che mi ha colpito di più. Stando alle ricostruzioni, il 17 ottobre un sistema civetta di Amazon (un honeypot) ha registrato un primo tentativo di sfruttamento, il 20 i dettagli sono trapelati, la mattina del 21 Cloudflare ha segnalato i primi attacchi e solo nel primo pomeriggio sono arrivate le versioni corrette, la 8.2.35, la 8.3.36, la 8.4.27 e la 8.5.12 (dettagli in Help Net Security). In pratica per qualche giorno chi voleva approfittarne era un passo avanti a chi doveva difendersi, ed è una situazione che nel mio lavoro non è affatto rara, ma di solito è meno visibile.
C'è poi il capitolo delle versioni vecchie. Il PHP 8.1 e quelle precedenti non ricevono più correzioni dal progetto ufficiale: per le 7.4, 8.0 e 8.1 è stato pubblicato un backport minimo da compilare a mano, e alcune distribuzioni hanno rilasciato i propri pacchetti, ma chi usa un sistema senza più supporto, e sono tanti, deve decidere cosa fare.
Il ruolo dell'intelligenza artificiale
Secondo quanto riportato da Fortune, il difetto è stato trovato ad agosto da un ricercatore della società di sicurezza Calif con l'aiuto di un modello di OpenAI. Il dato interessante sta qui, e vale per i prossimi anni: un modello di questo tipo legge una quantità di codice che a una persona richiederebbe mesi, e individua schemi anomali in ore o in giorni. Lo stesso strumento, però, è a disposizione anche di chi attacca, e un difetto che prima restava nascosto per anni perché nessuno aveva il tempo di cercarlo ora può emergere da una settimana all'altra.
I numeri vanno nella stessa direzione, con qualche cautela. Il FIRST, l'organizzazione che raccoglie i gruppi di risposta agli incidenti informatici, prevede per il 2026 circa 66.000 vulnerabilità catalogate, e attribuisce l'aumento in gran parte agli strumenti di ricerca basati sull'IA. Una parte di quella crescita dipende anche da archivi che hanno recuperato record vecchi, quindi non prenderei il totale come una misura esatta di quanto sia peggiorato il mondo, mentre la tendenza è chiara. Sarà normale ricevere più avvisi, più spesso e con meno preavviso, e la maggior parte non riguarderà noi, ma ogni tanto ne arriverà una come questa.
Cosa vuol dire gestirla
Quando esce una vulnerabilità del genere la domanda che conta è una sola, ed è quanto tempo passa fra l'avviso e la messa in sicurezza. Il tempo si guadagna prima, con un inventario aggiornato di quale versione di PHP gira su quale sistema, perché se devi scoprirlo in quel momento hai già perso le ore che servivano. Con quello in mano il lavoro si divide in due.
Dove si può aggiornare, si aggiorna, un sistema alla volta e in un momento tranquillo, perché anche un semplice riavvio del servizio PHP può far fallire qualche richiesta in corso e va fatto con criterio. Poi si controllano i log per verificare che il passaggio non abbia lasciato strascichi.
Dove non si può, perché un'applicazione vecchia può non funzionare su una versione nuova di PHP, o perché il sistema è così datato che non esistono più i repository per aggiornarlo, si lavora per ridurre la superficie di rischio, cioè le strade che l'attaccante può percorrere. Alcune mitigazioni sono configurazioni aggiuntive, come disattivare una funzione di PHP che nei siti serve di rado (dopo aver controllato che nessuno la usi). Altre stanno fuori da PHP: regole sul firewall applicativo, quando c'è, oppure una password messa a livello di web server su un sito vecchio che serve a poche persone, così la richiesta viene respinta prima di arrivare a PHP.
Servono anche giudizio e un po' di coraggio nel dire di no, perché non tutte le mitigazioni che circolano sono buone. Fra quelle suggerite nei primi giorni ce n'era una che toglie il limite di memoria a PHP: su una macchina piccola con molti processi significa che una sola richiesta può esaurire la memoria di tutto il server, e il rimedio costa più del problema. Meglio un'altra strada, anche meno comoda. Resta il fatto che le mitigazioni servono ad arrivare alla soluzione vera, che è aggiornare o migrare, senza restare esposti nel frattempo.
Per quello che ho visto io, il giorno dopo il rilascio le prime misure erano già provate su sistemi in produzione, e nel giro di due giorni erano applicate dove servivano, con la verifica dell'effetto sui log. Succede così perché la reazione fa parte della routine, con gli strumenti già pronti e le procedure già scritte.
Accorgersi prima che la vulnerabilità abbia un nome
Una parte del lavoro comincia molto prima dell'avviso, ed è quella che il cliente vede meno. In questo caso, come in tanti altri, esiste un periodo in cui la falla è già nelle mani di qualcuno ma per tutti gli altri non esiste ancora: nessun numero di CVE, nessuna correzione, nessuna notizia. In quel periodo l'unica cosa che può fare la differenza è accorgersi che qualcosa non va.
Per questo una gestione seria di un'infrastruttura prevede sempre un monitoraggio proattivo agganciato ai sistemi, con strumenti come Zabbix per lo stato e le risorse delle macchine e un SIEM per raccogliere e correlare i log e gli eventi di sicurezza. Servono a notare ciò che esce dalla normalità, per esempio un processo che non dovrebbe esistere, un picco di richieste strane verso uno script, un file modificato dove nessuno ha messo mano, un consumo di memoria che non torna, e a far partire l'allarme mentre la vulnerabilità non ha ancora un nome. A quel punto si può intervenire con una contromisura (isolare un servizio, bloccare un percorso, stringere una regola) senza aspettare che la notizia arrivi sui giornali.
Il monitoraggio non sostituisce la correzione, e sarebbe sbagliato raccontarlo come una garanzia: non vede tutto, e un attacco ben fatto può passare senza lasciare tracce evidenti. Quello che dà è una possibilità in più di accorgersi in tempo, ed è molto diversa dalla situazione di chi scopre il problema perché un cliente telefona, oppure perché il sito è sparito dai risultati di ricerca.
Molte macchine, una procedura
L'altro aspetto è come si interviene quando i sistemi sono tanti e sono tutti diversi fra loro, ognuno con la sua versione di PHP, il suo sistema operativo, la sua storia e i suoi vincoli. Farlo a mano, macchina per macchina, è lento e soprattutto ci si sbaglia: prima o poi se ne salta una, o su una si applica una cosa un po' diversa da quella applicata sulla precedente.
Chi gestisce interi parchi macchine lavora con strumenti di automazione, di natura e marca diversa, che permettono di scrivere la correzione una volta e di applicarla in modo uniforme a tutti gli ambienti. La procedura parte da una verifica di ciò che c'è su ogni sistema, quindi non presume niente, poi applica la modifica, controlla l'esito e, se qualcosa non va, sa tornare indietro. Con un riferimento unico si ottiene anche la certezza di avere fatto la stessa cosa dappertutto, e un registro di quando e dove è stata fatta, utile il giorno in cui qualcuno chiede conferma.
In un caso come PHP2Shell, in cui le ore contano, intervenire a mano su ogni ambiente o farlo in modo strutturato vuol dire giorni di esposizione in più o in meno, e soprattutto la tranquillità di sapere che il lavoro è stato fatto per intero.
La differenza la fa il metodo
Ho visto in più occasioni come funziona la versione opposta: si aspetta che qualcuno segnali un problema, o che il cliente chieda cosa fare, e solo allora si comincia a guardare a quali sistemi serve mettere mano, con tempi che si allungano e con la scoperta, a lavori iniziati, di macchine di cui nessuno si ricordava. Per chi gestisce poche cose una vulnerabilità critica è un evento raro, e a un evento raro difficilmente ci si prepara, mentre per chi ne gestisce molte è ordinaria amministrazione.
Quando un fornitore sa già dove sono i suoi sistemi e cosa ci gira, quando ha l'abitudine di leggere gli avvisi appena escono e quando ha le procedure per intervenire senza improvvisare, il cliente di norma non se ne accorge nemmeno, e questo è il risultato che si vuole. Le brutte sorprese vengono da ciò che nessuno aveva previsto, e una vulnerabilità come questa si può prevedere, perché si sa che prima o poi ne arriverà una.
Cosa aspettarsi e cosa chiedere
Se gestisci un sito o i sistemi di un'azienda, o anche solo ti affidi a qualcuno che lo fa, conviene chiedere al tuo fornitore quale versione di PHP gira sui tuoi sistemi, quanto ci metterebbe a intervenire il giorno in cui esce un avviso come questo e cosa si fa per ciò che non si può aggiornare. Se le risposte sono pronte e concrete, il problema è già in mano a qualcuno. Se arrivano vaghe, o dopo qualche giorno, vale la pena parlarne adesso, prima della prossima.
Il quadro che ci aspetta è questo: più vulnerabilità, trovate più in fretta, con finestre fra scoperta e sfruttamento sempre più brevi. Non serve allarmarsi, serve organizzarsi, e chi lo ha già fatto alla prossima occasione se la caverà con una normale giornata di lavoro.
Se hai sistemi con PHP datato, un sito che non si può aggiornare o semplicemente vuoi sapere a che punto sei, scrivimi.
Parliamone →