# php-cgi: un'eredità del passato a rischio

> Vulnerabilità php-cgi con PHP2Shell: trovare le configurazioni CGI e FastCGI, aggiornare, terminare i vecchi processi e pianificare il passaggio a PHP-FPM.

Fonte: https://phpsos.de/it/server/php-cgi/  
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:** 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.

```bash
# 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.

```bash
# 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](https://phpsos.de/it/server/windows-iis-php/).

> **Agire subito:**
> 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.

```ini
; 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](https://phpsos.de/it/server/nginx-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](https://phpsos.de/it/leistungen/php-migration-legacy/).
- Nell'ambito dell'[hardening dei server](https://phpsos.de/it/leistungen/server-haertung/) 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.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versioni supportate](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)