In breve: PHP-FPM (FastCGI Process Manager) esegue PHP come servizio a sé accanto al server web. Un processo master gestisce i pool e ogni pool avvia worker che elaborano le richieste tramite FastCGI. I pool si possono gestire per ogni sito con utente proprio, limiti propri e impostazioni PHP bloccate. Poiché i worker elaborano molte richieste una dopo l'altra, dopo un aggiornamento di PHP vanno tutti riavviati.
Che cos'è PHP-FPM?
Il manuale PHP descrive FPM come implementazione FastCGI primaria di PHP, con funzioni utili soprattutto per i siti web molto carichi. FPM è stato inserito con PHP 5.3.3 come SAPI a sé, cioè come modalità di esecuzione propria. Il suo nome SAPI è fpm-fcgi.
La differenza rispetto a mod_php: PHP non gira nel server web, ma come servizio a sé. Nginx, Apache o un altro server web inoltra le richieste PHP tramite il protocollo FastCGI e riceve in cambio la risposta già pronta. Server web e PHP si possono così riavviare, configurare e proteggere in modo indipendente. Come funziona FastCGI in linea di principio è spiegato in CGI e FastCGI.
Master, pool e worker: il modello di processo
PHP-FPM si compone di tre livelli:
- Processo master: legge la configurazione, apre i socket e avvia o termina i worker. Non esegue codice applicativo.
- Pool: ogni pool ha un nome, un socket o una porta propri, un utente Unix proprio e impostazioni PHP proprie. Il manuale cita espressamente uid, gid, chroot, ambiente e php.ini diversi per ogni pool.
- Worker: processi di un pool che accettano ed eseguono le richieste. Un worker elabora molte richieste una dopo l'altra prima di essere sostituito.
Quanti worker girano lo determina il gestore di processi con la direttiva pm:
| Modalità | Comportamento | Direttive importanti |
|---|---|---|
static |
numero fisso di worker | pm.max_children |
dynamic |
worker tra un limite inferiore e uno superiore | pm.start_servers, pm.min_spare_servers, pm.max_spare_servers |
ondemand |
worker solo su richiesta, rimossi dopo l'inattività | pm.process_idle_timeout (predefinito 10s) |
pm.max_children limita in tutte le modalità il numero di richieste simultanee. pm.max_requests sostituisce un worker dopo un numero fisso di richieste; il valore predefinito 0 significa illimitato.
Quale modalità sia adatta dipende dal carico. static tiene sempre pronto lo stesso numero di worker ed è indicata per applicazioni usate in modo uniforme e intenso, con memoria sufficiente. dynamic è un compromesso per la maggior parte dei siti web. ondemand risparmia memoria sui server con molti piccoli siti web, perché i pool senza visitatori non occupano worker; in compenso la prima richiesta dopo una pausa richiede un po' più di tempo. Un pm.max_children impostato troppo alto può portare il server a esaurire la memoria nei picchi di carico, uno troppo basso causa tempi di attesa e messaggi di errore del server web.
Un pool con impostazioni di base sicure
Un esempio di pool proprio per ogni sito web, con direttive del manuale PHP. Percorsi e valori sono esempi:
; /etc/php/8.3/fpm/pool.d/kunde-a.conf
[kunde-a]
user = kunde-a
group = kunde-a
listen = /run/php/kunde-a.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
security.limit_extensions = .php
clear_env = yes
php_admin_value[open_basedir] = /var/www/kunde-a:/tmp
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[error_log] = /var/log/php/kunde-a.error.log
Secondo il manuale i valori impostati con php_value e php_flag possono essere modificati a runtime con ini_set(), quelli impostati con php_admin_value e php_admin_flag invece no. security.limit_extensions è per impostazione predefinita .php .phar e stabilisce quali estensioni di file FPM esegue come script principale. clear_env = yes è il valore predefinito e svuota l'ambiente dei worker.
Per il monitoraggio esistono una pagina di stato tramite pm.status_path e una pagina di ping tramite ping.path. Entrambe dovrebbero essere raggiungibili solo dall'interno. Le richieste lente FPM le registra con backtrace se sono impostati request_slowlog_timeout e slowlog.
Il manuale PHP avverte: chi può aprire una connessione FastCGI verso PHP-FPM controlla la configurazione della richiesta e può quindi eseguire codice arbitrario. PHP-FPM non deve mai essere raggiungibile da una rete non attendibile. Usi un socket Unix oppure listen.allowed_clients.
Che ruolo ha PHP-FPM in PHP2Shell?
PHP-FPM rientra tra le modalità di esecuzione interessate. Il modello di processo emerge in modo particolarmente chiaro con CVE-2026-109619: lo stato interno appartenente alla richiesta può rimanere dopo la liberazione della memoria e una richiesta successiva nello stesso worker può usarlo prima che venga ripristinato. Ciò è possibile solo perché i worker elaborano molte richieste una dopo l'altra.
Ne derivano tre obblighi:
- Installare l'aggiornamento: PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure un backport confermato della distribuzione.
- Riavviare tutti i worker: i nuovi file sul disco non cambiano nulla finché girano i vecchi worker. Vale per ogni versione di FPM installata e per ogni pool. I comandi sono in Riavviare PHP-FPM e tutti i worker.
- Impostare i valori transitori in modo bloccato: le misure di php.net, ad esempio
session.upload_progress.enabled=0, vanno nel pool tramitephp_admin_valueophp_admin_flag, non in.user.ini.
La separazione in pool non sostituisce un aggiornamento, ma limita il danno: se ogni sito web gira con un proprio utente, dopo un'intrusione l'aggressore non raggiunge automaticamente i file degli altri. Come si presenta in concreto lo descrive Isolare i pool PHP-FPM per ogni sito web; l'integrazione in Nginx è in Mettere in sicurezza Nginx con PHP-FPM.
Come aiuta concretamente PHP SOS?
- Rilevare i pool: elenchiamo tutte le versioni di FPM, i pool, gli utenti e i socket del Suo server.
- Aggiornare e riavviare: aggiorniamo PHP e documentiamo dagli orari di avvio che non gira più alcun vecchio worker.
- Separare i pool: nell'ambito dell'hardening del server impostiamo per ogni sito web un pool con utente proprio e impostazioni bloccate.
- Verificare la raggiungibilità: controlliamo che i socket FastCGI e le pagine di stato non siano raggiungibili dall'esterno.
Domande frequenti
Che cosa significa FPM?
FPM sta per FastCGI Process Manager. Il manuale PHP lo descrive come implementazione FastCGI primaria di PHP, con funzioni utili soprattutto per i siti web molto carichi. È stato inserito con PHP 5.3.3.
Qual è la differenza tra pool e worker?
Un pool è un gruppo di processi worker con configurazione comune: utente, socket, limiti e impostazioni PHP. Un worker è un singolo processo che gestisce le richieste una dopo l'altra. Un server può avere molti pool, ad esempio uno per sito web.
PHP-FPM dovrebbe essere raggiungibile via TCP o tramite socket Unix?
Se il server web gira sullo stesso host, il manuale PHP raccomanda un socket Unix. Con TCP va impostato listen.allowed_clients, perché altrimenti qualsiasi indirizzo può collegarsi. Secondo il manuale una porta FastCGI raggiungibile liberamente consente l'esecuzione di codice arbitrario.
pm.max_requests protegge da vulnerabilità come PHP2Shell?
No. pm.max_requests sostituisce un worker dopo un numero fisso di richieste e aiuta soprattutto contro i memory leak nelle estensioni. Contro una vulnerabilità nell'interprete aiuta solo l'aggiornamento con successivo riavvio di tutti i worker.