Una mattina arriva l’avviso: è stata pubblicata una vulnerabilità grave di PHP, con punteggio critico e magari un exploit già in circolazione. Il server di produzione usa PHP 7.4, fuori supporto da quasi quattro anni, e il rilascio correttivo esiste solo per i rami 8.x. A quel punto qualcuno deve decidere in fretta: si migra subito l’applicazione a PHP 8, oppure si porta la correzione sulla versione installata?
In questo articolo mettiamo a confronto le due strade, backport e migrazione, con criteri concreti: tempi, rischi, impatto sull’applicazione e cosa resta aperto dopo. Proponiamo una sequenza di domande per arrivare alla scelta e spieghiamo perché, nella maggior parte dei casi, la risposta migliore è usarle entrambe in un ordine preciso.
Prima domanda: la CVE ti riguarda davvero?
Prima di scegliere come correggere, conviene verificare se c’è qualcosa da correggere. Una vulnerabilità di PHP raramente colpisce ogni installazione allo stesso modo. Le domande da fare sono poche e precise:
- il codice vulnerabile esiste nel ramo che usi, o è stato introdotto dopo?
- la vulnerabilità dipende da una SAPI, come PHP-FPM o CGI, e il server usa proprio quella?
- riguarda un’estensione, come phar, soap o intl, ed è caricata?
- servono configurazioni particolari del server web o di PHP, e sono presenti?
- il pacchetto installato è mantenuto da una distribuzione che ha già pubblicato la correzione?
Un esempio aiuta. La CVE-2019-11043 era sfruttabile solo con PHP-FPM dietro nginx e con una certa configurazione del blocco location: chi usava mod_php con Apache non era esposto a quella falla, anche con una versione vulnerabile. Se le risposte dicono che la CVE non ti riguarda, la decisione si sposta: va documentata l’analisi e il problema strutturale del ramo fuori supporto resta, ma non c’è un’urgenza da gestire nelle prossime ore.
Cosa offre il backport
Il backport della patch porta la correzione ufficiale sul ramo di PHP già installato e produce un pacchetto RPM o DEB con lo stesso numero di versione. Il codice dell’applicazione resta com’è, le estensioni e la configurazione pure. Per questo i tempi sono brevi e prevedibili: per un intervento d’urgenza su una singola CVE il nostro obiettivo è di 24 ore dall’analisi al rilascio, test con l’applicazione reale compresi.
Il rischio di regressione è basso perché la modifica tocca un punto preciso dell’interprete, e il rollback è semplice: basta reinstallare il pacchetto precedente. Il limite è altrettanto chiaro. Il backport chiude la vulnerabilità che ha motivato l’intervento e lascia il ramo fuori supporto, con tutto ciò che comporta per le CVE future, per le librerie che richiedono versioni recenti e per gli audit.
Perché il backport funzioni servono alcune condizioni. Bisogna sapere da dove arriva il PHP installato, che sia Remi, Software Collections, AppStream, i repository della distribuzione o deb.sury.org, perché il pacchetto corretto va ricostruito partendo da quello. Serve un ambiente di prova in cui far girare l’applicazione reale con il nuovo pacchetto prima del rilascio. E serve un modo ripetibile per installarlo su tutti i server coinvolti, che nel nostro caso è Ansible, con il pacchetto precedente pronto per il rollback.
Cosa offre la migrazione
Migrare a un ramo supportato è l’unica soluzione che chiude il problema alla radice: le correzioni future arriveranno con gli aggiornamenti ordinari dei pacchetti. Insieme alla sicurezza arrivano prestazioni migliori, la compatibilità con le librerie moderne e la possibilità di aggiornare CMS, plugin e SDK dei fornitori.
Il prezzo è il lavoro sull’applicazione. Tra PHP 5.6 e PHP 8 sono state rimosse estensioni e funzioni molto usate, come l’estensione mysql in PHP 7.0 o create_function() ed each() in PHP 8.0, e molti avvisi sono diventati errori. Ne parliamo nell’articolo sulle funzioni rimosse in PHP 8. Ogni modifica va testata sui percorsi critici, come ordini, pagamenti e integrazioni, e una migrazione fatta di corsa durante un’emergenza rischia di sostituire una vulnerabilità con un sito che non funziona.
Il confronto, criterio per criterio
| Criterio | Backport della patch | Migrazione a un ramo supportato |
|---|---|---|
| Tempi | ore o giorni per una singola CVE | settimane o mesi, secondo l’applicazione |
| Codice dell’applicazione | invariato | da adeguare e testare |
| Rischio di regressione | basso, modifica circoscritta | più alto, va gestito con i test |
| Rollback | reinstallazione del pacchetto precedente | ritorno al vecchio ambiente, da preparare |
| CVE future | da valutare una per una | coperte dagli aggiornamenti ordinari |
| Compatibilità con librerie e CMS | invariata, resta il blocco | risolta |
| Audit e conformità | misura documentabile, temporanea | soluzione definitiva |
Letta riga per riga, la tabella mostra che i punti di forza dell’una sono i punti deboli dell’altra. Il backport vince su tempi, rischio e rollback; la migrazione vince su tutto quello che riguarda il futuro, dalle CVE che verranno alla compatibilità con l’ecosistema.
I fattori che spostano la decisione
Dimensione e stato del codice
Un sito WordPress aggiornato, con tema e plugin mantenuti, può essere già quasi pronto per PHP 8: in quel caso la migrazione può essere anticipata e diventare la risposta alla CVE. Un gestionale scritto in casa dieci anni fa, con librerie copiate nel progetto e nessun test automatico, richiede un’analisi del codice prima ancora di stimare i tempi.
Esposizione
Un e-commerce raggiungibile da chiunque su Internet non può aspettare. Un’applicazione interna, accessibile solo dalla rete aziendale o tramite VPN, concede più margine, e in quel caso mitigazioni come il filtro degli accessi possono reggere qualche giorno in più. Conta anche cosa gestisce l’applicazione: dati personali, ordini e pagamenti alzano il costo di una compromissione e abbassano il tempo che ci si può concedere.
Sistema operativo
Se anche il sistema operativo è fuori supporto, come CentOS 7 dopo giugno 2024, la migrazione di PHP si intreccia con quella del server. Il backport di PHP protegge l’interprete, ma le librerie di sistema richiedono a loro volta una strategia.
Conformità e fornitori
Un audit PCI DSS o le misure richieste dalla NIS2 accettano più facilmente una vulnerabilità corretta e documentata con una data di migrazione che un componente fuori supporto senza piano. Anche un fornitore di pagamenti che annuncia la fine del supporto del proprio SDK per le versioni vecchie di PHP fissa una scadenza che il backport non sposta.
Perché spesso conviene combinarle
Le due strade non sono alternative. Il backport risponde alla domanda «come proteggo la produzione adesso?», la migrazione alla domanda «come smetto di avere questo problema?». Trattarle come una scelta secca porta a due errori opposti: migrare in fretta per chiudere una CVE, oppure correggere la CVE e dimenticarsi della migrazione fino alla prossima.
Immaginiamo un negozio online su PHP 7.4 con un tema personalizzato e una dozzina di moduli, di cui due non più aggiornati dal produttore. Esce una CVE che riguarda la sua configurazione. La sequenza sensata è applicare subito le mitigazioni possibili, installare entro poche ore il pacchetto con la patch, e intanto avviare l’analisi di compatibilità per PHP 8.x: sostituire o adattare i moduli abbandonati, aggiornare il tema, testare ordini e pagamenti, scegliere la data del passaggio. Quando la migrazione è completata, il backport non serve più.
Il backport compra tempo. La migrazione decide come usarlo.
Gli errori da evitare
- Migrare in emergenza senza test: un passaggio a PHP 8 fatto in una notte, senza provare i percorsi critici, sposta il rischio dalla sicurezza alla continuità del servizio.
- Considerare il backport una soluzione definitiva: ogni nuova CVE riapre la valutazione, e la distanza dal ramo supportato cresce ogni anno.
- Affidarsi solo alle mitigazioni: un filtro sul web server o una regola del firewall applicativo riducono il rischio, ma la vulnerabilità resta nel codice.
- Compilare PHP a mano sul server: un binario costruito fuori dal sistema dei pacchetti è difficile da tracciare, da aggiornare e da riportare indietro.
- Decidere senza inventario: senza sapere quali server usano quale versione e quale SAPI, ogni valutazione è una stima.
Se stai affrontando una CVE su un PHP fuori supporto e vuoi capire quale combinazione ha senso per la tua applicazione, scrivici indicando versione di PHP, sistema operativo e tipo di applicazione. Per un’urgenza in corso è attiva la reperibilità H24.
In conclusione
Quando una CVE colpisce un PHP fuori supporto, la prima cosa da stabilire è se riguarda davvero la tua configurazione: ramo, SAPI, estensioni, server web e chi mantiene il pacchetto. Se la risposta è sì, backport e migrazione rispondono a esigenze diverse. Il backport protegge la produzione in tempi brevi senza toccare l’applicazione, ma lascia il ramo fuori supporto. La migrazione chiude il problema e richiede lavoro sul codice e test che un’emergenza non concede. Dimensione del codice, esposizione, stato del sistema operativo e obblighi di conformità spostano l’equilibrio, ma la strategia più solida resta quasi sempre la stessa: backport subito, migrazione pianificata subito dopo.
