PHP2Shell: come aggiornare PHP e riavviare FPM

Articolo aggiornato al 23 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se il PHP Group o le distribuzioni rilasciano nuove correzioni.

Avete un sito WordPress, un gestionale web o un’applicazione interna scritta in PHP? Allora questa settimana c’è un aggiornamento da fare prima di tutto il resto. Il 21 ottobre il PHP Group ha pubblicato due advisory critici, CVE-2026-109618 e CVE-2026-109619, ribattezzati “PHP2Shell”: entrambi permettono a un attaccante non autenticato di eseguire codice sul server con l’utente del web server, ed entrambi hanno un punteggio CVSS 4.0 di 9.2.

Il punto che mi preoccupa di più è che il problema non sta nell’applicazione ma nel motore PHP stesso: su Apache con mod_php l’attacco avviene durante l’avvio della richiesta, prima che venga eseguita una sola riga del vostro codice. Non serve avere un plugin vulnerabile. E i tentativi di sfruttamento ci sono già: Amazon ne ha registrato uno sui suoi honeypot il 17 ottobre, quattro giorni prima della pubblicazione, e watchTowr ne segnala dal 21 ottobre.

Perché succede

Le due vulnerabilità sono diverse ma della stessa famiglia:

• CVE-2026-109618 (“RCE via OOM corruption”): se PHP esaurisce la memoria mentre la richiesta è inizializzata solo a metà, la procedura di chiusura legge dati non validi. Una richiesta multipart/form-data costruita apposta basta a provocare questa condizione restando apparentemente dentro i limiti configurati.
• CVE-2026-109619 (“RCE via stale global state”): alcuni stati globali (sessioni, errori, estensioni) sopravvivono alla richiesta che li ha creati e vengono riutilizzati dalla richiesta successiva sullo stesso worker, prima che PHP li reinizializzi.

Chi è coinvolto

Tutte le versioni precedenti a 8.2.35, 8.3.36, 8.4.27 e 8.5.12, che sono le release corrette. Secondo gli advisory l’esecuzione di codice è confermata su Apache mod_php, mentre su PHP-FPM è confermato il percorso legato alle sessioni; FrankenPHP e LiteSpeed sono considerati probabilmente vulnerabili. In pratica: qualunque PHP che risponde a richieste web.

PHP 8.1 e precedenti non ricevono più correzioni ufficiali da php.net. Alcune distribuzioni le hanno comunque portate sui loro pacchetti: AlmaLinux, ad esempio, ha aggiornato anche gli stream 7.2, 7.3, 7.4 e 8.0 su AlmaLinux 8. Se però avete un PHP 7.x compilato a mano o fuori supporto, quello resta scoperto.

Attenzione: nelle PMI il PHP dimenticato è spesso su Windows, dentro un gestionale o un pacchetto tipo XAMPP che si porta dietro il suo php-cgi.exe. Cercatelo anche lì, non solo sui server Linux.

Prima di iniziare

Fate l’inventario di quali PHP girano davvero. Su un server Linux questo ciclo vi mostra i binari presenti e la loro versione:

for p in /usr/bin/php /usr/bin/php[0-9]* /opt/alt/php*/usr/bin/php; do [ -x "$p" ] && echo "$p $("$p" -r 'echo PHP_VERSION;')"; done

Non fidatevi però solo del numero di versione: le distribuzioni correggono spesso con un backport senza cambiare la versione upstream, quindi una Debian o una AlmaLinux aggiornata può continuare a dire, ad esempio, 8.2.33. Quello che conta è la versione del pacchetto confrontata con il bollettino di sicurezza della vostra distribuzione. Prima di aggiornare, come sempre, uno snapshot della VM o un backup recente.

L’aggiornamento

Su Debian e Ubuntu, compresi i repository di Ondřej Surý:

sudo apt-get update
apt list --upgradable 2>/dev/null | grep php
sudo apt-get install --only-upgrade 'php8.3*'
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'

Sostituite 8.3 con la vostra versione e ripetete per ognuna installata. Su RHEL, AlmaLinux e Rocky:

sudo dnf clean metadata && sudo dnf upgrade 'php*'
rpm -q php-common

Per le immagini Docker ufficiali scaricate il nuovo tag, ricostruite le vostre immagini con docker build --pull e ricreate i container. Plesk e cPanel distribuiscono i loro pacchetti PHP: controllate gli aggiornamenti dal pannello.

Il riavvio non è facoltativo

È l’errore che vedo più spesso: si aggiorna il pacchetto e ci si ferma lì. Un processo già avviato continua a usare il vecchio PHP finché non viene riavviato.

# PHP-FPM su Debian/Ubuntu
sudo systemctl restart php8.3-fpm
# PHP-FPM su RHEL/AlmaLinux
sudo systemctl restart php-fpm
# Apache con mod_php (un reload non basta)
sudo systemctl restart apache2   # oppure httpd

Per essere sicuri che nessun processo stia ancora usando le librerie vecchie, cercate i file mappati in memoria che risultano cancellati dal disco. Se il comando non restituisce nulla, siete a posto:

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

Se non potete aggiornare subito

Gli advisory sono chiari: l’unica mitigazione completa è l’aggiornamento. Esistono però alcune misure temporanee che riducono l’esposizione:

• disattivare il progresso degli upload, se l’applicazione non lo usa, con session.upload_progress.enabled = 0 nel php.ini o nel pool FPM;
• su PHP 8.5, impostare fatal_error_backtraces = 0;
• se l’applicazione non riceve upload, bloccare le richieste multipart/form-data sul reverse proxy o sul WAF;
• su FPM, valutare pm.max_requests = 1 se le prestazioni lo permettono, così ogni worker serve una sola richiesta.

Dopo ogni modifica riavviate tutti i worker. L’advisory cita anche memory_limit = -1 contro la prima vulnerabilità, ma io lo sconsiglio: toglie la protezione contro gli script fuori controllo e non copre comunque tutti i casi. Se un server proprio non si può correggere a breve, il National Cyber Security Centre britannico consiglia di toglierlo dalla rete, e sono d’accordo.

Se il problema persiste

Se il pacchetto corretto non compare, il mirror della vostra distribuzione potrebbe essere ancora indietro: ripulite la cache dei metadati e riprovate dopo qualche ora. Se avete esposto per giorni un PHP vulnerabile su Internet, l’aggiornamento chiude la porta ma non vi dice se qualcuno è già entrato: controllate i log del web server per richieste multipart anomale, i file PHP modificati di recente nelle cartelle web e i processi avviati dall’utente del web server.

Vi è capitato di trovare qualche PHP dimenticato durante l’inventario, magari dentro un gestionale? Raccontate nei commenti dove l’avete scovato e come l’avete aggiornato: possono essere utili ad altri.