Vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619, come il repository REMI permetta di utilizzare versioni PHP dalla 7.4 in poi

Nei giorni scorsi abbiamo seguito passo dopo passo la vicenda di PHP2Shell, le due vulnerabilità critiche di PHP: prima l’avviso preventivo, poi la fuga di notizie, le proof of concept pubbliche e infine l’avviso ufficiale con le versioni corrette. In questo articolo affrontiamo un aspetto che interessa da vicino chi gestisce server Red Hat, AlmaLinux, Rocky Linux o CentOS Stream: il ruolo del repository di Remi Collet, che ha reso disponibile la correzione anche per versioni di PHP che il progetto ufficiale non supporta più, a partire da PHP 7.4.

Cosa è successo, in breve

Il 21 ottobre 2026 il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, che correggono due vulnerabilità critiche:

• CVE-2026-109618: esecuzione di codice da remoto tramite una corruzione dei dati interni della richiesta quando PHP esaurisce la memoria;
• CVE-2026-109619: esecuzione di codice da remoto tramite uno stato interno che sopravvive alla liberazione della memoria e viene riutilizzato da una richiesta successiva dello stesso processo.

Entrambe possono essere sfruttate senza autenticazione, riguardano tutte le installazioni di PHP che servono richieste web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed) e sono accompagnate da codici d’attacco già circolati pubblicamente prima ancora del rilascio delle patch.

L’avviso ufficiale conteneva due indicazioni importanti per chi usa PHP su Enterprise Linux. La prima: PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti dal progetto PHP, anche se, data la gravità, il team di sicurezza ha messo a disposizione delle correzioni minime dei sorgenti per PHP 7.4, 8.0 e 8.1, destinate a chi compila PHP da sé o non ha un fornitore con supporto a lungo termine. La seconda: chi usa il repository rpms.remirepo.net, mantenuto su base volontaria, veniva invitato a passare ai pacchetti della distribuzione o a compilare dai sorgenti, perché il repository non avrebbe avuto aggiornamenti in giornata.

Le cose sono andate meglio del previsto.

Il repository di Remi e perché è così importante

Per chi lavora con Red Hat Enterprise Linux e le sue derivate, il repository di Remi Collet è un’istituzione. Le distribuzioni enterprise offrono una o due versioni di PHP per l’intero ciclo di vita del sistema operativo, spesso già vecchie al momento del rilascio. Il repository di Remi permette di installare praticamente qualunque versione di PHP, anche più versioni sullo stesso server, ognuna con il proprio PHP-FPM: è ciò che consente a migliaia di hosting provider e di aziende di far convivere sulla stessa macchina un sito su PHP 8.4 e un vecchio gestionale che gira solo su PHP 7.4.

Remi Collet, sviluppatore che contribuisce da anni al progetto PHP, mantiene questo repository da molto tempo, e tra le sue caratteristiche più apprezzate c’è proprio il supporto prolungato delle versioni di PHP uscite dal ciclo di vita ufficiale, con le correzioni di sicurezza riportate sulle versioni vecchie quando possibile.

Il backport per PHP 7.4, 8.0 e 8.1

Lo stesso 21 ottobre, nonostante l’avvertimento dell’avviso ufficiale, nel repository di Remi sono comparsi i pacchetti aggiornati per tutti i rami supportati e, soprattutto, per tre rami ormai fuori supporto. Lo abbiamo verificato direttamente sui pacchetti pubblicati:

Per i rami 7.4, 8.0 e 8.1 la versione di PHP resta la stessa e cambia solo il numero di rilascio del pacchetto: è il segno tipico di un backport, cioè di una correzione riportata dal codice nuovo a quello vecchio. Il changelog dei pacchetti lo conferma, con la stessa voce per tutti e tre i rami:

Mitigation fix: Avoid state corruption via bailout. CVE-2026-109618, CVE-2026-109619

I pacchetti sono disponibili sia nella forma a collezioni separate (php74-php-*, php80-php-*, php81-php-*), quella che permette di installare più versioni in parallelo, sia nei flussi modulari (php:remi-7.4, php:remi-8.0, php:remi-8.1), per Enterprise Linux 8 e 9 e, dove il ramo è presente, per Enterprise Linux 10.

Due precisazioni importanti. La prima: Remi stesso descrive la modifica come una correzione di mitigazione. È la correzione minima preparata dal team di sicurezza di PHP per i rami vecchi, non l’insieme completo delle modifiche delle versioni supportate. La seconda: proprio per questo, il backport è una soluzione per mettere in sicurezza subito i sistemi legacy, non un motivo per restare su PHP 7.4 o 8.0. La migrazione a una versione supportata resta necessaria.

Come aggiornare

Su un server che usa il repository di Remi, l’aggiornamento è quello di sempre. Per le versioni installate come collezioni separate:

dnf --refresh upgrade 'php74-*' 'php80-*' 'php81-*'

Per chi usa i flussi modulari, basta aggiornare i pacchetti php-* con il flusso già attivo. In entrambi i casi conviene verificare che il pacchetto installato contenga la correzione:

rpm -q --changelog php74-php-common | head -5

