Il 21 ottobre 2026 due vulnerabilità critiche di PHP, note come PHP2Shell, hanno costretto amministratori, hosting provider e responsabili ICT a intervenire con urgenza. Le correzioni sono arrivate, ma nell’attesa diversi gestori hanno sospeso preventivamente i propri servizi. Anche il CSIRT Italia ha pubblicato un avviso.
Ieri è stata una giornata intensa per il nostro Studio e per i tanti amministratori di sistema impegnati a verificare l’esposizione dei servizi, valutare le mitigazioni e applicare gli aggiornamenti appena disponibili. Abbiamo seguito l’evoluzione dell’emergenza nel nostro articolo su rossi.team, aggiornandolo man mano che emergevano nuove informazioni.
Il giorno dopo, oltre agli aggiornamenti, restano alcune domande: quanto conosciamo le tecnologie da cui dipendiamo? Quanto siamo preparati a intervenire? E chi risponde di un servizio lasciato online senza manutenzione?
Perché la sicurezza di un server riguarda anche tutti gli altri.
Da anni sentiamo ripetere che PHP è morto, superato, da sostituire con qualcosa di più moderno. Eppure, secondo W3Techs, al 22 ottobre PHP è utilizzato dal 69,3% dei siti di cui è identificabile il linguaggio lato server. Un’infrastruttura enorme, che continua a sostenere servizi critici, commercio elettronico, informazione e attività aziendali.
Invocare genericamente “altri framework” serve a poco: occorre trovare un sostituto di php, che attualmente non esiste. Cambiare tecnologia comporta comunque nuove dipendenze da mantenere, aggiornare e controllare.
La soluzione drastica
Durante l’emergenza, alcuni gestori hanno scelto la strada più drastica: sospendere i servizi. Il PHPocalypse Tracker raccoglie segnalazioni di interruzioni e successivi ripristini, anche per siti istituzionali e piattaforme conosciute. Va letto con attenzione: essere stati messi offline non significa essere stati compromessi, e le singole segnalazioni hanno livelli diversi di conferma.
Alcuni gestori hanno sospeso preventivamente i servizi, seguendo anche l’indicazione del CERT-EU di considerare l’isolamento delle applicazioni esposte quando non fosse possibile applicare tempestivamente le correzioni.
A nostro avviso, alcune di queste decisioni riflettono soprattutto l’incertezza sulla concreta sfruttabilità delle vulnerabilità: mancavano elementi sufficienti per valutare l’esposizione dei singoli sistemi e l’efficacia delle possibili mitigazioni. Nell’incertezza, diversi gestori hanno scelto di interrompere il servizio.
È una scelta comprensibile, ma ha un costo. Crediamo che questa vicenda mostri quanto sia necessario disporre di informazioni tempestive e capacità di analisi: conoscere la gravità di una vulnerabilità è essenziale; comprenderne le condizioni di sfruttamento permette di decidere come intervenire in modo proporzionato. La disponibilità delle correzioni non esaurisce, da sola, la comprensione delle possibilità di attacco nelle diverse configurazioni.
Cloudflare e il ruolo delle CDN nella mitigazione del rischio
Il caso Cloudflare merita attenzione anche per il ruolo di intermediazione che una CDN può svolgere tra Internet e il server che ospita un sito. Quando il traffico attraversa la sua rete, Cloudflare può applicare controlli e distribuire rapidamente mitigazioni a beneficio di molti servizi contemporaneamente.
Durante l’emergenza PHP2Shell, Cloudflare ha dichiarato di aver introdotto regole WAF dedicate anche per i clienti Free, operative dalle 03:02 UTC del 21 ottobre, aggiornandole in risposta ai tentativi di attacco osservati. Le informazioni pubblicate descrivono l’approccio adottato, ma non ci consentono di stabilire quanto ogni misura abbia ridotto il rischio nelle diverse configurazioni, né quanti incidenti abbia evitato.
Resta il contributo di un operatore autorevole, capace di affiancare i gestori dei server web durante un’emergenza. È un vantaggio concreto dell’intermediazione e delle difese su più livelli, purché il traffico non possa aggirarle raggiungendo direttamente il server. Gli aggiornamenti PHP rimangono comunque necessari.
Il dato più impressionante, però, riguarda ciò che esisteva prima dell’emergenza.
PHP fuori supporto: il debito di manutenzione presenta il conto
Sommando i dati ufficiali WordPress consultati il 22 ottobre, circa il 36% delle installazioni rappresentate utilizza PHP 8.1 o versioni precedenti. Quasi il 16% è ancora su PHP 7.4. Sono statistiche dell’ecosistema WordPress, non dell’intero web, ma descrivono comunque una situazione pesante.
PHP 8.1 e precedenti sono fuori dal supporto ordinario del progetto. Esistono manutenzioni estese e correzioni fornite da alcuni distributori: la versione, da sola, non dimostra l’assenza di patch. Ma chi utilizza questi servizi dovrebbe sapere chi garantisce gli aggiornamenti e con quali tempi.
Perché lasciare un sito su PHP 7.4, ormai in EOL da quattro anni? Un plugin incompatibile, un tema abbandonato, un’applicazione mai adeguata, un contratto che nessuno ha più verificato. Sono spiegazioni possibili. Non giustificano anni di rinvii.
La manutenzione fa parte del costo del sito. Se un componente critico non può essere aggiornato, occorre programmare un intervento prima che l’emergenza imponga di scegliere tra esposizione e interruzione del servizio. Quando arriva una correzione urgente, dobbiamo essere nelle condizioni di applicarla.
Chi ha la responsabilità?
Questa responsabilità coinvolge anche i fornitori. In un hosting WordPress gestito ci si deve aspettare una gestione concreta della piattaforma. Nell’hosting condiviso il provider controlla l’ambiente PHP e dovrebbe prevedere politiche sulle versioni obsolete, avvisi e percorsi di migrazione. Una VPS non gestita attribuisce invece al cliente compiti molto più ampi.
Le responsabilità cambiano con il servizio acquistato e con il controllo effettivo sui sistemi. Devono però essere esplicite: il rischio cresce quando proprietario, manutentore e provider presumono ciascuno che se ne occupi qualcun altro.
Qui torna utile il paragone con la revisione dell’automobile. Il mezzo è privato, ma circola in uno spazio condiviso e le sue condizioni possono danneggiare altre persone.
Un server compromesso può distribuire malware, ospitare phishing, inviare spam e attaccare altri sistemi. Il proprietario non sta quindi accettando soltanto un rischio per sé: ne sta trasferendo una parte alla collettività.
La base minima di sicurezza
Crediamo sia ragionevole discutere di requisiti minimi di manutenzione, controlli e conseguenze per chi li ignora. Proponiamo un modello nel quale provider e soggetti qualificati possano svolgere verifiche nei rispettivi ambiti, mentre vigilanza e sanzioni abbiano una responsabilità pubblica chiaramente definita.
Servirebbero criteri proporzionati: segnalazione delle carenze, termine per intervenire, sanzioni per le omissioni persistenti e sospensione nei casi di pericolo concreto. Il controllo dovrebbe verificare una capacità effettiva di manutenzione e risposta, perché una fotografia periodica può essere superata dalla vulnerabilità scoperta il giorno successivo.
L’incuria dimostrabile — avvisi ignorati, rischi conosciuti e aggiornamenti trascurati — deve avere conseguenze. La scoperta di una vulnerabilità può invece riguardare anche chi lavora correttamente: la responsabilità si misura anche nella capacità di gestirla.
La consapevolezza della cybersec
Pubblicare un servizio su Internet comporta una responsabilità continuativa. La sicurezza di ogni singolo server contribuisce alla sicurezza della rete che condividiamo.
Le correzioni sono disponibili. Da domani vedremo quanti siti continueranno a utilizzare versioni vulnerabili di PHP e per quanto tempo.
È qui che misureremo la nostra capacità di imparare da questa emergenza: nella manutenzione quotidiana, nelle responsabilità assunte e negli interventi effettivamente eseguiti.
Quanti server vulnerabili siamo disposti a lasciare online, trasferendone il rischio anche ad altri?
In gioco c’è anche il futuro di Internet.