PHP2Shell: le vulnerabilità critiche di PHP e cosa fare subito

Il 21 ottobre 2026 il team di sicurezza di PHP ha pubblicato in via straordinaria quattro nuove versioni del linguaggio per correggere due vulnerabilità che permettono di eseguire codice su un server da remoto, senza credenziali.
I ricercatori le hanno chiamate PHP2Shell: da una richiesta web a una shell sul server.
Chi le ha individuate le colloca nel codice da oltre dieci anni, dalla versione 5.4.

PHP è il linguaggio su cui gira la maggior parte dei siti aziendali, dei CMS come WordPress, Joomla e Drupal, degli e-commerce e di molti gestionali web.
Le falle non sono in un plugin o in un’applicazione ma nell’interprete. Aggiornare il CMS non basta.

In questo articolo mettiamo in fila cosa è successo, chi è esposto e cosa fare adesso, con le informazioni disponibili al 22 ottobre.

1. Cosa è successo
2. Chi è esposto
3. Cosa fare adesso
4. Se il sito è gestito da un fornitore
5. Dopo l’aggiornamento

Cosa è successo

Le due vulnerabilità hanno gli identificativi

• CVE-2026-109618
• CVE-2026-109619

PHP le classifica entrambe come critiche, con un punteggio CVSS v4.0 di 9.2.
Sono due errori nella gestione della memoria: il primo si attiva quando PHP esaurisce la memoria mentre elabora una richiesta, per esempio un modulo con file allegati; il secondo riguarda informazioni che restano in memoria da una richiesta all’altra nei processi che servono più richieste di fila.
In entrambi i casi chi attacca non ha bisogno di credenziali e ottiene i privilegi del processo PHP: di solito quanto basta per leggere la configurazione dell’applicazione, le credenziali del database e i file del sito.

Il vettore del punteggio aggiunge un dettaglio che conta.
Le due falle sono raggiungibili dalla rete e senza credenziali ma hanno complessità alta e condizioni preliminari da soddisfare: sono serie, non si sfruttano con una richiesta improvvisata. Il CVSS misura la gravità e non la probabilità che qualcuno le usi davvero.
Su quel fronte la risposta è già arrivata: i primi tentativi di sfruttamento sono stati segnalati prima ancora che uscissero le correzioni.

La cronologia spiega perché se ne parla tanto.

La fuga di notizie ha cambiato i tempi di risposta.
Normalmente chi gestisce i server riceve la correzione e la notizia insieme.

Questa volta per un giorno intero si è saputo che esisteva un problema grave senza avere nulla da installare, mentre in rete cominciavano a circolare presunti exploit. Secondo CERT-AgID circolano diversi codici dimostrativi pubblici, la cui efficacia non è stata pienamente verificata: il team di PHP, alla data del rilascio, non ne aveva trovato di funzionanti. Vanno comunque trattati come potenzialmente malevoli essi stessi.

Il precedente è noto: nel 2024 una vulnerabilità di php-cgi, la CVE-2024-4577, fu attaccata entro 24 ore dalla pubblicazione.

Chi è esposto

Secondo l’avviso ufficiale è a rischio ogni installazione di PHP che risponde a richieste web.
Il livello di rischio cambia con il modo in cui PHP è collegato al web server.

Quali versioni sono corrette

Che il CMS sia aggiornato non cambia nulla.
I ricercatori hanno riportato attacchi funzionanti senza autenticazione contro versioni specifiche di WordPress, Drupal, Joomla e Magento.
La falla sta sotto l’applicazione e l’applicazione non può difendersi.

Le versioni fuori supporto

Le versioni non più supportate sono il vero problema.
Un conteggio basato sulle intestazioni dei server esposti in rete, pubblicato il 20 ottobre, stimava che il 59% degli host che dichiarano la propria versione di PHP usi la 8.1 o precedenti: circa 884.000 macchine. È un dato approssimativo, perché molti server non dichiarano la versione e altri usano pacchetti corretti dalla distribuzione con numeri di versione vecchi. Indica però dove sta la massa del rischio: sui server che nessuno aggiorna da anni.

Su queste versioni serve una precisazione.
CSIRT Italia scrive che per PHP 8.1 e precedenti non saranno rilasciate patch né workaround: vale per gli aggiornamenti ufficiali, perché quei rami sono fuori supporto. Vista la gravità, il team di PHP ha comunque pubblicato correzioni minime in codice sorgente, utili solo a chi compila PHP da sé. Per tutti gli altri restano il pacchetto corretto del fornitore della distribuzione (se esiste) o la migrazione.

In azienda PHP non vive solo nel sito istituzionale.
Ci sono il portale clienti, l’area riservata dei fornitori, il gestionale web, il pannello di controllo dell’hosting, a volte l’interfaccia di un’appliance comprata anni fa. Sapere quanti server PHP sono esposti e con quale versione è il primo passo: è il lavoro dell’inventario degli asset e quando manca, come in questi giorni, si paga in ore.

