Che cosa fare con un sito web che ha una versione vecchia di PHP o di Node.js?

La risposta breve è questa: un sito web con una versione vecchia di PHP o di Node.js ha tre strade — adattare il codice a un rilascio supportato, ricostruire il sito da zero, oppure tenerlo per un periodo su una piattaforma che continua ad applicare i backport delle patch di sicurezza al runtime vecchio, e nel frattempo pianificare il passaggio con calma. La quarta strada — lasciare tutto com’è, perché il sito in fondo funziona — in realtà non esiste, perché i release branch di PHP 8.1 e precedenti non ricevono più correzioni dal progetto PHP, e non le ricevono nemmeno la release line 18 e la release line 20 di Node.js, e l’ottobre 2026 ha mostrato, in entrambi i casi, che cosa questo significhi nella pratica.

Un sito web con una versione vecchia di PHP di solito non è né un’eccezione né una negligenza particolare. È stato realizzato cinque o otto anni fa, lo sviluppatore che lo ha costruito lavora da tempo altrove, e per tutti questi anni il sito ha servito senza grandi problemi: ha accettato richieste, mostrato prezzi e inviato fatture. Secondo i dati di W3Techs, nell’ottobre 2026 il 26,8% dei siti web che usano PHP girava su PHP 7 e un altro 7,7% su PHP 5, quindi più di un terzo di essi usa un PHP che ha raggiunto l’end of life da diversi anni. La domanda di solito nasce solo quando il fornitore di hosting manda un avviso, o quando una vulnerabilità diventa notizia.

Quando una versione di PHP o di Node.js diventa vecchia

«Vecchia», qui, non è una questione di gusto, perché sia PHP sia Node.js pubblicano un calendario che indica fino a quale data ogni release branch o release line riceve correzioni. PHP, per ogni release branch, concede due anni di Active support e altri due anni nei quali escono solo correzioni di sicurezza per i difetti critici, e dopo quel momento il release branch non è più supportato in alcun modo. Le release line di Node.js in supporto a lungo termine hanno, alla fine, una fase Maintenance LTS e, quando quella finisce, la release line non riceve più alcun rilascio, anche se una vulnerabilità nuova colpisce proprio quella.

Nella tabella ci sono i release branch e le release line con cui oggi capita più spesso di avere a che fare, e il loro stato nell’ottobre 2026. Le date sono prese dall’elenco degli end of life di PHP e dal calendario dei rilasci di Node.js, ed entrambe le fonti vanno ricontrollate anche in seguito, perché ogni anno vi compaiono righe nuove.

Due righe di questa tabella meritano di essere rilette. PHP 8.2 raggiungerà l’end of life il 31 dicembre 2026, quindi un sito che nell’autunno 2026 sembra attuale si troverà, nel gennaio 2027, nella stessa situazione di un sito con PHP 7.4, e conviene pianificare il passaggio già adesso, finché lo si può fare senza fretta. La release line 20 di Node.js, ancora nell’autunno 2024, era la release line in supporto a lungo termine allora attiva, sulla quale sono partiti molti progetti nuovi, ma il 30 aprile 2026 ha raggiunto l’end of life. L’invecchiamento non avviene per gradi: in un giorno preciso il runtime passa da «riceve le correzioni» a «non riceve più nulla», e sul sito, in quel momento, non cambia nulla che si possa notare.

Perché un sito che funziona è comunque esposto

Una versione senza supporto non diventa pericolosa il giorno in cui il supporto finisce, ma il giorno in cui viene pubblicata una vulnerabilità che riguarda anche quella. La correzione per i release branch supportati esce insieme alla descrizione e, appena è pubblica, chi attacca può confrontare il codice corretto con quello non corretto e capire dov’è il buco. Node.js, nella sua pagina sull’end of life, lo dice in modo diretto: se una vulnerabilità riguarda anche una release line senza supporto, per quella non uscirà un rilascio nuovo, e chi resta su una release line così è subito esposto agli attacchi che sfruttano la vulnerabilità pubblicata.

