Un paio di settimane fa internet è stata rilasciata una notizia che riguarda il php, che è rimbalzata anche sui medie generalisti. Una vulnerabilità chiamata PHP2Shell ha messo a rischio una parte enorme del web, alcuni siti governativi sono stati spenti per precauzione e i telefoni delle web agency hanno iniziato a squillare. Ancora più grave un noto sito di videogiochi ha spento tutto, per prudenza.
Anche noi abbiamo avuto la nostra dose di fibrillazione. Ci è venuta il giorno prima, quando hanno cominciato a circolare i primi allarmi e nessuno sapeva ancora bene con cosa avessimo a che fare, e ci è passata nella notte, quando finalmente abbiamo potuto installare gli aggiornamenti sui nostri server. Ad alcuni dei nostri clienti la fibrillazione è arrivata il giorno dopo, leggendo le notizie, e ci hanno telefonato per sapere cosa fare. Altri non si sono accorti di nulla, semplicemente perché erano impegnati a fare il loro lavoro, che giustamente non ha niente a che vedere con PHP. Sarebbe bello dire che si tratta di un caso unico nella storia dell’informatica, ma i diversamente giovani ricordano di situazioni simili, quello che cambia è il contorno e la frequenza con cui allarmi di questo tipo si stanno diffondendo, ci arriviamo.
Prima vedremo cosa è successo e cosa dovreste controllare sul vostro sito. Poi proveremo a spiegare perché questa vicenda non è un incidente isolato, ma il segnale di un cambiamento che riguarda chiunque abbia un sito internet.
PHP2Shell in breve
PHP è il linguaggio di programmazione con cui funziona circa il 70% dei siti web del mondo, compresi tutti quelli realizzati con WordPress, Joomla e Drupal. Se WordPress è la carrozzeria del vostro sito, PHP è il motore: non lo vedete mai, ma senza di lui la macchina non si muove.
Il 21 ottobre 2026 gli sviluppatori di PHP hanno corretto due vulnerabilità gravissime, catalogate come CVE-2026-109618 e CVE-2026-109619 e battezzate collettivamente PHP2Shell. In determinate condizioni permettono a un malintenzionato di prendere il controllo del server che ospita il sito, senza bisogno di alcuna password. In alternativa possono consentirgli di leggere porzioni della memoria del server, dove possono trovarsi password, chiavi di accesso e altri dati riservati.
Senza entrare nei dettagli tecnici, il meccanismo è questo: l’attaccante costringe PHP a esaurire la memoria disponibile, e quando PHP “inciampa” non pulisce tutto come dovrebbe. La richiesta successiva trova la porta socchiusa. Il difetto era presente nel codice da oltre dieci anni e riguarda praticamente tutte le versioni di PHP rilasciate nell’ultimo decennio, fino alla 5.4.
A rendere tutto più drammatico ci si è messo anche il calendario. Le informazioni sono uscite il 20 ottobre, il giorno prima della pubblicazione concordata delle correzioni, e i primi attacchi sono stati osservati già prima del rilascio ufficiale. Secondo Amazon, un tentativo di sfruttamento risalirebbe addirittura al 17 ottobre. Il 26 ottobre l’agenzia americana per la sicurezza informatica (CISA) ha inserito entrambe le vulnerabilità nel suo catalogo di quelle sfruttate attivamente. Insomma, non stiamo parlando di un rischio teorico.
Siete a rischio? Cosa fare subito
Aggiornare WordPress, i plugin e il tema resta indispensabile, ma questa volta non bastava. PHP2Shell si trova nel motore, non nella carrozzeria: un sito WordPress perfettamente aggiornato, su una versione vulnerabile di PHP, era comunque esposto.
Attenzione però a non trarre la conclusione sbagliata. PHP2Shell ha guadagnato così tanta notorietà perchè riguardava tutti i siti, indipendentemente dal CMS ma problemi altrettanto gravi vengono scoperti spesso, solo che riguardano una porzione più limitata del web. Secondo Patchstack, nel 2025 sono state scoperte 11.334 nuove vulnerabilità nell’ecosistema WordPress, il 42% in più dell’anno precedente, e il 91% riguardava i plugin. Nello stesso periodo le vulnerabilità segnalate nel cuore di WordPress sono state appena sei, tutte di gravità bassa. Nella stragrande maggioranza dei casi l’anello debole resta l’applicazione: plugin scelti male o abbandonati, temi mai aggiornati, componenti installati e dimenticati. PHP2Shell è l’eccezione che ha conquistato le prime pagine perché riguarda mezza internet, non la regola.
Chi deve intervenire
Aggiornare PHP non è un’operazione che si può fare bacheca di WordPress. A seconda di dove si trova il vostro sito:
- Hosting condiviso o gestito: è il fornitore a gestire PHP. La maggior parte dei grandi provider ha installato le correzioni nel giro di poche ore, ma non date nulla per scontato e chiedete conferma.
- Server dedicato o VPS: l’aggiornamento tocca a chi amministra il server. Se siete voi, dovete farlo voi; se è un tecnico o un’agenzia, chiedete a loro.
- Sito gestito da un’agenzia: chi si occupa della manutenzione dovrebbe avervi già informato. Se non l’ha fatto, è il momento di chiedere.
Le domande da fare sono tre, semplici e dirette:
- Quale versione di PHP usa il mio sito?
- È stata aggiornata dopo il 21 ottobre 2026?
- Se si tratta di una versione non più supportata, come è stata protetta?
Per le versioni ancora supportate le correzioni sono contenute in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Potete verificare quale ramo di PHP usa il vostro sito anche da soli, dalla bacheca di WordPress: andate su Strumenti, poi Salute del sito, scheda Info e sezione Server.
C’è però un problema nel problema. Per le versioni più vecchie, che non ricevono più aggiornamenti ufficiali, le correzioni sono state distribuite come “toppe” applicate alla versione esistente, senza cambiarne il numero. Un PHP 7.4 protetto e uno vulnerabile, in altre parole, mostrano esattamente la stessa versione. Il numero vi dice quale ramo state usando, non se siete al sicuro: per quello serve chiedere a chi gestisce il server.
Per completezza: il 23 ottobre gli sviluppatori di PHP hanno segnalato una terza vulnerabilità, CVE-2026-115560. Se doveste leggerne da qualche parte, niente panico: riguarda solo configurazioni molto particolari, rare nei siti WordPress, e si neutralizza con una semplice impostazione in attesa della correzione definitiva. Chi gestisce il vostro server sa di cosa si tratta.
I dettagli ufficiali, per chi volesse approfondire, sono nell’annuncio pubblicato sul sito di PHP.
L’eroe sconosciuto
C’è un aspetto di questa vicenda che i giornali hanno raccontato poco, e che secondo noi merita più attenzione.
Il progetto PHP supporta ufficialmente solo le versioni dalla 8.2 in su. Per le versioni più vecchie, come la 7.4 o la 5.6, non esiste un aggiornamento ufficiale: chi le usa, in teoria, è rimasto scoperto. In pratica, però, milioni di server sono stati protetti grazie al lavoro di una sola persona: Ondřej Surý.
Ondřej vive in Repubblica Ceca e di mestiere dirige lo sviluppo DNS all’Internet Systems Consortium, l’organizzazione no profit che sviluppa BIND, uno dei software su cui si regge internet. Non lavora per il progetto PHP. Eppure da oltre vent’anni prepara, nel suo tempo libero, i pacchetti di PHP pronti da installare sui server Debian e Ubuntu, che sono una fetta enorme dei server web del pianeta. Anche quelli delle versioni ormai abbandonate da tutti.
Il giorno stesso del rilascio delle correzioni, Ondřej ha pubblicato le versioni protette per tutti i rami che mantiene, dalla 8.5 fino alla 5.6, rilasciata più di dieci anni fa. Quando in rete ha iniziato a circolare l’idea che un terzo di internet fosse a rischio armageddon perché basato su versioni non più correggibili, la sua risposta è stata semplice: le versioni vecchie si possono correggere, l’ho appena fatto. Anche noi gli dobbiamo molto: il suo lavoro permette di lavorare anche quando non è possibile spostare il software su una versione di php decente.
Ondřej ha anche detto una cosa che dovrebbe essere ovvia: vorrebbe che più aziende sostenessero i volontari da cui dipendono, prima della prossima emergenza e non dopo.
Ed è proprio qui il punto. Il gesto di Ondřej è straordinario, ma è anche la dimostrazione di quanto sia fragile il sistema. Se il vostro sito è al sicuro solo perché un volontario in Repubblica Ceca ha lavorato senza sosta, la vostra strategia di sicurezza ha un nome preciso: si chiama fortuna. Ondřej non ha obblighi verso nessuno, potrebbe ammalarsi, cambiare lavoro o semplicemente decidere di aver fatto abbastanza. E i suoi pacchetti coprono solo alcune distribuzioni: chi usa sistemi diversi, o versioni troppo vecchie degli stessi sistemi, non ha avuto questa fortuna.
Non è un problema solo suo, peraltro. Buona parte del software su cui si regge internet è mantenuta da volontari, o da piccoli gruppi sottofinanziati, che negli ultimi tempi devono anche fare i conti con un’ondata di segnalazioni di presunte vulnerabilità generate in automatico, spesso inesistenti. Il progetto curl, uno dei software più diffusi al mondo, è arrivato a chiudere il suo programma di ricompense per chi segnala problemi di sicurezza proprio per questo motivo. Più lavoro, stesse persone.
Non è un problema di PHP (e nemmeno di WordPress)
Sarebbe comodo pensare che PHP2Shell sia la prova che PHP e WordPress sono tecnologie “vulnerabili”, e che basterebbe cambiare strumento per dormire tranquilli. Purtroppo non è così, e per capirlo basta guardare cosa è successo negli ultimi due anni a software molto lontani dal mondo dei siti web:
- SQLite (2024): è il database che si trova dentro ogni smartphone e ogni browser. Un sistema sperimentale di Google vi ha individuato una vulnerabilità sfruttabile che i metodi di test tradizionali non avevano trovato.
- Il kernel Linux (2025): un singolo ricercatore, con un modello di intelligenza artificiale disponibile in commercio, ha scoperto una falla sfruttabile da remoto nel componente che gestisce la condivisione di file in rete.
- OpenSSL (gennaio 2026): è la libreria che sta dietro il lucchetto che vedete nella barra degli indirizzi quando visitate un sito sicuro. Dodici vulnerabilità corrette in un colpo solo, alcune presenti nel codice dalla fine degli anni Novanta.
- OpenBSD e FFmpeg (aprile 2026): OpenBSD è considerato uno dei sistemi operativi più blindati al mondo, e conteneva una falla vecchia di 27 anni. FFmpeg gestisce i video in un’infinità di programmi, e nascondeva un difetto di 16 anni in una riga di codice che gli strumenti di test automatico avevano eseguito cinque milioni di volte senza accorgersi di nulla.
Lo stesso discorso vale per i database su cui si appoggiano i siti WordPress: nel 2026 sono state scoperte vulnerabilità anche in MySQL, MariaDB e PostgreSQL.
Avrete notato un elemento comune: in tutti questi casi le falle sono state scoperte con l’aiuto dell’intelligenza artificiale, e lo stesso vale per PHP2Shell. Non vogliamo unirci al coro di chi annuncia la fine del mondo (né a quello di chi annuncia l’avvento di un’età dell’oro), ma un fatto è difficile da negare. Il codice vulnerabile c’era già, a volte da decenni. Quello che è cambiato è il costo per trovarlo e, purtroppo, anche per sfruttarlo: secondo i ricercatori che hanno scoperto PHP2Shell, un lavoro che avrebbe richiesto mesi a un gruppo di specialisti è stato completato in una settimana da una sola persona.
Gli stessi strumenti, per fortuna, sono a disposizione di chi difende: molte di queste falle sono state trovate e corrette prima che qualcuno le sfruttasse. Ma il risultato netto è che le vulnerabilità emergono più in fretta, e chi gestisce un sito deve tenere il passo.
Cosa cambia nella manutenzione
Fino a pochi anni fa, diciamo quattro o cinque, si poteva contare su una specie di sicurezza per oscurità. Trovare una vulnerabilità seria, e soprattutto riuscire a sfruttarla, era un lavoro per pochi specialisti molto preparati, che di solito avevano obiettivi più appetibili del sito di una piccola azienda. Oggi questa barriera si è abbassata parecchio e le capacità necessarie sono alla portata di molte più persone.
La conseguenza è che la manutenzione di un sito cambia natura. Non è più un intervento da fare ogni tanto, quando capita o quando qualcosa si rompe, ma un processo continuo: aggiornamenti più frequenti, controlli più regolari, la capacità di reagire nel giro di ore e non di settimane. Questo significa, inevitabilmente, un aumento dello sforzo necessario, per noi come per chiunque faccia questo mestiere seriamente.
È un costo. Ma va confrontato con il costo del non fare nulla: un sito spento per giorni, dati dei clienti sottratti, credenziali rubate dalla memoria del server e riutilizzate altrove, il tempo e i soldi necessari per ripulire tutto e, nel caso di dati personali, le grane che ne conseguono. Senza contare la figura che si fa con i propri clienti.
La telefonata di cui parlavamo all’inizio è la dimostrazione pratica di cosa significhi manutenzione proattiva: quando il cliente ha saputo del problema, il problema era già stato risolto. È questo il livello a cui bisogna puntare, ed è un livello che richiede attenzione costante, non interventi occasionali. Se volete capire come lavoriamo su questo fronte, trovate qualche informazione nella pagina dedicata alla sicurezza dei siti.
Il software invecchia, anche il nostro
Arriviamo al punto più delicato.
Ogni anno, con alcuni clienti, ripetiamo lo stesso rituale: spieghiamo che la loro applicazione gira su una versione di PHP non più supportata, a volte addirittura PHP 5, e proponiamo di aggiornarla. E ogni anno, spesso, la risposta è la stessa: funziona, perché dovrei spendere?
Lo capiamo, davvero. Dal punto di vista del cliente è un ragionamento sensato: il costo dell’aggiornamento è concreto e immediato, il rischio è invisibile. Il sito si apre, i moduli funzionano, gli ordini arrivano. Perché cambiare qualcosa che funziona?
Vale la pena fare un’ammissione, prima di tutto. Alcune di queste applicazioni le abbiamo scritte noi, dieci o anche vent’anni fa. Non sono state scritte male: sono state scritte per un mondo che non esiste più. Il software invecchia non perché si consuma, ma perché tutto quello che gli sta intorno cambia: i linguaggi, i server, i browser e, soprattutto, le minacce. Un’applicazione realizzata per PHP 5 era perfettamente adeguata a internet del 2010. Quello di oggi è un altro posto.
Con PHP2Shell la situazione dei software più vecchi che seguiamo è stata, per usare un eufemismo, frammentata. Quelli che girano sui nostri server sono stati protetti in poche ore anche grazie ai pacchetti di Ondřej Surý, e dove possibile abbiamo ridotto ulteriormente l’esposizione limitando gli accessi o disattivando funzioni non indispensabili, come il caricamento di file. Alcuni sono protetti da una password, altri girano dietro una VPN, su server che non gestiamo direttamente perché ci siamo limitati, a suo tempo, a realizzare il software. Questa volta è andata bene. Ma avete notato quante volte, in questo paragrafo, la sicurezza è dipesa da qualcosa che non era il software stesso? La prossima volta potrebbe non bastare.
Il problema, a volte, è che aggiornare PHP non è un’operazione indolore. Per alcuni siti significa riscrivere parti dell’applicazione, per altri cambiare il tema e in qualche caso addirittura il CMS. È un lavoro importante, e capiamo che possa non esserci la voglia di affrontarlo. Ma esistono anche strade intermedie: una valutazione del rischio per capire cosa è davvero esposto, una migrazione graduale, l’isolamento delle parti più vecchie, la limitazione degli accessi. E se proprio decidete di non intervenire, fatelo almeno in modo consapevole, sapendo cosa state rischiando.
C’è anche una scadenza molto concreta da segnare in agenda: PHP 8.2 arriva a fine vita il 31 dicembre 2026 e dopo quella data non riceverà più aggiornamenti di sicurezza. Molti siti che oggi sono considerati aggiornati, tra due mesi non lo saranno più.
Quando vi chiediamo di aggiornare un sito o un’applicazione non stiamo cercando di vendervi qualcosa. Ovviamente non lavoriamo gratis, ma la proposta nasce da una preoccupazione reale: proteggere il vostro sito, i vostri dati e quelli dei vostri clienti. Nel vostro interesse, prima che nel nostro. E a volte la soluzione migliore non è rattoppare il vecchio ma ripartire con un restyling del sito fatto come si deve.
Conclusioni
PHP2Shell passerà, come sono passate tutte le emergenze prima di lei, e tra qualche settimana nessuno ne parlerà più. Quello che resterà è il cambiamento di cui è un sintomo: le vulnerabilità non sono più rare gemme nascoste che solo pochi esperti sanno trovare, ma qualcosa che emerge con una velocità e una frequenza mai viste prima. Riguarda PHP, WordPress, i database, i sistemi operativi, qualunque software.
Per chi ha un sito internet questo significa una cosa sola: la manutenzione non è più un optional da rimandare all’anno prossimo, e il software obsoleto non è più un rischio che si possa tollerare a tempo indeterminato.
Voi da che parte stavate la settimana scorsa: tra chi era in fibrillazione o tra chi dormiva sonni tranquilli? Se non sapete rispondere alle tre domande che vi abbiamo suggerito, o se il vostro sito gira ancora su una versione di PHP che ha qualche anno di troppo, contattateci: ne parliamo con calma, prima della prossima emergenza.
