In breve: su RHEL, AlmaLinux e Rocky Linux verifica la patch PHP contro PHP2Shell per tre vie: le segnalazioni di sicurezza della distribuzione (dnf updateinfo), il changelog del pacchetto (rpm -q --changelog) e l'orario di avvio dei processi PHP. Red Hat indica RHEL da 7 a 10 come interessati e, alla consultazione, ha segnalato che alcuni aggiornamenti sono disponibili e altri in lavorazione. Dopo l'aggiornamento vale: riavviare completamente, non solo ricaricare.
Cosa ha pubblicato Red Hat su PHP2Shell
Red Hat ha emesso su PHP2Shell il bollettino di sicurezza RHSB-2026-013. Lo abbiamo consultato il 25 ottobre 2026. I punti più importanti per gli admin:
- Interessati sono RHEL 10, 9, 8 e 7 nonché i prodotti basati su di essi e i container su immagini RHEL o UBI.
- RHEL 7 è interessato, secondo Red Hat, solo da CVE-2026-109619; il codice per CVE-2026-109618 non vi sarebbe contenuto.
- Non interessati sono i sistemi senza PHP o con PHP che non elabora richieste HTTP non attendibili.
- Aggiornamenti: alla consultazione alcuni erano disponibili, altri in lavorazione. Il bollettino non indicava numeri di errata concreti, ma rimandava alle pagine delle errata.
Red Hat valuta CVE-2026-109618 con un metodo proprio come «Important» e fa notare che le installazioni standard da RHEL 8 in poi usano PHP-FPM anziché mod_php. È un inquadramento, non un cessato allarme. Il progetto PHP valuta entrambe le vulnerabilità con CVSS v4.0 9,2, e il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda l'aggiornamento immediato.
AlmaLinux e Rocky Linux: stessa fonte, ritmo proprio
AlmaLinux e Rocky Linux ricompilano i propri pacchetti dai sorgenti di Red Hat. Le correzioni arrivano perciò di norma identiche nei contenuti, ma in un momento proprio e con segnalazioni di sicurezza proprie. Il riferimento a un'errata di Red Hat non significa che il pacchetto sia disponibile lo stesso giorno presso il Suo clone.
Decisivo è quindi lo stato sul Suo sistema. Lo verifichi con gli strumenti della gestione dei pacchetti e non in base a notizie o forum.
Faccia attenzione anche al fatto che sul server vengano usati mirror o fonti di pacchetti interne. In molte aziende i server non ottengono gli aggiornamenti direttamente dal produttore, ma tramite un mirror interno o uno strumento di gestione. Se questo mirror non è aggiornato, dnf non trova nuovi pacchetti, benché siano stati pubblicati da tempo.
Verificare la patch PHP su RHEL e cloni
I comandi seguenti sono di sola lettura. I nomi dei pacchetti valgono per i pacchetti PHP della distribuzione; i pacchetti da fonti di terze parti come Remi si chiamano in parte diversamente.
# Quali stream PHP conosce il sistema, quale è attivo? (RHEL 8 e 9)
dnf module list php
# Pacchetti PHP installati con versione e origine
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Esistono segnalazioni di sicurezza sui CVE per questo sistema?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# La correzione è nel changelog del pacchetto installato?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo mostra solo segnalazioni per aggiornamenti non ancora installati; con --installed vede anche quelli già installati. Un risultato vuoto può quindi significare due cose: l'aggiornamento è già dentro o non è ancora pubblicato. Il confronto con il changelog chiarisce la questione. Come conservare il risultato come prova lo descrive l'articolo Documentare i numeri CVE nel changelog del pacchetto.
Come con altre distribuzioni aziendali, il pacchetto mantiene di solito la propria versione PHP originale; cambia solo l'indicazione di release. Un numero più vecchio con php -v non è quindi un indizio di una correzione mancante. Indicazioni generali sulla verifica delle versioni si trovano in Verificare correttamente versione e stato della patch di PHP.
Riconoscere la modalità di esecuzione giusta
Red Hat indica le modalità di esecuzione predefinite: da RHEL 8 PHP gira tramite PHP-FPM, su RHEL 7 come mod_php nel servizio Apache httpd. Molti server si discostano da ciò, ad esempio per pannelli, fonti esterne o vecchie configurazioni.
| Sistema | Predefinito secondo Red Hat | Riavvio dopo l'aggiornamento |
|---|---|---|
| RHEL 8, 9, 10 e cloni | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php in httpd | systemctl restart httpd |
| Container su base RHEL o UBI | a seconda dell'immagine | ricostruire l'immagine, sostituire il container |
Per i container Red Hat raccomanda, dopo l'aggiornamento delle immagini di base, di ricostruire le proprie immagini e di sostituire i container o i pod in esecuzione. Un aggiornamento nel container in esecuzione non è una via affidabile.
Dopo l'aggiornamento: riavvio e controllo
Red Hat sottolinea che un reload non basta. I worker esistenti possono mantenere lo stato interessato. Riavvii quindi ogni servizio che carica PHP e controlli il risultato:
# Mostrare i servizi con librerie obsolete (dnf-utils o dnf-plugins-core)
needs-restarting -s
# Confrontare l'orario di avvio dei processi PHP con il momento dell'aggiornamento
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Per la configurazione Red Hat dà un'indicazione pratica: php -i mostra le impostazioni della riga di comando, non quelle del server web. Chi vuole verificare se valori transitori come session.upload_progress.enabled=0 agiscano nel contesto web usa per breve tempo una pagina phpinfo protetta e la cancella poi. Cos'altro considerare nel riavvio è in Riavviare PHP-FPM e tutti i worker.
Misure transitorie: le indicazioni di Red Hat
Dove manca ancora un aggiornamento, Red Hat rimanda alle stesse misure transitorie di php.net e aggiunge alcune indicazioni pratiche per i sistemi RHEL. Non sostituiscono l'aggiornamento.
- Integrare davvero la riga: secondo Red Hat la riga per
session.upload_progress.enablednella configurazione fornita è commentata, quindi la funzione è attiva per impostazione predefinita. Il valore0deve essere impostato espressamente. - Impostare in modo non sovrascrivibile: tramite
php_admin_valuenel pool PHP-FPM, con mod_php nella configurazione di Apache. Non tramiteini_set()o.user.ini. - Cercare gli antagonisti: Red Hat raccomanda di verificare se file
.htaccess, VirtualHost e file.user.iniriattivino le impostazioni interessate. - Porre limiti anche a monte: oltre a
post_max_sizein PHP, Red Hat consiglia di valutare limiti alla dimensione delle richieste anche nel server web o nel proxy.
Sui sistemi PHP-FPM i pool si trovano di norma in /etc/php-fpm.d/. Dopo ogni modifica vale lo stesso che dopo l'aggiornamento: riavviare completamente tutti i worker.
Se sullo stesso server gira in aggiunta PHP dal repository Remi, per esso valgono pacchetti e servizi propri. Legga in proposito l'articolo Il repository Remi.
Come aiuta concretamente PHP SOS?
- Su RHEL, AlmaLinux e Rocky Linux verifichiamo tutti i pacchetti PHP, gli stream e le fonti esterne e li confrontiamo con le segnalazioni di sicurezza.
- Installiamo gli aggiornamenti, riavviamo completamente tutti i worker e controlliamo gli orari di avvio dei processi.
- Per gli ambienti container ricostruiamo le immagini e sostituiamo le istanze in esecuzione in modo controllato.
- Lo stato di ogni server lo riportiamo nella prova del servizio patch PHP.
Domande frequenti
RHEL 7 è interessato da PHP2Shell?
Secondo Red Hat, RHEL 7 è interessato solo da CVE-2026-109619, il codice vulnerabile per CVE-2026-109618 non vi sarebbe presente. Su RHEL 7 mod_php è la modalità di esecuzione predefinita, che il team PHP classifica come particolarmente rischiosa.
Perché Red Hat valuta la vulnerabilità meno di php.net?
Red Hat usa una valutazione propria secondo CVSS v3.1 e classifica CVE-2026-109618 come Important, perché lo sfruttamento richiederebbe un timing preciso. php.net valuta con CVSS v4.0 9,2. Entrambi ritengono possibile l'esecuzione di codice senza autenticazione, l'aggiornamento è comunque necessario.
AlmaLinux e Rocky Linux ricevono le correzioni automaticamente?
Entrambe ricompilano i propri pacchetti dai sorgenti di Red Hat e pubblicano segnalazioni di sicurezza proprie. Il momento può differire da quello di Red Hat. Verifichi quindi lo stato sul Suo sistema e nelle segnalazioni della Sua distribuzione.
Dopo l'aggiornamento basta systemctl reload php-fpm?
No. Red Hat segnala espressamente che un reload non basta, perché i worker esistenti possono mantenere lo stato interessato. Riavvii tutti i worker, con mod_php il servizio Apache httpd.