Nell’ottobre 2026 è successo proprio questo, quasi nello stesso momento, a entrambe le piattaforme. Il 21 ottobre PHP ha pubblicato patch di sicurezza di emergenza per due vulnerabilità critiche note con il nome PHP2Shell, e i rilasci ufficiali li hanno ricevuti solo i release branch dall’8.2 all’8.5, mentre per i release branch 7.4, 8.0 e 8.1 il team di sicurezza ha preparato, in via eccezionale, soltanto correzioni minime del codice sorgente per chi compila PHP in proprio. Lo stesso giorno Node.js ha pubblicato le correzioni per dieci vulnerabilità, e la release line 18 e la release line 20 non le hanno ricevute affatto dal progetto stesso. I due casi li abbiamo descritti più nel dettaglio, separatamente: nell’articolo su PHP2Shell e nell’articolo sull’aggiornamento di sicurezza di Node.js.

Il secondo rischio è meno visibile, ma nel lungo periodo è più grande. Un runtime vecchio non lascia aggiornare nulla di ciò che sta sopra di esso: i plugin di WordPress, i package di Composer e di npm e il framework stesso, nei loro rilasci nuovi, smettono a poco a poco di supportare PHP e Node.js vecchi, e così il sito non può ricevere nemmeno le loro correzioni. WordPress stesso raccomanda PHP 8.3 o più recente e, sui release branch più vecchi, scrive che il loro supporto ufficiale è finito e che possono lasciare il sito esposto. Così il runtime vecchio non è più un problema a sé, ma uno strato che impedisce di risolvere tutti gli altri.

Quando qualcosa accade, il costo è ben più alto di un aggiornamento pianificato. Un sito hackerato significa pulizia, ripristino da un backup, sostituzione di password e chiavi e, se sono stati toccati i dati personali dei clienti, anche una valutazione sul fatto che la violazione dei dati personali vada notificata all’autorità di controllo; e tutto questo avviene di fretta, mentre il sito non funziona o mostra ai visitatori contenuti altrui. Il passaggio, in questa situazione, va fatto comunque, solo che ora tocca farlo dopo la compromissione e non prima, e senza la possibilità di verificare tutto con calma in un ambiente di test.

Perché una versione vecchia di PHP non si cambia con un clic nel pannello di hosting

Nel pannello di hosting il passaggio a una versione più recente di PHP richiede un solo clic, ed è proprio per questo che è insidioso: se il codice non è pronto, il sito smette di funzionare nel secondo successivo, spesso con una pagina bianca o un messaggio di errore. Nel passaggio al major version successivo, PHP rimuove di proposito funzioni che per anni sono state obsolete. PHP 7.0 ha rimosso la vecchia estensione PHP mysql, sulla quale poggiavano molti siti più vecchi, mentre PHP 8.0, nel suo elenco delle modifiche incompatibili, ha rimosso tra le altre le funzioni each() e create_function(), che nel codice più vecchio si incontrano ancora.

Nel mondo Node.js l’esempio classico è la release line 17, nella quale il runtime è passato a OpenSSL 3.0. Nel comunicato del rilascio Node.js avvertiva che un’applicazione la quale, essa stessa o tramite i suoi moduli, usa un algoritmo o una lunghezza di chiave che OpenSSL 3.0 per impostazione predefinita non consente più, riceverà l’errore ERR_OSSL_EVP_UNSUPPORTED, e come soluzione temporanea proponeva il parametro di avvio --openssl-legacy-provider. L’errore, non di rado, non lo causava il codice del progetto stesso, ma una delle sue dipendenze, e così bisognava correggere codice che il team del progetto non aveva nemmeno scritto.