La prima voce deve riportare i due CVE. Poi c’è il passaggio che molti dimenticano: riavviare tutti i processi PHP, cioè ogni pool di PHP-FPM (ad esempio systemctl restart php74-php-fpm) o il web server nel caso di mod_php. Finché i vecchi processi restano in memoria, il codice vulnerabile continua a girare anche se il pacchetto sul disco è aggiornato. Su un server con molte versioni di PHP è facile aggiornarne cinque e riavviarne quattro.

E per le versioni precedenti a PHP 7.4?

Qui le notizie sono meno buone. Per PHP 7.3, 7.2, 7.1, 7.0 e 5.6 non è arrivata alcuna correzione: né dal progetto PHP, che ha preparato il backport solo per 7.4, 8.0 e 8.1, né dal repository di Remi, dove i pacchetti di questi rami sono fermi alle versioni precedenti alla vulnerabilità. Chi ha ancora siti su queste versioni ha davanti due strade.

La strada giusta: l’aggiornamento

Portare l’applicazione almeno su PHP 7.4, che oggi ha la correzione, o meglio ancora direttamente su un ramo di PHP 8 supportato. Per un sito di qualche anno fa il salto da PHP 7.2 o 7.3 a 7.4 è spesso indolore. Il passaggio a PHP 8 richiede più lavoro su codice vecchio e plugin non aggiornati, ma è l’unica soluzione che chiude davvero il problema, anche per le vulnerabilità future.

La strada per chi non può aspettare: il backport fatto in casa

Quando la migrazione non è possibile in tempi brevi, per esempio per un gestionale di cui nessuno ha più il codice o un’applicazione che richiede mesi di adeguamento, resta la possibilità di riportare la correzione in autonomia sulla versione in uso. Per chi ha dimestichezza con rpmbuild, il punto di partenza migliore sono proprio i pacchetti di Remi:

• scaricare il pacchetto sorgente (SRPM) della propria versione dal repository di Remi, ad esempio quello di PHP 7.3, e quello di PHP 7.4.33-31 che contiene la correzione;
• estrarre dal pacchetto di PHP 7.4 la patch aggiunta per i due CVE e confrontarla con il codice della versione vecchia;
• adattare la patch al codice di PHP 7.3 o della versione in uso: il motore di PHP cambia da una versione all’altra e quasi mai una patch si applica senza modifiche;
• aggiungere la patch al file spec, incrementare il numero di rilascio e ricompilare il pacchetto, preferibilmente in un ambiente pulito come mock;
• eseguire i test di PHP e installare il pacchetto prima in un ambiente di prova identico alla produzione, verificando che l’applicazione funzioni;
• distribuire il pacchetto in produzione da un proprio repository interno, così che gli aggiornamenti futuri di Remi non lo sovrascrivano per errore e che la distribuzione su più server possa essere automatizzata.

È un lavoro che richiede competenze serie: conoscere la struttura dei pacchetti RPM, saper leggere e adattare codice C del motore di PHP, e soprattutto saper verificare che la correzione funzioni senza introdurre nuovi problemi. Una patch adattata male può dare un falso senso di sicurezza o rendere instabile il servizio. E va considerata per quello che è: una soluzione ponte in attesa della migrazione, non una sistemazione definitiva.

Nel frattempo: le mitigazioni

Per tutti i sistemi che non possono essere aggiornati subito, valgono le misure indicate nell’avviso ufficiale e che abbiamo riportato nel nostro articolo precedente: disattivare session.upload_progress.enabled nella configurazione di PHP-FPM o in php.ini, ridurre post_max_size, impostare il limite di memoria in modo che le applicazioni non possano modificarlo, usare limiti a livello di cgroup o container e riavviare tutti i processi. Sono misure che riducono il rischio su alcuni percorsi d’attacco, ma il progetto PHP è esplicito: non rendono sicura un’installazione.

Cosa stiamo facendo noi

Come avevamo anticipato, ci stiamo adoperando con Ansible per il patching di tutti i sistemi che gestiamo. La disponibilità dei pacchetti di Remi, anche per i rami legacy, ci permette di distribuire le correzioni in modo coordinato su tutte le versioni di PHP presenti sui server, con il riavvio di ogni pool di PHP-FPM e la verifica del changelog dei pacchetti installati. Per i clienti che usano ancora versioni precedenti a PHP 7.4, valuteremo caso per caso la migrazione o le misure da adottare.

Se il vostro server non è gestito da noi e avete bisogno di aiuto per aggiornare, migrare un’applicazione da una versione obsoleta di PHP o preparare un backport per un sistema che non può essere aggiornato, la nostra assistenza sistemistica Linux è a disposizione.

Un grazie a Remi

Vale la pena dirlo: in una giornata in cui migliaia di amministratori di sistema avevano bisogno di risposte rapide, un repository mantenuto su base volontaria ha messo a disposizione le correzioni per sette rami di PHP, compresi tre che il progetto ufficiale non supporta più. È il genere di lavoro silenzioso su cui si regge una parte enorme di Internet, e che di solito si nota solo quando manca. Se il vostro business si appoggia ogni giorno a quei pacchetti, considerate di sostenere il progetto.

Fonti

• PHP, “Security advisory: Critical remote code execution vulnerabilities, update now” del 21 ottobre 2026
• Repository di Remi Collet, rpms.remirepo.net: pacchetti e changelog verificati il 22 ottobre 2026
• Managed Server, PHP2Shell: due vulnerabilità critiche in PHP