In breve: con Apache e mod_php, PHP gira direttamente nel web server. Il team PHP classifica il rischio di PHP2Shell più alto proprio in questa modalità, perché è stato mostrato un exploit prima ancora che giri il codice dell'applicazione. Aggiorni subito, riavvii Apache per intero e pianifichi poi il passaggio a PHP-FPM.
Che cos'è mod_php e perché conta adesso
Con mod_php, Apache carica PHP come modulo in ogni proprio processo di lavoro. Ogni richiesta a un file PHP viene eseguita direttamente in quel processo. Per molto tempo è stato lo standard ed è semplice da configurare. Significa però anche: tutti i siti sul server girano con lo stesso utente e PHP condivide il processo con il web server.
PHP2Shell comprende le vulnerabilità CVE-2026-109618 e CVE-2026-109619, entrambe con CVSS v4.0 9.2. Nella seconda, lo stato interno di una richiesta può persistere dopo il rilascio della memoria ed essere usato da una richiesta successiva nello stesso processo. Per mod_php il team PHP ha accertato il rischio più alto. Contesto e inquadramento si trovano alla pagina Perché mod_php comporta il rischio più alto.
Riconoscere Apache mod_php e verificare la versione
Verifichi per prima cosa se il Suo Apache usa davvero mod_php. I comandi seguenti leggono soltanto. I nomi dei comandi e dei pacchetti variano a seconda della distribuzione e sono esempi.
# Debian/Ubuntu: moduli caricati
apache2ctl -M 2>/dev/null | grep -i php
# Famiglia RHEL
httpd -M 2>/dev/null | grep -i php
# Quale MPM è attivo? mod_php richiede prefork
apache2ctl -V 2>/dev/null | grep -i mpm
# Stato dei pacchetti del modulo (esempi)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
Se compare un modulo come php_module, gira mod_php. La sola versione di PHP mostrata non è una prova della patch, perché le distribuzioni spesso installano le correzioni come backport. Le versioni corrette del progetto PHP sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i pacchetti delle distribuzioni conta il changelog con i numeri CVE.
Aggiornare e riavviare Apache per intero
Installi l'aggiornamento tramite la gestione dei pacchetti. Poiché PHP è integrato nel processo Apache, dopo deve riavviarsi l'intero servizio. Ricaricare la configurazione qui non è la via sicura.
# Debian/Ubuntu
systemctl restart apache2
# Famiglia RHEL
systemctl restart httpd
# Controllo: orario di avvio di tutti i processi Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
Tutti i processi Apache devono mostrare un orario di avvio successivo all'aggiornamento. Se sullo stesso server gira anche PHP-FPM o php-cgi, riavvii anche questi servizi.
Se per la Sua versione di PHP non è ancora disponibile una patch, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete il web server. Con mod_php ciò pesa in modo particolare, perché l'attacco può agire prima del codice dell'applicazione.
Misure transitorie nella configurazione di Apache
php.net indica misure transitorie che riducono il rischio ma non offrono una protezione completa. Con mod_php imposti i valori con php_admin_value o php_admin_flag nella configurazione di Apache, in modo che .htaccess e le applicazioni non possano sovrascriverli.
# Esempio: nella configurazione del VirtualHost o a livello di server
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M
php_admin_value upload_max_filesize 6M
</IfModule>
Con la funzione di upload, php.net indica post_max_size = 32M, con upload_max_filesize inferiore. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. L'indicazione su memory_limit=-1 la applichi solo insieme a un limite di memoria per il servizio tramite cgroup, ad esempio con MemoryMax in un'integrazione systemd, non tramite RLIMIT_AS o RLIMIT_DATA. Poi riavvii Apache per intero. Tutte le misure in sintesi: Misure immediate senza patch.
La strada per lasciare mod_php
Dopo la patch d'emergenza vale la pena passare a PHP-FPM. In questo caso PHP gira in processi propri, separati dal web server. Ogni sito può avere un pool proprio con un utente proprio, si possono impostare limiti per ogni pool e i riavvii riguardano solo PHP. Apache collega PHP-FPM tramite mod_proxy_fcgi e può usare allora, al posto di prefork, un MPM più moderno come event.
Pianifichi il passaggio in un ambiente di test: creare i pool per ogni sito, adeguare i permessi dei file ai nuovi utenti, trasferire nelle impostazioni dei pool le voci php_value presenti in .htaccess, eseguire test di carico. Com'è fatta una configurazione pulita lo mostra Mettere in sicurezza Nginx con PHP-FPM; i principi valgono ugualmente per Apache con PHP-FPM.
Indipendentemente dalla modalità di esecuzione vale: una patch non rimuove il malware già introdotto. Conservi i log a partire dal 20/10/2026 e verifichi la presenza di tracce sul server.
Nella ricerca di tracce sui server con mod_php vale la pena guardare all'utente condiviso. Poiché tutti i siti girano con l'utente di Apache, ad esempio www-data o apache, un aggressore che ha preso il controllo di un sito può di norma leggere e modificare anche i file degli altri. Verifichi quindi non solo il sito che Le sembra anomalo, ma tutte le document root sul server. Faccia particolare attenzione a file PHP con data di modifica recente nelle directory di upload e di cache, a codice di programma che appartiene all'utente di Apache e a voci sconosciute nel crontab di questo utente. Se trova qualcosa, salvi prima lo stato e non cancelli in fretta, in modo che la causa resti ricostruibile in seguito.
Come aiuta concretamente PHP SOS?
- Verifichiamo modalità di esecuzione, MPM e stato dei pacchetti e valutiamo se il Suo server è effettivamente aggiornato.
- Tramite il servizio di patch PHP installiamo l'aggiornamento, riavviamo Apache per intero e documentiamo la prova.
- Fino alla patch applichiamo le misure transitorie in modo non sovrascrivibile e limitiamo la memoria a livello di servizio.
- Nell'ambito dell'hardening dei server pianifichiamo e testiamo il passaggio a PHP-FPM con pool separati.
Domande frequenti
Come riconosco se il mio server usa mod_php?
Se Apache ha caricato un modulo PHP, compare nell'elenco dei moduli come php_module o con il numero di versione nel nome. Inoltre un output di phpinfo mostra alla voce Server API il valore Apache 2.0 Handler. Cancelli subito un simile file di prova.
Perché mod_php è particolarmente critico con PHP2Shell?
Secondo il team PHP il rischio lì è il più alto; è stato mostrato un exploit prima ancora che giri il codice dell'applicazione. Perciò non protegge nemmeno un'applicazione ben curata. Un aggiornamento rapido ha quindi la massima priorità.
Dopo l'aggiornamento basta un reload di Apache?
La via sicura è un riavvio completo del servizio, perché PHP è integrato come modulo nei processi Apache. Poi verifichi l'orario di avvio di tutti i processi Apache. Non devono restare processi più vecchi dell'aggiornamento.
Il passaggio a PHP-FPM è complesso?
Di solito è ben pianificabile: installare PHP-FPM, creare i pool, portare Apache su proxy_fcgi e passare da prefork a un altro MPM. Lo provi prima in una copia dell'ambiente.