Patch urgente PHP (PHP2Shell): come controllare e aggiornare i tuoi server

Il 21 ottobre 2026 il team PHP ha rilasciato aggiornamenti urgenti per due vulnerabilità critiche (CVE-2026-109618 e CVE-2026-109619, insieme “PHP2Shell”, 9,2 ciascuna su CVSS 4.0). Si trovano nel runtime, non in un'applicazione: anche una pagina “Hello World” su una versione vulnerabile di PHP può essere attaccata, senza alcun account. La correzione è in 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le hanno trovate ricercatori di Wiz, Calif e OpenAI.

Perché aggiornare l'applicazione non basta

Aggiornare WordPress, Laravel o Nextcloud non cambia la versione di PHP sotto. Quella arriva dal pacchetto del server, dall'hosting o dall'immagine del container. Secondo l'advisory di PHP sono interessati tutti i modi di eseguirlo (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). Il più pericoloso è mod_php: una singola richiesta può far partire l'attacco prima che giri il codice dell'applicazione. Inoltre si può leggere la memoria del processo PHP, dove possono esserci password, token e chiavi di altre richieste.

Passo 1: trova tutte le installazioni di PHP

Su un server raramente c'è un solo PHP. Posti tipici:

• Il pacchetto della distribuzione (php -v, php-fpm).
• Versioni del pannello, per esempio Plesk in /opt/plesk/php/*.
• Container: Nextcloud, WordPress e altri hanno il proprio PHP nell'immagine (docker exec NOME php -v).
• Handler aggiuntivi per singoli siti, su una versione diversa dal resto.

php -v
ls /opt/plesk/php/ 2>/dev/null
for c in $(docker ps --format '{{.Names}}'); do echo -n "$c: "; docker exec $c php -v 2>/dev/null | head -1; echo; done

Confronta ogni versione con la tabella: sotto 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 è vulnerabile. PHP 8.1 e precedenti non ricevono più aggiornamenti, per 7.4, 8.0 e 8.1 esistono solo backport del sorgente; 8.2 finisce il 31 dicembre 2026.

Passo 2: aggiorna e riavvia

Su Debian/Ubuntu il solito apt update && apt upgrade. Importante: le distribuzioni spesso rilasciano la correzione con un numero di versione “vecchio”, quindi controlla il changelog del pacchetto cercando il numero CVE, non solo la stringa di versione. Poi riavvia PHP-FPM o Apache, compresi i worker PHP di lunga durata. Senza riavvio gira ancora il codice vecchio.

Esempio pratico: il mio server stasera

Sul mio server Plesk avevo tre fonti: il pacchetto di sistema Ubuntu (8.3.6), PHP 8.5.11 di Plesk e due immagini Docker con PHP proprio. Risultato:

• PHP 8.5 di Plesk aggiornato a 8.5.12 con l'installer di Plesk.
• Per il pacchetto Ubuntu non c'era ancora la correzione. Invece di aspettare ho installato PHP 8.3 di Plesk (ora 8.3.36) e spostato i siti su quell'handler. Stessa versione minore, quindi poco rischio di incompatibilità. Poi ho provato ogni sito.
• I container (Nextcloud AIO) hanno ancora un PHP più vecchio. Lì aiuta solo la nuova immagine, appena esce.

Synology, Plesk, hosting condiviso, Docker: cosa fare?

• Hosting condiviso (ad es. STRATO o IONOS): PHP è gestito e aggiornato dal provider. Controlla nel pannello quale versione di PHP usa il sito e passa a una versione supportata. Tieni comunque aggiornata la tua applicazione (WordPress, Nextcloud, shop). È il mio parere tecnico, non una dichiarazione di un provider.
• Plesk: ogni versione di PHP è un pacchetto a sé. Installa gli aggiornamenti con l'aggiornamento di Plesk o il gestore pacchetti, poi verifica: /opt/plesk/php/8.3/bin/php -v (per ogni versione installata) e plesk bin php_handler --list.
• Synology: PHP arriva con Web Station e il Centro pacchetti. Finché Synology non rilascia un aggiornamento, resta solo l'attenuazione via php.ini: guida per NAS, Plesk e server.
• Docker e container: la correzione è nell'immagine. docker compose pull && docker compose up -d, poi docker exec <container> php -v.

Qualche consiglio

• Prima l'inventario: annota dove gira PHP (sistema, pannello, container). Alla prossima emergenza risparmi la ricerca.
• Evita mod_php: dove puoi passa a PHP-FPM. Riduce la superficie d'attacco e permette pool separati.
• Prova dopo ogni cambio: home, login, moduli, cron. Un 200 sulla home non basta.
• I palliativi non sono una soluzione: limiti come un post_max_size basso riducono solo singole vie d'attacco. L'aggiornamento resta obbligatorio.
• Pianifica la fine del supporto: chi è su 8.1 o più vecchio ha bisogno di un piano di migrazione, non solo di questa patch. 8.2 finisce tra due mesi.
• Tieni d'occhio i segreti: poiché la memoria era leggibile, ruota token e chiavi se vedi tracce sospette.

Fonti: The Hacker News e l'advisory di sicurezza di PHP.