Il 31 dicembre 2026 PHP 8.2 riceve l’ultimo giorno di supporto di sicurezza. Mancano poco più di tre mesi, che bastano per una migrazione ordinata se si comincia adesso e diventano pochi se si aspetta novembre, quando molte aziende entrano nel periodo più intenso dell’anno e nessuno vuole toccare i server di produzione. Chi è su PHP 8.2 si trova quindi nella posizione migliore possibile, perché è ancora protetto e ha il tempo per decidere con calma.
In questo articolo vediamo cosa succede davvero il 1° gennaio 2027, quando il PHP 8.2 della distribuzione continua a essere corretto, come scegliere il ramo di destinazione, cosa cambia nel codice tra PHP 8.2 e i rami successivi e un calendario possibile per arrivare alla scadenza senza fretta, con un piano di riserva se la migrazione non è pronta.
Le date di PHP 8.2
PHP 8.2.0 è uscito l’8 dicembre 2022 con le classi in sola lettura, i tipi in forma normale disgiuntiva, la nuova estensione Random e l’attributo SensitiveParameter per nascondere i dati sensibili nelle tracce degli errori. Il supporto attivo si è chiuso il 31 dicembre 2024; da allora il ramo riceve solo correzioni di sicurezza, che terminano il 31 dicembre 2026. Sono le date della riforma del ciclo di rilascio approvata nel 2024, che ha dato a PHP 8.2 un anno di sicurezza in più rispetto alla regola precedente, come spieghiamo nell’articolo sul ciclo di vita delle versioni di PHP.
Il 1° gennaio 2027 non si romperà nulla. I siti continueranno a funzionare, i pacchetti installati resteranno quelli. L’unica differenza riguarda le nuove vulnerabilità, perché la prima pubblicata nel 2027 verrà corretta nei rami dall’8.3 in su e non nell’8.2. Da quel momento ogni nuovo avviso di sicurezza andrà valutato a mano, finché l’applicazione non avrà cambiato ramo.
Se il tuo PHP 8.2 arriva dalla distribuzione
Come per ogni ramo, la data che conta per il tuo server dipende da chi mantiene il pacchetto. Per PHP 8.2 alcune distribuzioni importanti vanno oltre la scadenza del progetto:
| Origine del pacchetto | Correzioni fino a | Note |
|---|---|---|
| php.net e build compilate dai sorgenti | 31 dicembre 2026 | fine del supporto del progetto |
| Debian 12, pacchetto php8.2 | giugno 2028 | con il progetto Debian LTS, dopo la fine del supporto regolare di giugno 2026 |
| RHEL 8 e 9, stream PHP 8.2 | maggio 2029 | ciclo di vita degli Application Streams; Rocky Linux e AlmaLinux ricostruiscono gli stessi pacchetti |
| Ubuntu LTS | nessun pacchetto | 22.04 usa PHP 8.1, 24.04 usa PHP 8.3: un PHP 8.2 su Ubuntu arriva da un repository esterno |
| Remi, deb.sury.org e altri repository | da verificare | controlla il changelog del pacchetto e le comunicazioni del manutentore |
Se il PHP 8.2 viene da Debian 12 o da uno stream di RHEL e i pacchetti vengono aggiornati con regolarità, la scadenza del 31 dicembre non è un’emergenza: il calendario della migrazione può seguire i tempi dell’applicazione. Resta comunque da pianificare, perché l’ecosistema si muove indipendentemente dalla distribuzione. Se invece il PHP 8.2 arriva da un repository esterno o da una compilazione propria, la data che conta è quella del progetto. Per capire con certezza quale situazione riguarda ciascun sito, puoi seguire i passi descritti in quale versione di PHP sto usando.
Scegliere il ramo di destinazione
Conviene sempre scegliere il ramo più recente supportato ufficialmente da tutte le componenti dell’applicazione. Ogni ramo in più vale un anno di supporto in più, e il lavoro per passare da 8.2 a 8.4 o a 8.5 non è molto diverso da quello per arrivare a 8.3.
- PHP 8.3, supportato fino alla fine del 2027, ha senso solo se una dipendenza importante non supporta ancora i rami successivi: dà un anno di respiro e obbliga a una nuova migrazione a breve;
- PHP 8.4, supportato fino alla fine del 2028, è la scelta prudente per la maggior parte delle applicazioni: è in circolazione da quasi due anni ed è ampiamente supportato da framework e CMS;
- PHP 8.5, supportato fino alla fine del 2029, è la scelta migliore se le dipendenze lo supportano già: Laravel 12 e 13, per esempio, lo includono tra le versioni compatibili;
- PHP 8.6 è previsto per il 19 novembre 2026: conviene attendere i primi rilasci di manutenzione e il supporto ufficiale delle proprie dipendenze prima di usarlo in produzione.
I requisiti delle piattaforme spingono nella stessa direzione: Laravel 13 e Drupal 11 richiedono almeno PHP 8.3, Symfony 8 almeno PHP 8.4, e WordPress raccomanda PHP 8.3 o superiore. Composer può dire in pochi secondi quali pacchetti impediscono il passaggio a un certo ramo:
# Quali pacchetti installati impediscono di usare PHP 8.4 (alias: composer why-not)
composer prohibits php 8.4
# Con l'interprete di destinazione: le estensioni e le versioni richieste sono presenti?
php8.4 /usr/local/bin/composer check-platform-reqsCosa cambia nel codice dopo PHP 8.2
Il passaggio da PHP 8.2 ai rami successivi è di norma il più leggero tra quelli che abbiamo descritto in questa serie, perché non attraversa una versione principale. Le guide di migrazione del manuale indicano però alcuni punti da controllare:
- PHP 8.3 introduce le costanti di classe tipizzate e la funzione
json_validate(), e depreca poche cose, come la chiamata aget_class()senza argomenti; - PHP 8.4 depreca i parametri resi nullabili in modo implicito, cioè scritti come
Tipo $x = nullinvece di?Tipo $x = null, molto frequenti nel codice e nelle librerie più datate; rimuove il livello di erroreE_STRICT; sposta in PECL le estensioni IMAP, OCI8, PDO_OCI e Pspell; alza i requisiti minimi di alcune librerie, come OpenSSL 1.1.1; - PHP 8.5 depreca l’operatore backtick come alias di
shell_exec(), i nomi di cast non canonici come(integer)e(boolean)e l’uso dinullcome chiave di array.
Il punto da verificare per primo sono le estensioni spostate in PECL, perché sono le uniche che possono impedire all’applicazione di funzionare. Due comandi bastano per capire se ti riguardano:
# Estensioni caricate oggi che da PHP 8.4 non fanno più parte della distribuzione
php -m | grep -iE '^(imap|oci8|pdo_oci|pspell)$'
# Righe di codice che le usano
grep -rnE '\bimap_[a-z_]+\(|\boci_[a-z_]+\(|\bpspell_[a-z_]+\(' --include='*.php' /var/www/sito | wc -lPer il resto vale il metodo descritto per i rami PHP 8.0 e 8.1: un ambiente di prova con la versione di destinazione, i log di deprecazione attivi e i percorsi principali dell’applicazione eseguiti a mano o con i test automatici.
Un calendario senza fretta
Tre mesi sono sufficienti per molte applicazioni, a patto di usarli bene. Un calendario possibile, da adattare alla dimensione del codice e al tipo di attività, è questo:
- settembre: inventario dei server e delle applicazioni su PHP 8.2, origine dei pacchetti, versioni di PHP supportate da CMS, framework, plugin e librerie, scelta del ramo di destinazione;
- ottobre: ambiente di prova con il nuovo ramo, aggiornamento delle dipendenze, raccolta di errori e deprecazioni dai log;
- novembre: correzioni, test dei percorsi critici, preparazione del rilascio con un piano di rollback;
- prima dei picchi stagionali: rilascio in produzione in una finestra a basso traffico, tenendo pronta la configurazione precedente di PHP-FPM per tornare indietro in pochi minuti.
Per un e-commerce la finestra giusta conta quanto il lavoro tecnico. Se il rilascio rischia di cadere nelle settimane di maggior traffico, è più sensato rimandarlo a gennaio e proteggere la produzione nel frattempo, piuttosto che cambiare ramo sotto pressione.
Se non fai in tempo
Arrivare a gennaio ancora su PHP 8.2 non è una catastrofe, se la situazione è gestita. Le strade sono tre, in ordine di preferenza:
- pacchetti della distribuzione ancora mantenuti: su Debian 12 e sugli stream PHP 8.2 di RHEL 8 e 9 le correzioni proseguono, a patto di aggiornare con regolarità;
- backport delle patch di sicurezza: per i pacchetti che non ricevono più correzioni, le patch scritte per i rami supportati vengono adattate al ramo 8.2 e rilasciate al posto dei pacchetti in uso, senza toccare l’applicazione; è il servizio che offriamo per i rami fuori supporto, con l’obiettivo di 24 ore dall’analisi al rilascio per un intervento d’urgenza su una singola CVE;
- mitigazioni: disattivazione delle estensioni non usate, protezione delle aree amministrative, filtri sulle richieste. Riducono l’esposizione ma non chiudono le vulnerabilità.
In tutti e tre i casi conviene fissare per iscritto una data di fine della fase transitoria e una data di migrazione. È la differenza tra una scelta consapevole, facile da spiegare a un auditor, e un rinvio senza scadenza.
In sintesi
PHP 8.2 esce dal supporto di sicurezza il 31 dicembre 2026. Il giorno dopo i siti continuano a funzionare, però da lì in poi le nuove vulnerabilità non verranno più corrette dal progetto. Chi usa il PHP 8.2 di Debian 12 o degli stream di RHEL 8 e 9 riceverà correzioni ancora per anni; chi lo ha da un repository esterno o compilato in proprio deve guardare alla data del progetto. Il ramo di destinazione consigliato è PHP 8.4, o PHP 8.5 se le dipendenze lo supportano già, e il lavoro sul codice è di norma contenuto: deprecazioni da pulire e, soprattutto, le estensioni spostate in PECL con PHP 8.4 da verificare per prime. Con un calendario di tre mesi, un ambiente di prova e un piano di rollback la migrazione si chiude prima della scadenza; se la finestra non c’è, pacchetti mantenuti, backport e mitigazioni proteggono la produzione fino a una data di migrazione decisa per tempo.