Per questo il passaggio è lavoro di sviluppo, non un’impostazione. Il codice va verificato sul runtime nuovo, le funzioni obsolete vanno sostituite, le dipendenze vanno aggiornate fino a rilasci che lo supportano, e tutto va provato in un ambiente di test prima che lo vedano i clienti. Per un sito piccolo su una piattaforma mantenuta possono essere poche ore di lavoro, ma per un sistema il cui framework ha raggiunto l’end of life diversi anni fa il passaggio spesso significa anche sostituire il framework, e allora è già un progetto con un suo budget e un suo calendario, non un compito da sbrigare tra un lavoro e l’altro.

Tre strade: aggiornare, ricostruire o tenere protetto

La strada la decidono due cose: quanto il codice è rimasto indietro rispetto a una versione supportata, e per quanto tempo il sito deve ancora servire. Se fra un anno il sito va comunque sostituito con uno nuovo, non conviene fare un grande passaggio sul codice vecchio; se invece è lo strumento del lavoro quotidiano dell’azienda, e verrà usato per almeno altri cinque anni, una soluzione temporanea non fa che rimandare l’inevitabile e renderlo più caro. Nella tabella ci sono le tre strade che esistono davvero, e che cosa ciascuna risolve e che cosa no.

L’aggiornamento è la scelta giusta se il sito poggia su una piattaforma mantenuta, per esempio WordPress o Laravel, e da un release branch supportato lo separano uno o due passi grandi. Allora il lavoro è prevedibile: aggiornare il framework e i plugin, correggere ciò che trovano gli strumenti di verifica e cambiare PHP. La ricostruzione è la strada più onesta se il framework stesso è senza supporto, se il sito è scritto su PHP 5.x senza alcun framework, o se il codice non lo capisce più nessuno, perché allora il costo dell’aggiornamento si avvicina in fretta al costo di un sito nuovo, ma il risultato resta comunque codice vecchio.

La terza strada si discute più di rado. Un sito vecchio si può tenere su una piattaforma che continua ad applicare i backport delle patch di sicurezza per il suo runtime, isola il sito dagli altri siti e blocca gli schemi di attacco noti ancora prima della patch. Non sostituisce il passaggio, e lo stesso Node.js chiama un supporto di questo tipo una soluzione temporanea, ma è un modo onesto per guadagnare tempo: il passaggio si può fare al ritmo pianificato, e non nella settimana che segue l’ennesimo avviso di sicurezza. La parola più importante, qui, è «termine», perché senza un termine la soluzione temporanea diventa permanente.

Che cos’è un backport e perché il numero di versione non dice nulla

Un backport significa che una patch di sicurezza, sviluppata per un rilascio più recente, qualcuno la adatta e la incorpora in un rilascio più vecchio, che l’utente sta già usando. Red Hat, che in questo modo mantiene i package delle proprie distribuzioni Linux, scrive che dal solo numero di versione il cliente non può giudicare se il suo sistema abbia una vulnerabilità, perché la correzione cambia il package ma non il numero di versione. Proprio per questo gli scanner di vulnerabilità che guardano solo il numero, su sistemi così, tendono a segnalare per errore problemi che sono già stati risolti.

Per PHP e Node.js lo fanno diversi fornitori. Le distribuzioni Linux applicano i backport delle correzioni ai propri package di PHP e Node.js per tutto il tempo di supporto della distribuzione. CloudLinux, per i propri package alt-php, che i server di hosting con CloudLinux usano, applica i backport anche ai release branch per i quali il supporto di PHP ha raggiunto l’end of life da tempo: nel caso di PHP2Shell, la sua pagina di stato il 21 ottobre ha annunciato che preparava package corretti per tutti i release branch alt-php dal 5.2 all’8.5, e nel corso della notte successiva erano disponibili. Questi package ora fanno parte dell’Extended Lifecycle Support di TuxCare, nei cui termini, come obiettivo per le vulnerabilità di gravità alta e critica, è indicata una patch entro 14 giorni dalla pubblicazione.

