In breve: php-cgi è il modo più antico di far girare PHP dietro a un web server e gira ancora su molti server, spesso senza che se ne sappia. La vulnerabilità php-cgi di PHP2Shell riguarda espressamente questa modalità di esecuzione. Aggiorni, termini tutti i processi php-cgi in esecuzione e pianifichi il passaggio a PHP-FPM.
Che cos'è php-cgi e dove gira ancora
PHP esiste in più varianti: come programma a riga di comando, come modulo Apache, come PHP-FPM e come php-cgi. php-cgi è un programma che il web server avvia e al quale passa le richieste tramite CGI o FastCGI. Senza una gestione dei processi propria è più semplice di PHP-FPM, ma anche meno controllabile.
I luoghi tipici in cui lo si trova sono hosting panel più vecchi, Apache con mod_fcgid, script wrapper propri per più versioni di PHP e PHP su Windows con IIS tramite FastCGI. In agenzie e amministrazioni si trovano inoltre server configurati anni fa e da allora semplicemente fatti funzionare.
La vulnerabilità php-cgi con PHP2Shell
PHP2Shell comprende le vulnerabilità CVE-2026-109618 e CVE-2026-109619 in PHP stesso, entrambe con CVSS v4.0 9.2. Entrambe consentono l'esecuzione di codice dannoso senza autenticazione. Il progetto PHP cita espressamente php-cgi tra le modalità di esecuzione interessate, accanto a PHP-FPM, mod_php, FrankenPHP e LiteSpeed.
Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali, solo backport minimi del sorgente per 7.4, 8.0 e 8.1. Proprio le configurazioni php-cgi girano più spesso della media su versioni vecchie. Inoltre php-cgi non è interessato per la prima volta: già nel 2024 una vulnerabilità in php-cgi su Windows (CVE-2024-4577) fece scalpore. Le eredità di questo tipo meritano quindi particolare attenzione.
Trovare php-cgi sul server
I comandi seguenti leggono soltanto e aiutano a individuare php-cgi. Percorsi e nomi dei moduli sono esempi.
# Processi php-cgi in esecuzione con orario di avvio e utente
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep
# Programmi php-cgi installati
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null
# Apache: mod_fcgid o mod_cgi sono caricati?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null
Se trova voci FcgidWrapper o handler che puntano a un programma php-cgi, gira questa modalità. Per ogni programma trovato verifichi la versione con -v. Per i pacchetti delle distribuzioni è il changelog con i numeri CVE a provare la patch, perché i backport spesso non cambiano il numero di versione.
Aggiornare e terminare tutti i processi
Installi l'aggiornamento tramite la gestione dei pacchetti o la fonte da cui proviene php-cgi. Poi tutti i processi php-cgi in esecuzione devono scomparire. Con mod_fcgid Apache tiene i processi per un po'; un riavvio completo di Apache li termina.
# Riavviare Apache per intero (Debian/Ubuntu o famiglia RHEL)
systemctl restart apache2 # oppure: systemctl restart httpd
# Controllo: ci sono ancora processi php-cgi più vecchi dell'aggiornamento?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep
Se php-cgi gira tramite un gestore di processi proprio o un servizio del pannello, riavvii quello. Su Windows con IIS ricicli gli application pool, vedi PHP su Windows e IIS.
Se php-cgi gira con PHP 8.1 o precedente su un server raggiungibile pubblicamente, manca una patch ufficiale. Applichi subito le misure transitorie e valuti, secondo la raccomandazione del BSI (l'Ufficio federale tedesco per la sicurezza informatica), di scollegare temporaneamente il server dalla rete.
Misure transitorie con php-cgi
php.net raccomanda misure transitorie che non offrono una protezione completa. Con php-cgi i valori vanno nel php.ini che il rispettivo programma carica, oppure nella configurazione del server. I file .user.ini e ini_set() non bastano per session.upload_progress.enabled, secondo php.net.
; php.ini dell'installazione php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Con la funzione di upload, php.net indica post_max_size = 32M. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. I limiti di memoria si impostano tramite cgroup per il servizio del web server, non tramite RLIMIT_AS o RLIMIT_DATA. Poi riavvii tutti i processi.
La strada verso PHP-FPM
Nel lungo periodo php-cgi non è una buona scelta. PHP-FPM offre pool per ogni sito, utenti propri, limiti per pool, pagine di stato e riavvii controllati. Il passaggio è di solito ben pianificabile: installare PHP-FPM, creare i pool, portare il web server su FastCGI verso PHP-FPM, rimuovere gli script wrapper. Com'è fatta una configurazione pulita lo mostra Mettere in sicurezza Nginx con PHP-FPM. Se gira in aggiunta una vecchia versione di PHP, colleghi il passaggio all'upgrade.
Finché il passaggio non è avvenuto, dovrebbe esaminare con occhio critico la configurazione esistente. Il web server dovrebbe passare a php-cgi solo file con estensione .php e non percorsi che puntano a file inesistenti. Nelle directory di upload non deve essere possibile eseguire PHP. Gli script wrapper che caricano un php.ini proprio per ogni sito vanno controllati per vedere se quei file annullano di nuovo i valori transitori. Se un programma php-cgi si trova direttamente in una directory raggiungibile pubblicamente come cgi-bin, va rimosso da lì. Simili eredità del passato derivano spesso da istruzioni di installazione di anni fa e nelle ristrutturazioni successive vengono semplicemente dimenticate. Documenti ogni riscontro con percorso e scopo, in modo che la successiva ristrutturazione non trascuri nulla.
Resta importante: una patch non rimuove il malware introdotto prima. Conservi i log a partire dal 20/10/2026.
Come aiuta concretamente PHP SOS?
- Individuiamo installazioni php-cgi, wrapper e handler e li assegniamo ai siti.
- Aggiorniamo, terminiamo tutti i vecchi processi e documentiamo lo stato.
- Per PHP 8.1 e precedenti pianifichiamo con Lei la migrazione a una versione di PHP supportata.
- Nell'ambito dell'hardening dei server sostituiamo php-cgi con PHP-FPM con pool separati.
Domande frequenti
Uso php-cgi senza saperlo?
È più frequente di quanto si pensi. Pannelli più vecchi, configurazioni FastCGI con mod_fcgid e PHP su Windows con IIS avviano spesso PHP come php-cgi. Un elenco dei processi o la Server API in phpinfo lo mostrano in modo affidabile.
FastCGI è la stessa cosa di php-cgi?
Non del tutto. FastCGI è un protocollo. Sia PHP-FPM sia php-cgi possono parlare FastCGI, ma php-cgi è il programma più vecchio e semplice, senza pool né gestione dei processi. PHP2Shell riguarda espressamente php-cgi.
Che cosa significa CGI classico con PHP?
Con il CGI classico il web server avvia un nuovo processo PHP per ogni richiesta. È lento e oggi raro. Più frequente è php-cgi dietro mod_fcgid o FastCGI, dove i processi elaborano più richieste.
Dopo l'aggiornamento devo riavviare qualcosa?
Sì. Nelle configurazioni FastCGI i processi php-cgi continuano a girare per un po'. Riavvii il web server o il gestore dei processi e verifichi che nessun processo php-cgi sia più vecchio dell'aggiornamento.