Indice dei contenuti dell'articolo:
Le vulnerabilità di PHP del 21 ottobre 2026, CVE-2026-109618 e CVE-2026-109619, hanno messo in evidenza un problema che molte aziende conoscono bene ma tendono a rimandare: i siti e le applicazioni che girano ancora su versioni di PHP non più supportate. Ne abbiamo parlato prima raccontando come si è sviluppata la vicenda PHP2Shell, poi spiegando come il repository di Remi abbia portato la correzione fino a PHP 7.4.
Resta però una domanda a cui nessuno, in questi giorni, ha dato una risposta: cosa fa chi ha ancora in produzione PHP 5.4, 5.6, 7.0, 7.1, 7.2 o 7.3, o chi usa PHP 7.4 e 8.0 su sistemi dove non esiste un pacchetto già corretto? Per queste situazioni, in Managed Server offriamo un servizio di backporting delle patch di sicurezza PHP: riportiamo le correzioni sulle versioni che non le ricevono più, così da permettervi di continuare a usarle in modo più sicuro, mentre pianificate con calma la migrazione.
Il problema dei sistemi PHP legacy
Ogni versione di PHP ha un ciclo di vita preciso: qualche anno di supporto attivo, poi un periodo di sole correzioni di sicurezza, poi la fine. Oggi il progetto PHP supporta solo i rami dalla 8.2 in su. Tutto quello che viene prima è ufficialmente abbandonato.
Nel mondo reale, però, le versioni vecchie sono ovunque:
- gestionali e software verticali sviluppati anni fa, di cui spesso nessuno ha più il codice sorgente o lo sviluppatore originale;
- e-commerce su versioni datate di Magento, PrestaShop o OpenCart, con personalizzazioni che non funzionano sulle versioni nuove;
- siti WordPress o Joomla con temi e plugin non più aggiornati, che si rompono al primo cambio di versione di PHP;
- intranet, portali aziendali, aree riservate e integrazioni con sistemi esterni che “funzionano e nessuno vuole toccare”;
- applicazioni che richiedono mesi di lavoro e un budget importante per essere riscritte o adeguate.
Finché non succede niente, una versione vecchia di PHP sembra un problema teorico. Poi arriva una vulnerabilità critica, sfruttabile da remoto e senza autenticazione, e il problema diventa concreto da un giorno all’altro.
Cosa è successo con CVE-2026-109618 e CVE-2026-109619
Le due vulnerabilità corrette il 21 ottobre consentono l’esecuzione di codice da remoto senza autenticazione, cioè la possibilità per un attaccante di eseguire comandi sul server senza disporre di alcun account. Riguardano tutte le installazioni di PHP che servono richieste web, e codici d’attacco erano già pubblici prima ancora del rilascio delle patch.
Le correzioni ufficiali sono arrivate per PHP 8.2, 8.3, 8.4 e 8.5. Per PHP 7.4, 8.0 e 8.1 il team di sicurezza di PHP ha messo a disposizione una correzione minima dei sorgenti, che il repository di Remi ha trasformato in pacchetti pronti per Red Hat, AlmaLinux e Rocky Linux. Per tutte le versioni precedenti, da PHP 5.4 a PHP 7.3, non esiste alcuna correzione: né dal progetto PHP, né dai principali repository.
Chi ha un sito su PHP 7.2 o 5.6, oggi, ha quindi davanti tre strade: migrare in fretta, accettare il rischio, oppure riportare la correzione sulla propria versione.
Il costo di non fare nulla
Lasciare un sito su una versione vulnerabile di PHP, sperando che nessuno lo trovi, è una scommessa che si perde quasi sempre. Gli attacchi a vulnerabilità di questo tipo non sono mirati: sono scansioni automatiche che passano su milioni di indirizzi alla ricerca di qualunque server risponda nel modo giusto. Non serve essere un bersaglio interessante, basta essere raggiungibili.
Le conseguenze di una compromissione vanno ben oltre il sito: dati dei clienti sottratti, con gli obblighi di notifica previsti dal GDPR; il server usato per inviare spam o attaccare altri sistemi, con l’indirizzo IP che finisce nelle blacklist e la posta aziendale che smette di arrivare; il sito segnalato come pericoloso dai browser e dai motori di ricerca; giorni di fermo per ripulire, ricostruire e ripristinare. Costi che, quasi sempre, superano di molto quello di un intervento preventivo.
Cos’è il backporting delle patch
Fare il backport di una patch significa prendere una correzione scritta per una versione recente del software e adattarla a una versione più vecchia. Sembra semplice, ma non lo è: il motore di PHP cambia molto tra un ramo e l’altro, e una correzione scritta per PHP 8.2 quasi mai si applica così com’è al codice di PHP 7.2 o 5.6. Bisogna capire cosa corregge, ritrovare nel codice vecchio il punto equivalente, riscrivere la modifica rispettando le strutture di quella versione e poi verificare che funzioni davvero.
È lo stesso lavoro che fanno i grandi fornitori di distribuzioni Linux con supporto a lungo termine, che mantengono per anni versioni di PHP e di altri software ben oltre la loro fine ufficiale, riportando su di esse le sole correzioni di sicurezza.
Il servizio di backporting PHP di Managed Server
Il nostro servizio si rivolge a chi usa versioni di PHP dalla 5.4 alla 8.0 e ha bisogno di continuare a farlo per un periodo, senza restare esposto alle vulnerabilità critiche. In concreto, ci occupiamo di:
- analisi della situazione: versioni di PHP in uso, modalità di installazione, sistema operativo, applicazioni coinvolte e loro esposizione su Internet;
- adattamento della patch alla vostra versione di PHP, partendo dalle correzioni ufficiali e da quelle già riportate sui rami più recenti;
- compilazione dei pacchetti a partire da quelli che già usate, per esempio i pacchetti RPM del repository di Remi, mantenendo intatte configurazioni ed estensioni;
- test in un ambiente di prova il più possibile identico alla produzione, con la vostra applicazione reale;
- distribuzione in produzione in modo controllato e automatizzato con Ansible, con il riavvio di tutti i processi PHP e un piano di ritorno indietro in caso di problemi;
- mitigazioni di configurazione indicate dagli avvisi ufficiali, applicate dove la correzione da sola non basta.
Il risultato è che il vostro sito o la vostra applicazione possono continuare a girare sulla versione di PHP per cui sono stati scritti, con la correzione della vulnerabilità applicata.
A chi è utile
Il servizio è pensato per aziende e professionisti che si trovano in una di queste situazioni:
- hanno un’applicazione critica su PHP 5.x o 7.x e non possono fermarla per una migrazione d’urgenza;
- stanno già pianificando la migrazione, ma hanno bisogno di qualche mese per completarla in modo ordinato;
- gestiscono molti siti su versioni diverse di PHP e vogliono metterli tutti in sicurezza con un unico intervento coordinato;
- usano PHP 7.4 o 8.0 su sistemi per cui non è disponibile un pacchetto già corretto;
- hanno software di terze parti che il fornitore non aggiorna più e che non può essere sostituito a breve.
Cosa il backport fa, e cosa non fa
Preferiamo essere chiari, perché è un tema in cui la chiarezza vale più di qualunque promessa commerciale.
Il backport corregge le vulnerabilità per cui viene realizzato, come CVE-2026-109618 e CVE-2026-109619, e riduce in modo concreto il rischio di compromissione legato a quelle falle. È una soluzione seria, la stessa adottata dai fornitori di distribuzioni enterprise.
Il backport non trasforma una versione vecchia in una versione supportata. PHP 5.6 resta PHP 5.6: non riceve miglioramenti, non beneficia di tutte le correzioni accumulate negli anni nei rami successivi, e ogni nuova vulnerabilità critica richiederà un nuovo intervento. Per questo lo consideriamo una soluzione ponte: il modo per mettere in sicurezza subito ciò che non può essere migrato subito, e per affrontare la migrazione con i tempi giusti invece che in emergenza.
Quando il momento arriva, possiamo affiancarvi anche nella migrazione a una versione di PHP supportata: analisi della compatibilità, ambiente di prova con la nuova versione, correzione dei problemi, passaggio in produzione.
Perché affidarsi a Managed Server
Il backport di una patch di sicurezza è un lavoro delicato: richiede di conoscere il motore di PHP, la costruzione dei pacchetti, la gestione dei server in produzione e la responsabilità di toccare sistemi che non devono fermarsi. È il nostro lavoro quotidiano: gestiamo Server Dedicati e infrastrutture con decine di versioni di PHP diverse, ci occupiamo di assistenza sistemistica Linux su sistemi Red Hat, AlmaLinux e Rocky Linux, e automatizziamo il patching dei sistemi con Ansible.
Non vi chiediamo di migrare il vostro sito da noi per offrirvi il servizio: possiamo intervenire anche sui vostri server, ovunque si trovino, in accordo con chi li gestisce oggi.
Domande frequenti
Per quali versioni di PHP è disponibile il backport?
Per le versioni dalla 5.4 alla 8.0, comprese PHP 5.6, 7.0, 7.1, 7.2, 7.3 e 7.4. Per PHP 7.4 e 8.0 interveniamo quando sul vostro sistema non è già disponibile un pacchetto corretto.
Devo cambiare hosting per usare il servizio?
No. Possiamo lavorare sui vostri server, anche se gestiti da un altro fornitore, in accordo con chi ne ha la responsabilità.
Il backport rallenta il sito o cambia il comportamento dell’applicazione?
La correzione è mirata alla vulnerabilità e non modifica il funzionamento normale di PHP. Per questo ogni pacchetto viene provato con la vostra applicazione prima di arrivare in produzione.
Con il backport posso restare per sempre sulla mia versione di PHP?
No, ed è giusto dirlo. Il backport mette in sicurezza contro le vulnerabilità corrette, ma la soluzione definitiva resta la migrazione a una versione supportata. Vi aiutiamo a pianificarla con i tempi giusti.
Quanto tempo serve per avere la versione corretta?
Dipende dalla versione di PHP, da quanto il codice si discosta da quello dei rami corretti e dalla complessità dell’ambiente. Dopo la prima analisi vi diamo una stima chiara dei tempi e, nel frattempo, applichiamo subito le mitigazioni di configurazione che riducono l’esposizione.
Cosa succede se esce una nuova vulnerabilità critica?
Ogni nuova vulnerabilità che riguarda la vostra versione richiede una valutazione e, se necessario, un nuovo backport. Ne parliamo insieme in base alle vostre esigenze.
Contattateci
Se avete siti o applicazioni su PHP dalla 5.4 alla 8.0 e volete metterli in sicurezza contro CVE-2026-109618 e CVE-2026-109619 senza essere costretti a una migrazione d’emergenza, parliamone. Analizziamo la vostra situazione, vi diciamo con chiarezza cosa si può fare, in quanto tempo e con quali limiti, e vi aiutiamo a proteggere oggi ciò che migrerete domani.