Per le release line di Node.js senza supporto, lo stesso servizio lo offrono partner commerciali che Node.js stesso nomina nella sua pagina sull’end of life: HeroDevs, NodeSource e TuxCare. Node.js aggiunge subito che un supporto di questo tipo va considerato una soluzione temporanea, e che l’obiettivo deve essere sempre il passaggio a una versione supportata. Durante il rilascio di sicurezza di Node.js dell’ottobre 2026, CloudLinux ha applicato i backport delle correzioni anche ai propri package delle release line 16, 18 e 20, che i clienti di hosting scelgono nella sezione Setup Node.js App di cPanel.

Dal numero di versione non lo si può verificare. Il comando php -v o node -v, dopo un backport, mostra esattamente lo stesso di prima, e CloudLinux nel suo comunicato su Node.js lo scrive apertamente: per le release line senza supporto il numero, dopo l’aggiornamento, non cambia. Cambia il release number del package, che vede solo l’amministratore del server, e così, in un hosting condiviso, la risposta la può dare soltanto il fornitore di hosting.

Il limite va detto con la stessa chiarezza. Un backport protegge PHP o Node.js stesso, ma non protegge un plugin di WordPress il cui autore ha smesso di aggiornarlo, il codice scritto in proprio con una SQL injection, o un package npm i cui rilasci più recenti non supportano più un Node.js vecchio. Inoltre i fornitori applicano i backport per ogni release line separatamente, quindi per ciascuna va verificato se sia nell’elenco, e TuxCare nei propri termini si riserva il diritto di offrire, al posto della patch, una misura che riduce il rischio.

Quando a essere vecchio non è il runtime, ma la piattaforma stessa

A volte il problema non sta nel runtime, ma nella piattaforma stessa sulla quale il sito è costruito, e allora i backport di PHP aiutano solo in parte. L’esempio migliore è Drupal 7: il suo supporto di sicurezza è terminato il 5 gennaio 2025 e, da allora, il progetto Drupal stesso non pubblica più né aggiornamenti di sicurezza né aggiornamenti di compatibilità. Un sito su Drupal 7 può girare su un PHP del tutto corretto, ma il core di Drupal, i moduli e il tema restano comunque con tutte le vulnerabilità che vi verranno ancora trovate, perché gratuitamente non le corregge più nessuno.

Anche qui esiste una soluzione temporanea a pagamento: l’associazione Drupal ha istituito un programma di supporto di sicurezza prolungato, nel quale fornitori verificati, per esempio HeroDevs e Tag1 Consulting, offrono supporto a pagamento. È lo stesso principio dei backport di PHP, solo uno strato più in alto, e ha gli stessi limiti: rimanda il passaggio ma non lo risolve, e ogni anno su una piattaforma vecchia rende il passaggio più caro, perché cresce la distanza dal rilascio attuale e diminuisce il numero di sviluppatori che conoscono ancora la piattaforma vecchia.

Per questo, prima di qualsiasi decisione, conviene verificare tutti gli strati e non solo PHP: il runtime, la piattaforma o il framework, i plugin o i moduli, e il codice scritto in proprio. Se è invecchiato solo PHP, ma WordPress, Laravel o un’altra piattaforma è mantenuta, il passaggio di solito è un lavoro prevedibile. Se vecchia è la piattaforma stessa, la domanda non riguarda più il release branch di PHP, ma se spostare il sito sul rilascio nuovo della piattaforma o costruirlo da zero, ed è proprio qui che il compito di un backport è dare il tempo di prendere questa decisione senza fretta.

Come teniamo PHP e Node.js vecchi sul nostro server

