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.
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.
Che cosa dovrebbero fare ora i gestori di mod_php
- 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.
- Riavviare Apache completamente, non solo ricaricarlo. Con mod_php il vecchio codice PHP è presente in ogni processo Apache.
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
- Impostare le misure provvisorie, se l'aggiornamento non è ancora possibile. php.net indica tra l'altro limiti fissi che le applicazioni non possono sovrascrivere:
# 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. 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.
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.
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 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 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.