Il 21 ottobre 2026 alle 14:00 UTC il team di PHP ha pubblicato le correzioni per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, note come PHP2Shell. Abbiamo iniziato circa un’ora dopo. Verso le 17:00 UTC tutti i server che gestiamo erano messi in sicurezza: 88 progetti sotto il nostro supporto. In questo articolo raccontiamo come lo abbiamo fatto e cosa ci ha rallentato, perché gli stessi ostacoli si trovano su molti server che nessuno ha ancora aggiornato.
Se ti serve solo sapere se il tuo sito è coinvolto e cosa chiedere all’hosting, leggi il nostro primo articolo su PHP2Shell.
La prima ora: chiudere il percorso di attacco ovunque
Installare un PHP corretto su decine di server richiede tempo. Disattivare il meccanismo vulnerabile richiede minuti. Per questo l’abbiamo fatto per primo, su ogni server, prima di compilare qualsiasi cosa.
L’advisory di PHP indica session.upload_progress.enabled come uno dei percorsi per CVE-2026-109619. Lo abbiamo impostato a off nella configurazione principale di ogni versione di PHP su ogni server e abbiamo riavviato i processi PHP. L’advisory avverte che .user.ini e ini_set() non bastano, quindi abbiamo modificato i file a livello di server. Su PHP 8.5 abbiamo anche disattivato fatal_error_backtraces, come suggerisce l’advisory.
Questo ha chiuso solo il percorso confermato di CVE-2026-109619 tramite le sessioni. Per CVE-2026-109618 serviva l’aggiornamento vero e proprio.
Tre tipi di server, tre modi di aggiornare
I nostri 88 progetti girano su configurazioni diverse, e ognuna ha richiesto una strada propria.
Server con PHP dai pacchetti della distribuzione. Qui la correzione arriva dai manutentori dei pacchetti. Ubuntu ha pubblicato i pacchetti corretti il giorno del rilascio. Un dettaglio per chi controlla un server del genere: dopo l’aggiornamento php -v può mostrare ancora il numero vecchio, per esempio 8.3.6, perché Ubuntu corregge il pacchetto e mantiene la versione. Controlla invece la versione del pacchetto.
Server gestiti con un pannello di controllo per hosting. Diversi server usano aaPanel, che compila un proprio PHP. Il giorno del rilascio il pannello non aveva PHP aggiornato. Aspettare il pannello voleva dire lasciare questi server aperti per un tempo indefinito, quindi abbiamo compilato PHP noi.
Container Docker. Alcuni progetti eseguono PHP dentro container costruiti da immagini esistenti. Ricostruire e ridistribuire un’intera applicazione nel mezzo di un incidente aggiunge rischio. Abbiamo invece corretto PHP dentro i container in esecuzione e pianificato per dopo una ricostruzione completa delle immagini.
Compilare PHP da soli senza rompere il pannello
La build di PHP di un pannello è diversa da una standard. Se compili PHP con le opzioni predefinite e lo metti al suo posto, mancano estensioni e il pannello non riconosce più il proprio PHP.
Abbiamo scritto un unico script di build e lo abbiamo eseguito per ogni versione di PHP su ogni server con il pannello:
- legge le opzioni di configure esatte dal PHP già installato, così la nuova build ha le stesse estensioni e gli stessi percorsi;
- compila la versione corretta dai sorgenti ufficiali;
- controlla a quali librerie OpenSSL e curl si collega il nuovo binario. Il pannello collega alcune versioni di PHP a proprie copie più vecchie di queste librerie, quindi lo script si assicura che la nuova build usi le stesse;
- fa un backup dei vecchi binari, installa i nuovi e riavvia PHP;
- se PHP non riparte, ripristina da solo i vecchi binari.
Con lo script potevamo aggiornare una versione di PHP su un server, controllare i siti e ripetere sul successivo senza lavoro manuale ogni volta.
PHP 7.4, 8.0 e 8.1: nessun rilascio ufficiale
Il team di PHP non pubblica più rilasci per questi rami. Per PHP2Shell ha pubblicato solo le modifiche ai sorgenti per 7.4, 8.0 e 8.1. Alcuni dei nostri progetti girano ancora su queste versioni.
In quei casi abbiamo applicato le correzioni ai sorgenti del team di PHP all’ultimo rilascio di ogni ramo e lo abbiamo compilato con lo stesso script. Le modifiche pubblicate toccano anche i file di versione e i changelog, che non si applicano in modo pulito a un rilascio, quindi abbiamo applicato solo le modifiche al codice.
Un server usava PHP 7.4 dai pacchetti di Ubuntu 20.04. Per quella versione di Ubuntu la correzione arriva solo tramite la manutenzione di sicurezza estesa di Ubuntu (ESM), che quel server non usa. Abbiamo compilato PHP 7.4 con gli stessi flag di build che usa Ubuntu e sostituito solo il binario PHP-FPM, tenendo l’originale accanto. Un futuro aggiornamento del pacchetto sovrascriverebbe la nostra build, quindi lo abbiamo annotato nella documentazione del progetto.
Container: corretti ora, ricostruiti dopo
Per ogni container abbiamo compilato il PHP corretto in una copia pulita dell’immagine ufficiale per lo stesso sistema operativo, poi abbiamo copiato nel container in esecuzione solo i binari di PHP e le estensioni necessarie, con un backup degli originali all’interno.
Un’immagine basata su Alpine richiedeva le stesse patch aggiuntive ai sorgenti che applica l’immagine Docker ufficiale di PHP, altrimenti la build falliva con un compilatore più recente.
Il limite di questo approccio: la correzione vive solo finché qualcuno non ricrea il container dalla vecchia immagine. Se il tuo team ha corretto i container in questo modo, metti in programma la ricostruzione delle immagini, altrimenti la vulnerabilità torna con il prossimo deploy.
Dopo l’aggiornamento: i log
Quando tutti i server avevano un PHP corretto, abbiamo esaminato i log del web server e di PHP su tutti i server alla ricerca di richieste compatibili con il modo in cui le vulnerabilità potevano essere sfruttate. Non abbiamo trovato segni di sfruttamento.
Cosa diremmo a un proprietario di sito dopo quella sera
- La velocità del tuo hosting è la tua velocità. Se il tuo PHP arriva da un pannello o da un provider che lo aspetta, il sito resta aperto finché loro non intervengono. Chiedi loro oggi che versione stai usando.
- Il PHP vecchio ha ancora un costo. PHP 8.1 e precedenti questa volta hanno ricevuto solo correzioni al codice sorgente. La prossima volta potrebbero non riceverne nessuna. Il supporto per PHP 8.2 termina il 31 dicembre 2026.
- Container e build personalizzate hanno bisogno di un responsabile. Nessuno li aggiorna in automatico. Qualcuno deve sapere che esistono e come ricostruirli.
Il nostro monitoraggio automatico lavora giorno e notte, e i nostri ingegneri intervengono quando segnala un incidente.
Se ti serve lo stesso per i tuoi server
Controlliamo la tua versione di PHP e la aggiorniamo entro un giorno lavorativo. Scrivici.
Per un’assistenza continuativa guarda assistenza server, assistenza per siti web e DevOps. Se la tua app mobile comunica con un backend PHP, quel backend ha bisogno dello stesso aggiornamento; lo seguiamo nell’ambito dell’assistenza per app mobili. Per sapere se c’è altro di esposto, richiedi un penetration test.
Fonti
- Annuncio del team di PHP e misure di mitigazione: https://www.php.net/archive/2026.php
- Advisory di sicurezza: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w e https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available