Il nostro hosting gestito è uno spazio sul nostro server, che gira su CloudLinux, e per ogni sito la versione di PHP si sceglie separatamente nel pannello di hosting. In questo momento vi è disponibile PHP dal 5.4 all’8.4 e, per le applicazioni Node.js, sia le release line supportate 22 e 24, sia le release line vecchie 16, 18 e 20. Questo significa che un sito vecchio, da noi, si può migrare con lo stesso PHP o lo stesso Node.js con cui funziona adesso, e prima stabilizzarlo, invece di cambiare anche il codice il giorno della migrazione, che è il modo più sicuro per non rompere nulla durante la migrazione.

Come funziona nella pratica, nell’ottobre 2026 abbiamo potuto misurarlo noi stessi. Le patch di PHP2Shell sono uscite nel pomeriggio del 21 ottobre, e sul nostro server tutti i release branch vecchi di PHP, dal 5.4 all’8.1, ora girano con package che CloudLinux ha ricompilato nella notte dello stesso giorno, a meno di ventiquattr’ore dal rilascio di PHP, e nei quali la correzione è entrata con un backport. I release branch dall’8.2 all’8.4 sono passati ai rilasci ufficiali corretti 8.2.35, 8.3.36 e 8.4.27, mentre le release line 16, 18 e 20 di Node.js, il 22 ottobre, hanno ricevuto package CloudLinux con i backport, benché il progetto Node.js stesso non avesse pubblicato correzioni per quelle. Per i release branch vecchi il numero non è cambiato, e così non l’abbiamo verificato dal numero, ma da quando i file eseguibili sono stati ricompilati.

Non è tutto ciò che fa la piattaforma. CloudLinux colloca ogni account di hosting in un ambiente isolato a parte, chiamato CageFS, e lì gli utenti non vedono gli altri utenti del server e nemmeno i loro nomi utente, il che rende più difficile che una compromissione si propaghi da un account agli altri. Il web application firewall (WAF) di Imunify360, nel caso di PHP2Shell, ha cominciato a bloccare gli schemi di attacco noti il 21 ottobre, diverse ore prima della pubblicazione del PHP corretto. Nessuno di questi strati rende un sito vecchio invulnerabile, ma insieme restringono il tempo in cui una vulnerabilità nota è sfruttabile, e limitano fin dove possono arrivare le conseguenze di una compromissione.

Per questo consigliamo di prendere la migrazione di un sito vecchio da noi come una soluzione temporanea con un termine, non come il traguardo. Migriamo il sito con lo stesso runtime, verifichiamo che tutto funzioni come prima, e poi, insieme a Lei, concordiamo entro quale data e in quale ordine passerà a una versione supportata, così che la soluzione temporanea non diventi permanente. Il nostro hosting gestito parte da 45 € al mese, e i runtime mantenuti, l’account isolation e il web application firewall (WAF) fanno parte di ciò per cui si paga questa cifra. Se ha un sito con una versione vecchia di PHP o di Node.js, ci invii l’indirizzo, e Le diremo quale delle tre strade conviene a quel sito e da dove cominciare.

Come sapere quale versione di PHP o di Node.js ha il Suo sito

La strada più rapida è il pannello di hosting. In un hosting cPanel con CloudLinux, la sezione Select PHP Version mostra la versione scelta per l’intero account, mentre MultiPHP Manager mostra la versione di ogni dominio separatamente e, se lì per il dominio è indicata una versione propria, è quella a decidere. Per le applicazioni Node.js lo stesso lo mostra la sezione Setup Node.js App, dove ogni applicazione ha una riga propria. Conviene guardare ogni sito, non solo quello principale, perché in un account spesso ci sono più siti con release branch di PHP diversi, e una copia di test dimenticata o una vecchia pagina di campagna non di rado è ancora raggiungibile da internet.

