# RHEL, AlmaLinux e Rocky Linux: verificare la patch PHP > Verificare la patch PHP su RHEL, AlmaLinux e Rocky: cosa segnala Red Hat su PHP2Shell, come interrogare errata e changelog e riavviare correttamente. Fonte: https://phpsos.de/it/blog/rhel-almalinux-rocky-php/ Stato: 25/10/2026 Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6 **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. ```bash # 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](https://phpsos.de/it/blog/cve-im-changelog-nachweisen/). 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](https://phpsos.de/it/php2shell/php-version-pruefen/). ## 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: ```bash # 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](https://phpsos.de/it/php2shell/php-fpm-neustart/). ## 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.enabled` nella configurazione fornita è commentata, quindi la funzione è attiva per impostazione predefinita. Il valore `0` deve essere impostato espressamente. - **Impostare in modo non sovrascrivibile:** tramite `php_admin_value` nel pool PHP-FPM, con mod_php nella configurazione di Apache. Non tramite `ini_set()` o `.user.ini`. - **Cercare gli antagonisti:** Red Hat raccomanda di verificare se file `.htaccess`, VirtualHost e file `.user.ini` riattivino le impostazioni interessate. - **Porre limiti anche a monte:** oltre a `post_max_size` in 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. > **Consiglio:** > 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](https://phpsos.de/it/blog/remi-repository-php/). ## 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](https://phpsos.de/it/leistungen/php-patch-service/). ## 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. ## Fonti - [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013) - [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618) - [php.net: segnalazioni di sicurezza](https://www.php.net/)