# Perché mod_php comporta il rischio più alto > Perché il team PHP classifica come più alto il rischio di PHP2Shell con Apache e mod_php, come riconoscere mod_php e che cosa aggiornare e cambiare adesso. Fonte: https://phpsos.de/it/php2shell/mod-php-risiko/ 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:** da PHP2Shell sono interessate tutte le modalità di esecuzione abituali, ma con Apache e mod_php il team PHP classifica il rischio come il più alto. Lì è stato dimostrato un exploit prima ancora che giri il codice dell'applicazione. Chi gestisce mod_php dovrebbe prima aggiornare PHP e riavviare Apache completamente. ## Che cos'è mod_php? Con mod_php, PHP è un modulo all'interno del web server Apache. Ogni processo Apache contiene un interprete PHP completo ed esegue direttamente il codice PHP. Questa modalità è stata a lungo lo standard ed è ancora oggi diffusa su server più vecchi, in molti pacchetti delle distribuzioni e in alcune immagini Docker. L'alternativa è PHP-FPM: qui PHP gira come servizio a sé, con processi propri, e Apache o Nginx si limita a inoltrare le richieste. Entrambe le varianti sono interessate da PHP2Shell, così come php-cgi, FrankenPHP e LiteSpeed. Ambienti tipici con mod_php sono i vecchi root server che girano invariati da anni, le installazioni standard di Apache dai pacchetti delle distribuzioni e le immagini Docker con Apache e PHP in un unico container. Chi non sa con certezza quale modalità di esecuzione usi il proprio server dovrebbe verificarlo, anziché supporlo. ## Perché la vulnerabilità di mod_php è considerata particolarmente rischiosa? Il team PHP ha espresso su PHP2Shell una valutazione chiara: con mod_php il rischio è il più alto. Motivazione: lì è stato dimostrato un exploit che agisce prima ancora che giri il codice dell'applicazione. Per i gestori ne deriva una conseguenza scomoda. Molte misure di protezione stanno nell'applicazione: plugin di sicurezza in WordPress, moduli firewall negli shop, controlli nel codice proprio. Sono tutti codice dell'applicazione. Se lo sfruttamento avviene prima, arrivano troppo tardi. A ciò si aggiunge lo stretto intreccio: con mod_php, PHP condivide il processo con Apache. Ciò che compromette PHP gira con i privilegi del web server e nella sua memoria. Con PHP-FPM, invece, i pool possono essere separati con utenti propri per ogni sito web, il che può limitare le conseguenze di un'intrusione. Per stabilire le priorità significa: se gestisce più server, quelli con mod_php vengono per primi, e per essi è particolarmente importante una successiva verifica delle tracce. Ciò che non sappiamo: quante delle 22,6 milioni di istanze esposte e potenzialmente vulnerabili contate nel mondo usino mod_php. Dati affidabili in merito non sono stati pubblicati. ## Il mio server usa mod_php? I comandi seguenti sono di sola lettura. I nomi di servizi e comandi variano a seconda della distribuzione: Debian e Ubuntu usano `apache2`, la famiglia RHEL `httpd`. ```bash apachectl -M 2>/dev/null | grep -i php # ad es. php_module o php8_module httpd -M 2>/dev/null | grep -i php # RHEL, AlmaLinux, Rocky a2query -m | grep -i php # Debian/Ubuntu apt policy libapache2-mod-php8.3 # Debian/Ubuntu, versione del pacchetto del modulo rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # famiglia RHEL ``` Se non compare alcun modulo PHP, Apache probabilmente usa PHP-FPM tramite `proxy_fcgi`. In tal caso valgono per analogia le indicazioni alla pagina [Mettere in sicurezza Nginx con PHP-FPM](https://phpsos.de/it/server/nginx-php-fpm/). ## Che cosa dovrebbero fare ora i gestori di mod_php 1. **Aggiornare il modulo PHP** a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure a un backport confermato della Sua distribuzione. 2. **Riavviare Apache completamente,** non solo ricaricarlo. Con mod_php il vecchio codice PHP è presente in ogni processo Apache. ```bash sudo systemctl restart apache2 # Debian/Ubuntu sudo systemctl restart httpd # famiglia RHEL ps -o pid,lstart,cmd -C apache2 # verificare l'ora di avvio, su RHEL: -C httpd ``` 3. **Impostare le misure provvisorie, se l'aggiornamento non è ancora possibile.** php.net indica tra l'altro limiti fissi che le applicazioni non possono sovrascrivere: ```apache # Configurazione del server o VirtualHost, non .htaccess php_admin_value memory_limit -1 php_admin_value post_max_size 32M php_admin_value upload_max_filesize 24M php_admin_flag session.upload_progress.enabled off ``` Con `memory_limit=-1` serve anche un limite di memoria tramite cgroup, non tramite `RLIMIT_AS` o `RLIMIT_DATA`. Queste misure non sono una protezione completa; i dettagli si trovano alla pagina [Misure immediate se non può ancora applicare la patch](https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-patch/). Se nessuna delle due cose è possibile subito, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete il web server. > **Agire subito:** > Se il Suo Apache con mod_php era esposto a Internet senza protezione tra il 17 ottobre e la patch, salvi i log a partire dal 20 ottobre e faccia verificare il server alla ricerca di tracce. La sola patch non dimostra che non sia successo nulla. ## A medio termine: lasciare mod_php Dopo la patch vale la pena guardare all'architettura. Il passaggio a PHP-FPM con Apache `mpm_event` e `proxy_fcgi` oppure con Nginx separa PHP dal web server, consente pool e utenti propri per ogni sito web e semplifica riavvii e cambi di versione. Non chiude PHP2Shell, ma riduce la superficie di attacco di vulnerabilità future. Il passaggio richiede pianificazione. Le impostazioni finora definite con `php_value` in `.htaccess` con PHP-FPM non hanno più effetto e devono spostarsi nel pool. Utenti e privilegi cambiano, le directory di upload e di cache possono richiedere nuovi permessi. In un ambiente di test la cosa è ben gestibile, in esercizio sotto pressione di tempo no. Indicazioni sul passaggio si trovano alla pagina [Mettere in sicurezza Apache con mod_php](https://phpsos.de/it/server/apache-mod-php/). ## Come aiuta concretamente PHP SOS? - **Riconoscere:** verifichiamo quali server usano mod_php e da quale fonte di pacchetti proviene il modulo. - **Applicare la patch e riavviare:** con il [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) installiamo l'aggiornamento e controlliamo che non giri più alcun vecchio processo Apache. - **Mettere in sicurezza la fase transitoria:** dove l'aggiornamento è bloccato, impostiamo le misure di php.net nella configurazione del server. - **Cambiare:** nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/) pianifichiamo e testiamo il passaggio a PHP-FPM con pool separati. ## Domande frequenti **Come riconosco se il mio Apache usa mod_php?** Con apachectl -M o httpd -M vede i moduli caricati. Se compare un modulo come php_module o php8_module, PHP gira direttamente in Apache. Su Debian e Ubuntu anche a2query -m mostra se un modulo php è attivo. **Un plugin di sicurezza in WordPress mi protegge con mod_php?** Non con questa vulnerabilità. Secondo il team PHP, con mod_php è stato dimostrato un exploit prima ancora che venga eseguito il codice dell'applicazione. Un plugin è codice dell'applicazione e arriva quindi troppo tardi. La protezione è offerta solo dall'aggiornamento di PHP con riavvio di Apache. **Dovrei passare ora da mod_php a PHP-FPM?** Prima applicare la patch, poi cambiare. Il passaggio a PHP-FPM è sensato a medio termine per la maggior parte delle configurazioni, perché PHP gira allora separatamente dal web server. Non chiude però PHP2Shell, perché anche PHP-FPM è interessato. ## Fonti - [php.net: bollettini di sicurezza](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)