Su un sito WordPress lo si vede anche nel pannello di amministrazione: in Strumenti → Salute del sito, nella scheda Informazioni, nella sezione Server è indicata la versione di PHP sulla quale il sito gira. Se il pannello non c’è, si può creare un file con la funzione phpinfo() e aprirlo nel browser, ma il file va poi assolutamente eliminato, perché mostra a ogni visitatore la configurazione del server. Il comando php -v qui aiuta meno di quanto sembri, perché mostra il PHP da riga di comando, mentre le richieste web spesso le serve un altro release branch, scelto nel pannello di hosting. In un progetto Node.js la release line desiderata è spesso indicata da package.json, nel campo engines, o dal file .nvmrc, ma quella è solo un’intenzione, e quale Node.js faccia davvero girare l’applicazione va guardato là dove il processo viene avviato.

Se l’accesso non c’è affatto, la domanda va fatta al fornitore di hosting o allo sviluppatore che mantiene il sito. Una formulazione che risparmia lo scambio di messaggi: «Quale versione di PHP o di Node.js serve il nostro sito? Se ha raggiunto l’end of life, riceve backport delle patch di sicurezza, da chi arrivano e quando il package è stato aggiornato l’ultima volta? Fino a quale data consiglia il passaggio?» La risposta all’ultima domanda dice molto anche sul fornitore stesso, perché, se la data non c’è, di solito non c’è nemmeno un piano.

Il passaggio a una versione supportata: come farlo senza sorprese

Il passaggio comincia dall’inventario, non dal cambio di versione. Va annotato quale release branch di PHP e quali estensioni PHP servono al sito, quali compiti pianificati lo fanno lavorare in background, con quali sistemi esterni comunica e quali sue parti sono critiche per l’attività, per esempio il modulo d’ordine, i pagamenti o l’invio delle fatture. La versione di destinazione conviene sceglierla con un margine: PHP 8.4 riceverà patch di sicurezza fino al 31 dicembre 2028, PHP 8.3 fino alla fine del 2027, mentre un passaggio a PHP 8.2, il cui supporto finisce già alla fine del 2026, significherebbe un altro passaggio molto presto. Per Node.js, nella maggior parte dei casi, l’obiettivo è la release line 24.

Il secondo passo è la verifica del codice, e per il codice PHP la si può automatizzare in gran parte. PHPCompatibility è un insieme di regole di PHP_CodeSniffer che verifica se il codice è compatibile con una versione precisa di PHP, mentre Rector può eseguire in automatico una parte delle modifiche necessarie. Nessuno dei due sostituisce la verifica di una persona, ma mostrano in fretta se il volume di lavoro si misura in ore o in settimane, ed è proprio questo che serve per decidere tra l’aggiornamento e la ricostruzione. Per un sito WordPress vanno prima aggiornati i plugin e il tema, e solo dopo si cambia PHP.

Il terzo passo è un ambiente di test, cioè una copia del sito con il PHP o il Node.js nuovo, nella quale si provano tutte le operazioni critiche: moduli, pagamenti, invio di e-mail, importazione ed esportazione. In questa fase il registro degli errori conta più del controllo visivo, perché gli avvisi sulle funzioni obsolete vi compaiono molto prima che qualcosa si fermi. Il quarto passo è il cambio in un momento di basso carico, con la possibilità di tornare indietro: in un hosting con scelta della versione, la via del ritorno è lo stesso singolo clic con cui si è cambiato, e così il rischio è piccolo, purché il backup sia recente e qualcuno, nella prima settimana, segua il registro degli errori.

Per un’applicazione Node.js la logica è la stessa, cambiano solo gli strumenti. Il passaggio da una release line a quella successiva conviene farlo una alla volta, lanciando dopo ciascuna i test dell’applicazione, e un’attenzione particolare va ai package con codice compilato, perché vengono costruiti per una release line precisa di Node.js e dopo il passaggio vanno ricompilati. Prima vanno aggiornate le dipendenze che non supportano ancora la release line nuova, e solo dopo si cambia il runtime stesso, altrimenti gli errori delle due parti si mescolano ed è difficile capire quale delle due abbia causato che cosa.