Il 31 dicembre 2026 PHP 8.2 riceve le ultime correzioni di sicurezza. Ogni ramo di PHP ha due anni di supporto attivo e poi due di sole correzioni di sicurezza, come si legge sulla pagina delle versioni supportate, e per la 8.2 il secondo periodo si chiude con l'anno. Dal 1° gennaio 2027 è a fine vita, end of life in inglese.
Secondo W3Techs, al 9 ottobre 2026 la 8.2 girava sul 28,3% dei siti in PHP 8, seconda solo alla 8.3. Sugli stessi dati abbiamo fatto un conto. Il 35,3% dei siti in PHP è ancora sulle versioni 5 e 7, senza correzioni da anni, e fra quelli in PHP 8 il 21,6% usa la 8.0 o la 8.1, anche loro fuori supporto. Oggi gira su una versione supportata circa la metà dei siti in PHP; tolta la 8.2, dal 1° gennaio sarà circa un terzo.
Cosa succede dopo il 31 dicembre
Il sito continua a funzionare, e per questo la scadenza si rimanda. Cambia quello che succede alla prossima falla scoperta nel linguaggio, perché la correzione esce solo per le versioni supportate.
È quello che si è visto il 21 ottobre. Per le due falle critiche chiamate php2shell il progetto PHP ha pubblicato le versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12, mentre per la 8.1 e le precedenti non è uscita nessuna nuova versione, solo delle correzioni minime del codice sorgente per chi compila PHP da sé. Chi è sulla 8.2 questa volta ha risolto con un aggiornamento di routine, cosa che da gennaio non potrà più fare.
Nel giugno 2024 era successo lo stesso con CVE-2024-4577, una falla che permetteva di eseguire codice da remoto su PHP in modalità CGI sui server Windows: corretta il 6 giugno nelle versioni allora supportate, non nella 8.0. Secondo Wiz, l'8 giugno il gruppo ransomware TellYouThePass la stava già usando.
A quale versione passare
Dal 1° gennaio le versioni supportate sono tre: la 8.3 riceve correzioni di sicurezza fino al 31 dicembre 2027, la 8.4 fino al 31 dicembre 2028, la 8.5 fino al 31 dicembre 2029. Nella maggior parte dei casi noi consigliamo la 8.4, che le librerie e i CMS più diffusi ormai supportano e che dà due anni di margine. La 8.3 è un salto più corto, ma fra un anno si ricomincia; la 8.5 dura di più ed è anche la più giovane, quindi prima di sceglierla va controllata dipendenza per dipendenza.
WordPress indica la 8.3 come versione minima raccomandata. Guarda anche cosa fa il tuo hosting, che non sempre aspetta la data ufficiale: Acquia ha tolto la 8.2 il 1° ottobre 2026 e ha portato d'ufficio a PHP 8.4 tutti gli ambienti rimasti.
Cosa si rompe di solito nella migrazione
Passare dalla 8.2 alla 8.4 raramente si risolve cambiando versione nel pannello dell'hosting. Il caso più netto sono le estensioni uscite dalla distribuzione standard: con la 8.4 non ci sono più IMAP, OCI8, PDO_OCI e PSpell, e un gestionale che legge una casella di posta con le funzioni imap_* smette di farlo. Poi c'è il framework. Laravel, Symfony e gli altri dichiarano con quali versioni di PHP funzionano, e spesso prima di aggiornare PHP bisogna aggiornare loro. Un plugin o una libreria abbandonati da anni vanno sostituiti, o corretti a mano.
Le deprecazioni invece non bloccano niente. La 8.4 segnala, per esempio, i parametri che accettano null in modo implicito, come function f(Tipo $x = null): il sito funziona, ma su un codice vecchio gli avvisi possono riempire i log fino a nascondere gli errori veri.
Per trovarli bisogna far girare il codice vero sulla nuova versione. Su WordPress si aggiungono i problemi di temi e plugin, di cui abbiamo scritto nell'articolo sulle vulnerabilità WordPress che troviamo negli audit.
Come impostare l'aggiornamento
- Controlla con quale versione gira il sito: la mostra il pannello dell'hosting, oppure una pagina con
phpinfo()su un ambiente non pubblico.php -vda terminale può dare una versione diversa da quella del server web. - Fai l'inventario di quello che gira sopra: framework, CMS, plugin, estensioni PHP, librerie in
composer.json. Con Composer,composer why-not php 8.4elenca i pacchetti che bloccano il passaggio. - Prepara una copia del sito su un ambiente di prova con la nuova versione e prova i flussi che contano: login, pagamenti, invio email, importazioni, stampe.
- Pianifica il passaggio in produzione con il ritorno indietro già pronto.
Se a gennaio la migrazione non sarà finita, ci sono distribuzioni e fornitori che continuano a pubblicare correzioni per le versioni fuori supporto: è la strada che php.net indica a chi è ancora sulla 8.1. Copre qualche mese, a patto di sapere da chi arrivano le correzioni e di tenere comunque in calendario il passaggio.
Se il tuo sito o il tuo gestionale gira su PHP 8.2 o su una versione più vecchia, scrivici o guarda come lavoriamo sulla migrazione PHP. Partiamo da un'analisi del codice e ti diciamo quanto lavoro c'è prima di toccare la produzione.