Cosa fare adesso

L’unica soluzione completa, ripetono sia il team di PHP sia CSIRT Italia, è aggiornare.
Le raccomandazioni ufficiali si riassumono in cinque passaggi, più un controllo.

• Trovare tutte le installazioni
  versione, modalità di esecuzione (mod_php, PHP-FPM, CGI), esposizione su internet, chi le gestisce. Compresi container, prodotti di terzi e servizi in gestione a fornitori.
• Aggiornare prima ciò che è esposto
  i sistemi raggiungibili da internet e quelli che trattano dati sensibili vengono prima di tutto il resto. Il criterio è lo stesso che abbiamo descritto parlando di come prioritizzare le vulnerabilità.
• Riavviare tutto
  dopo l’aggiornamento vanno riavviati Apache, PHP-FPM e ogni processo PHP di lunga durata. I container vanno ricostruiti sulle immagini ufficiali ripubblicate e ricreati: scaricare la nuova immagine non basta. Finché girano i processi vecchi il sito resta vulnerabile.
• Verificare la versione che serve davvero le pagine
  quella mostrata dal terminale può essere diversa da quella usata dal web server. Sulle distribuzioni Linux che correggono i pacchetti senza cambiare il numero di versione fa fede l’avviso di sicurezza del fornitore.
• Se non si può aggiornare subito, ridurre l’esposizione
  limitare l’accesso alle sole persone e ai soli sistemi che ne hanno bisogno o mettere il servizio temporaneamente offline, come raccomanda anche CSIRT Italia. La modalità manutenzione del CMS non serve: PHP elabora la richiesta prima che il codice del sito entri in gioco. Serve una pagina statica servita dal web server. L’avviso di PHP indica anche alcune impostazioni temporanee (disattivare il progresso degli upload di sessione, contenere memoria e dimensione delle richieste) da applicare a livello di server e non di applicazione. Sono misure parziali, che vanno affidate a un responsabile con una data di scadenza.
  Anche un WAF da solo, avverte l’ufficio federale svizzero, non basta.

Se qualcosa è già successo

CSIRT Italia raccomanda di analizzare i log a ritroso anche dopo aver aggiornato.
I segnali da cercare sono:

1. richieste HTTP anomale
2. errori ripetuti di memoria esaurita
3. interruzioni inattese dei processi PHP
4. processi non previsti
5. modifiche non autorizzate ai file dell’applicazione
6. connessioni di rete anomale verso l’esterno.

Alcune analisi collocano i primi tentativi prima della fuga di notizie: conviene guardare i log almeno dal 17 ottobre. Log puliti non sono una prova.
Un aggiornamento non cancella una compromissione già avvenuta e un sospetto va trattato come un incidente, non chiuso con la patch.

Se il sito è gestito da un fornitore

Molte aziende non gestiscono direttamente il server su cui gira il sito.
C’è un hosting condiviso, un’agenzia web, un fornitore del gestionale. In questi giorni chi gestisce server per conto di altri ha dovuto aggiornare centinaia o migliaia di macchine in poche ore, con i pacchetti delle distribuzioni che arrivavano in tempi diversi. Non tutti ci sono già riusciti.

La domanda da fare al fornitore non è “siamo protetti?”.

È più precisa: quale versione di PHP usa il nostro sito, quando è stata aggiornata, se i processi sono stati riavviati e se la verifica è stata fatta sulla versione che serve davvero le pagine.
La risposta va chiesta per scritto.

Se il fornitore risponde che il sito gira su PHP 7 o 8.0 “perché il gestionale non supporta versioni più recenti”, il problema non è di questa settimana.
È un’applicazione che dipende da un software senza più correzioni di sicurezza e va trattata come tale: isolata, protetta e messa in un piano di migrazione con una data.

Dopo l’aggiornamento

Passata l’emergenza restano due lavori.
Il primo è confermare dall’esterno che l’aggiornamento è arrivato davvero: che i sistemi esposti non rispondano più con versioni vulnerabili, che non siano rimasti server dimenticati, che le impostazioni temporanee non abbiano introdotto altri problemi.
È il controllo che fa un web vulnerability assessment sulle applicazioni e un vulnerability assessment sull’infrastruttura. Come funziona l’abbiamo spiegato nell’articolo sul website vulnerability assessment.

Il secondo è non arrivare alla prossima volta nello stesso modo.
PHP2Shell ha mostrato quanto contano tre cose che non si improvvisano: sapere quali sistemi si hanno, sapere chi li aggiorna e in quanto tempo, sapere su quali versioni non arriveranno più correzioni. Il 31 dicembre 2026 anche PHP 8.2 esce dal supporto. Chi oggi è su quel ramo ha poco più di due mesi per pianificare il passaggio.