In breve: l'handler PHP di Plesk stabilisce come PHP gira per un sito: come applicazione FPM con pool condiviso, come Dedicated FPM con pool proprio per ogni sito, come applicazione FastCGI o come modulo Apache (mod_php). Dal punto di vista della sicurezza Dedicated FPM su Linux è di solito la scelta migliore, il modulo Apache la peggiore. Plesk stesso lo definisce obsoleto o insicuro e, con PHP2Shell, il team PHP vede il rischio più alto proprio in mod_php.
Perché l'handler è più di una questione di prestazioni
In Plesk per ogni sito sceglie una versione di PHP e un handler. Molti trattano l'handler come un dettaglio di prestazioni e memoria. Ma decide anche quanto i siti siano separati l'uno dall'altro, dove abbiano effetto le impostazioni di sicurezza e quali processi vadano riavviati dopo un aggiornamento.
Dopo PHP2Shell questa scelta diventa concreta. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 riguardano tutte le modalità di esecuzione comuni, ma il team PHP classifica il rischio più alto per mod_php. Chi sul proprio server Plesk gestisce ancora domini con il modulo Apache dovrebbe cambiarlo ora. Come verificare e aggiornare le versioni lo descrive la pagina Server Plesk: verificare e aggiornare le versioni di PHP; qui si tratta della scelta della modalità di esecuzione.
Gli handler PHP di Plesk in sintesi
La panoramica seguente si basa sulla documentazione di Plesk per Plesk Obsidian, integrata dal punto di vista della sicurezza. Su Linux gli handler FPM possono, secondo Plesk, essere serviti a scelta tramite Apache o nginx, FastCGI sempre tramite Apache.
| Handler | Servito tramite | Isolamento | Raccomandazione secondo Plesk | Punto di vista della sicurezza |
|---|---|---|---|---|
| Dedicated FPM application | Apache o nginx | pool proprio per ogni sito | Linux con hosting condiviso | separazione migliore, valori propri per ogni pool |
| FPM application | Apache o nginx | pool condiviso per ogni versione di PHP | server Linux dedicati | un sito difettoso può disturbare altri con la stessa versione |
| FastCGI application | Apache (Linux) | processi persistenti, buona separazione | server Windows | solido, su Linux di solito sostituito da FPM |
| Apache module (mod_php) | Apache | PHP nel processo del server web | non raccomandato | rischio PHP2Shell più alto secondo il team PHP |
| CGI application | Apache | nuovo processo per ogni richiesta | non raccomandato | obsoleto |
Il contesto sulle modalità di esecuzione stesse lo spiegano le pagine PHP-FPM spiegato e Perché mod_php comporta il rischio più alto.
Pool condiviso o proprio?
La differenza tra FPM e Dedicated FPM viene spesso sottovalutata. Con il normale handler FPM, secondo Plesk, tutti i siti con la stessa versione di PHP condividono un pool di processi. Ciò fa risparmiare memoria, ma significa anche: un sito che dà problemi può trascinare con sé tutti gli altri con la stessa versione, e la cache comune è condivisa.
Dedicated FPM dà a ogni sito un pool proprio. Secondo Plesk questo migliora isolamento e prestazioni, ma costa più memoria. Dal punto di vista della sicurezza il pool proprio è la base per impostare separatamente per ogni sito valori come open_basedir, limiti di memoria o limiti di upload. Come separare i pool in modo coerente lo descrive l'articolo Isolare i pool PHP-FPM per ogni sito.
nginx o Apache: la trappola di .htaccess
Se sceglie un handler servito tramite nginx, cambia qualcosa di fondamentale: secondo Plesk questi handler ignorano il file .htaccess. Ciò che vi è scritto non ha più effetto.
È un tema di sicurezza. Molte applicazioni e molti amministratori mettono regole di protezione in .htaccess, ad esempio il divieto di eseguire file PHP nelle cartelle di upload o blocchi per file di configurazione. Dopo un passaggio a nginx queste regole sono silenziosamente fuori uso. Prima del cambio verifichi quindi quali regole di protezione siano in .htaccess e le riporti nella configurazione nginx del dominio.
Un cambio di handler è una modifica alla configurazione di sicurezza. Dopo, verifichi in modo mirato se i percorsi bloccati restano bloccati, e non solo se la home page si carica.
Verificare e cambiare l'handler
Per prima cosa si faccia un quadro di quali domini usino quale handler. I comandi sono di sola lettura.
# Tutti gli handler registrati con ID, versione e tipo
plesk bin php_handler --list
# Domini che usano un determinato handler (ID dall'elenco)
plesk bin php_handler --get-usage -id <handler-id>
# PHP gira nel processo di Apache? (Debian/Ubuntu: apache2ctl, famiglia RHEL: httpd)
apache2ctl -M 2>/dev/null | grep -i php
Per il cambio proceda dominio per dominio:
- Rilevare le regole di protezione di
.htaccess, se il nuovo handler è servito tramite nginx. - Impostare per il nuovo handler i valori transitori contro PHP2Shell, ad esempio
session.upload_progress.enabled=0. Con FPM vanno comephp_admin_valuenelle direttive aggiuntive del pool, con FastCGI valgono altre vie. - Cambiare l'handler nelle impostazioni PHP del dominio, possibilmente prima su una copia.
- Testare le funzioni e verificare se il dominio sia servito da processi con codice aggiornato.
- Se il modulo Apache non è più usato da nessun dominio, disattivare l'handler.
In quale ordine effettuare il passaggio?
Su un server Plesk cresciuto negli anni raramente si può cambiare tutto in un giorno. Un ordine per rischio aiuta a usare bene il poco tempo disponibile:
- Prima i domini con il modulo Apache, perché lì il rischio da PHP2Shell è il più alto secondo il team PHP e Plesk sconsiglia comunque.
- Poi i domini con dati sensibili, ad esempio shop, portali clienti o moduli con dati sanitari o contrattuali. Qui il pool proprio vale particolarmente la pena.
- Quindi i domini su vecchie versioni di PHP, che comunque devono essere cambiate. Handler e versione si possono cambiare insieme in una finestra di manutenzione.
- Per ultimo il passaggio dal pool condiviso a quello proprio per i domini restanti, se la memoria del server lo consente.
Prima dell'ultimo livello verifichi l'utilizzo della memoria. Plesk avverte che Dedicated FPM richiede più memoria e con molti siti consiglia il monitoraggio. Un server che dopo il passaggio va in swap diventa lento, e una memoria scarsa non è una buona condizione proprio con PHP2Shell.
Come aiuta concretamente PHP SOS?
- Rileviamo quali domini sul Suo server Plesk usano quale handler e contrassegniamo i domini con il modulo Apache.
- Passiamo a Dedicated FPM e, dove serve, riportiamo le regole di protezione da
.htaccessnella configurazione nginx. - Impostiamo valori transitori e limiti per ogni pool e verifichiamo che abbiano effetto nel contesto web.
- Nell'ambito dell'hardening del server disattiviamo gli handler obsoleti e documentiamo la configurazione.
Domande frequenti
Quale handler PHP raccomanda Plesk?
Secondo la documentazione di Plesk, FPM è l'handler raccomandato sui server Linux dedicati, Dedicated FPM sui server Linux per l'hosting condiviso e FastCGI sui server Windows. Il modulo Apache, CGI e ISAPI sono definiti da Plesk fortemente obsoleti o insicuri.
Perché dopo PHP2Shell l'handler modulo Apache è particolarmente critico?
L'handler corrisponde a mod_php. Il team PHP classifica il rischio di PHP2Shell come più alto proprio per mod_php, perché lì è stato dimostrato un exploit prima che venga eseguito il codice dell'applicazione. Inoltre lo stesso Plesk sconsiglia questo handler.
Cosa cambia se PHP viene servito tramite nginx invece che Apache?
Secondo Plesk, gli handler serviti tramite nginx ignorano il file .htaccess. Le regole di sicurezza che vi sono contenute, ad esempio i blocchi di PHP nelle cartelle di upload, non sono più efficaci e vanno riportate in regole nginx.
Dopo un cambio di handler devo riavviare PHP?
Dopo il cambio verifichi quali processi PHP girano per il dominio e da quando. Con Dedicated FPM il dominio riceve un pool proprio. Un vecchio processo con codice obsoleto non dovrebbe più lavorare per il dominio.
Dedicated FPM è sempre la scelta migliore?
Per l'isolamento sì, perché ogni sito riceve un pool proprio. Il prezzo è un fabbisogno di memoria maggiore. Plesk consiglia di monitorare i server con molti siti.