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; doneConfronta 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.
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_sizebasso 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.