In breve: il repository PHP Remi fornisce versioni attuali di PHP per Fedora e la famiglia RHEL, o come module stream, che sostituisce il PHP di sistema, o come Software Collection, che installa più versioni in parallelo. Le correzioni di PHP2Shell 8.2.35, 8.3.36, 8.4.27 e 8.5.12 sono state annunciate lì il 22 ottobre 2026. Verifichi singolarmente ogni versione installata e riavvii ogni servizio corrispondente.
Perché così tanti server RHEL ottengono PHP da Remi
Le distribuzioni aziendali come RHEL, AlmaLinux e Rocky Linux puntano su una lunga stabilità. Forniscono pochi rami PHP e li mantengono per anni. Molte applicazioni richiedono però versioni più recenti di quelle offerte dalla distribuzione. Qui interviene il repository di Remi Collet, da lungo tempo manutentore di pacchetti PHP nell'ambito Fedora e RHEL.
Remi compila le versioni di PHP a breve distanza dai rilasci ufficiali. Su PHP2Shell nel blog del repository è comparso il 22 ottobre 2026 un articolo sulle versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Vi sono citate le due vulnerabilità critiche CVE-2026-109618 e CVE-2026-109619 e l'aggiornamento è raccomandato con urgenza. Le segnalazioni di sicurezza di Red Hat non valgono per questi pacchetti; cosa segnali Red Hat per i propri pacchetti è nell'articolo RHEL, AlmaLinux e Rocky Linux: verificare la patch PHP.
Due vie: module stream o Software Collection
Secondo il blog di Remi, le build per Enterprise Linux dalla versione 8 in poi sono disponibili in due modi. Quale sia usato sul Suo server determina come verifica e riavvia.
| Via | Repository | Effetto | Servizio tipico |
|---|---|---|---|
Module stream, ad esempio php:remi-8.3 |
remi-modular | sostituisce il PHP di sistema, una versione predefinita | php-fpm |
Software Collection, ad esempio php83 |
remi-safe | versione aggiuntiva in parallelo in un percorso proprio | servizio proprio per versione, ad esempio php83-php-fpm |
| Pacchetti di test e release candidate | remi-modular-test, remi-test | versioni preliminari | non per la produzione |
Le Software Collection si trovano tipicamente sotto /opt/remi/phpXY, la loro configurazione sotto /etc/opt/remi/phpXY. È pratico per gestire su un server applicazioni vecchie e nuove. È però anche il motivo più frequente per cui una versione viene trascurata durante l'aggiornamento.
Un'osservazione sulla riga di comando: le Software Collection non sono automaticamente disponibili con il comando php. A seconda della configurazione, cronjob e script le richiamano con un comando proprio o con un percorso completo. Verifichi quindi anche crontab e script di deployment, se vuole sapere quale collection sia in uso per cosa.
Verificare il repository PHP Remi dopo PHP2Shell
I comandi seguenti sono di sola lettura e mostrano quali pacchetti Remi sono installati e in quale stato.
# Fonti di pacchetti attive: remi-modular o remi-safe è collegato?
dnf repolist
# Module stream attivo per PHP
dnf module list --enabled php
# Pacchetti di base e Software Collection installate in parallelo
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Versione di ogni collection installata
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Con i rami supportati la situazione è chiara: se compare 8.5.12, 8.4.27, 8.3.36 o 8.2.35 o più recente, la correzione è contenuta. Con Remi il numero di versione corrisponde di norma alla versione upstream, diversamente dai pacchetti delle distribuzioni, che spesso mantengono il vecchio numero.
Per le collection più vecchie come php81, php80 o php74 non esiste una versione di destinazione ufficiale. Remi indica PHP 8.1 come End-of-Life. Se un pacchetto installato contenga una correzione contro PHP2Shell lo chiarisce nel changelog, ad esempio con rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Senza riscontri tratti il pacchetto come non chiarito. Come documentare bene tali riscontri lo descrive l'articolo Documentare i numeri CVE nel changelog del pacchetto.
Non attivi in modo permanente su server di produzione repository di test come remi-test o remi-modular-test. Forniscono release candidate, pensate per i test.
Aggiornamento e riavvio di ogni versione
L'aggiornamento stesso con Remi è di solito privo di sorprese: dnf upgrade recupera i nuovi pacchetti per stream e collection. La parte critica segue dopo. Ogni collection ha un proprio servizio FPM, e ciascuno deve essere riavviato.
# Elencare tutti i servizi PHP-FPM, anche quelli delle collection
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Verificare gli orari di avvio di tutti i processi PHP
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Orari di avvio precedenti all'aggiornamento significano: questo servizio lavora ancora con il vecchio codice. Perché un ricaricamento non basti lo spiega la pagina Riavviare PHP-FPM e tutti i worker.
Remi e distribuzione: chi è responsabile?
Chi passa con un module stream a Remi cambia fornitore per PHP. Le segnalazioni di sicurezza di Red Hat, AlmaLinux o Rocky Linux non si riferiscono allora più ai pacchetti PHP installati. Viceversa Remi non segnala problemi in altri pacchetti del sistema. Entrambe le fonti vanno quindi tenute d'occhio.
Da dove provenga un pacchetto installato lo mostra il database dei pacchetti, ad esempio con rpm -qi php-fpm nei campi per produttore e pacchettizzatore. Poiché per i pacchetti Remi non esistono errata nel senso di Red Hat, il blog del repository si presta come canale di notifica; si può seguire tramite feed RSS. Con PHP2Shell la segnalazione è comparsa lì un giorno dopo i rilasci ufficiali.
Per le aziende questa ripartizione non è un ostacolo, ma deve essere documentata. Annoti quali server ottengono PHP da Remi, chi legge le segnalazioni e chi riavvia i servizi dopo un aggiornamento. Altrimenti ognuno si affida all'altro.
Mantenere l'ordine: meno versioni, meno rischio
Le Software Collection invitano a lasciare semplicemente lì le versioni vecchie. Dopo PHP2Shell è un buon momento per riordinare:
- Per ogni collection chiarire quale sito o cronjob la usa.
- Disattivare le collection non usate e rimuoverle dopo un periodo di osservazione.
- Portare le applicazioni su collection vecchie a un ramo supportato.
- Documentare le versioni rimanenti con scopo e responsabile.
Come mantenere la visione d'insieme su molte versioni parallele lo descrive l'articolo Più versioni di PHP su un server.
Come aiuta concretamente PHP SOS?
- Rileviamo tutti gli stream e le collection Remi sui Suoi server e li associamo a siti e cronjob.
- Verifichiamo lo stato di PHP2Shell per ogni versione tramite versione del pacchetto e changelog.
- Installiamo gli aggiornamenti, riavviamo ogni servizio e lo documentiamo con gli orari di avvio dei processi nell'ambito del servizio patch PHP.
- Le collection non più necessarie le rimuoviamo in modo controllato previo accordo.
Domande frequenti
Remi ha messo a disposizione le versioni per PHP2Shell?
Sì. Nel blog del repository sono state annunciate il 22 ottobre 2026 le versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12, con il riferimento a due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, e la raccomandazione urgente di aggiornare.
Qual è la differenza tra module stream e SCL in Remi?
Con un module stream sostituisce il PHP di sistema con una versione Remi, e c'è allora una versione PHP come predefinita. Le Software Collection installano altre versioni in parallelo in percorsi propri, ciascuna con un proprio servizio.
PHP 8.1 da Remi riceve ancora aggiornamenti?
Remi indica PHP 8.1 come End-of-Life, il progetto PHP non cura più il ramo. Se un determinato pacchetto 8.1 contenga una correzione contro PHP2Shell lo verifichi nel changelog del pacchetto installato. Senza voce, lo stato va considerato non chiarito.
Dopo un aggiornamento Remi devo riavviare ogni versione di PHP?
Sì. Ogni versione installata in parallelo ha un proprio servizio FPM. Se si riavvia solo il servizio della versione principale, le altre continuano a girare con il vecchio codice.