PHP2Shell: due vulnerabilità critiche in PHP, esecuzione di codice da remoto. Aggiornate subito a PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35

Il 20 ottobre 2026 il team di sicurezza di PHP ha pubblicato un avviso che raramente si vede: una release di sicurezza straordinaria, programmata per mercoledì 21 ottobre alle 14:00 UTC, cioè le 16:00 in Italia, per correggere due vulnerabilità critiche, entrambe con un punteggio CVSS v4.0 di 9.2. Poche ore prima, alcuni dettagli erano trapelati online prima della fine dell’embargo, e da allora le falle circolano tra i ricercatori con il nome di PHP2Shell.

Ne ha dato un resoconto molto completo TurboLab, e la notizia è stata ripresa dalle principali testate e società di sicurezza internazionali. In questo articolo mettiamo in ordine cosa è confermato, cosa non lo è ancora, cosa fare subito e cosa stiamo facendo noi.

Aggiornamento del 21 ottobre, ore 16:00. PHP ha pubblicato l’avviso ufficiale e le versioni corrette: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le due vulnerabilità consentono l’esecuzione di codice da remoto senza autenticazione e codici d’attacco sono già pubblici: aggiornate subito.

L’avviso ufficiale di PHP

Il 21 ottobre il progetto PHP ha rilasciato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 insieme a un avviso dal titolo inequivocabile: Security advisory: Critical remote code execution vulnerabilities, update now. Le versioni correggono due vulnerabilità critiche che possono consentire l’esecuzione di codice da remoto senza autenticazione, e tutti gli utenti di PHP sono invitati ad aggiornare immediatamente.

Chi è a rischio

Secondo l’avviso, sono a rischio tutte le installazioni di PHP che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è considerato più alto per mod_php, per il quale esiste un exploit dimostrato in cui una richiesta non autenticata può innescare l’attacco prima che venga eseguito qualsiasi codice dell’applicazione.

Tradotto: non conta quanto siano aggiornati WordPress, i plugin o il CMS. Il problema è nell’interprete che li esegue.

Le due vulnerabilità

• CVE-2026-109618, esecuzione di codice tramite corruzione in caso di memoria esaurita. La gestione dell’esaurimento della memoria può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte. La pulizia di fine richiesta può poi trattare quei dati non validi come se fossero validi.
• CVE-2026-109619, esecuzione di codice tramite stato globale obsoleto. Uno stato interno legato a una richiesta può sopravvivere dopo che la memoria che lo conteneva è stata liberata. Una richiesta successiva gestita dallo stesso processo può usare quello stato prima che la normale inizializzazione lo azzeri.

Le analisi pubblicate in mattinata, che indicavano la funzione session.upload_progress, descrivevano quindi uno dei percorsi confermati per arrivare alla seconda vulnerabilità, non l’unico.

Come aggiornare

• Aggiornate a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, a seconda del ramo in uso. Sorgenti e pacchetti per Windows sono disponibili nella pagina dei download di PHP.
• Distribuzioni Linux e fornitori LTS hanno ricevuto le patch in anticipo: verificate la disponibilità dei pacchetti aggiornati presso il vostro fornitore.
• PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP. Alcune distribuzioni e fornitori LTS offrono correzioni portate sulle versioni vecchie: chiedete al vostro fornitore, oppure passate a una versione supportata. Data la gravità, il team di sicurezza di PHP ha comunque fornito correzioni minime dei sorgenti per PHP 7.4, 8.0 e 8.1, per chi compila PHP da sé o non ha accesso a un fornitore LTS.
• Chi usa il repository rpms.remirepo.net, mantenuto da volontari e molto diffuso su Red Hat, AlmaLinux e Rocky Linux, è invitato da PHP a passare ai pacchetti della distribuzione o a compilare dai sorgenti per poter aggiornare subito: secondo l’avviso, il repository non avrà aggiornamenti in giornata.

Se non potete aggiornare subito

L’avviso è molto chiaro: solo l’aggiornamento è una soluzione completa. Le misure seguenti riducono l’esposizione a specifici percorsi d’attacco, ma non rendono un’installazione sicura.

Per CVE-2026-109618, corruzione in caso di memoria esaurita:

• impostare memory_limit=-1 in un modo che le applicazioni non possano sovrascrivere, ad esempio con php_admin_value nel pool di PHP-FPM o nella configurazione di Apache, e verificare che nessun pool, cartella o applicazione reimposti un limite finito. Questo elimina il fallimento controllabile dovuto al limite di memoria di PHP, ma un errore di allocazione a un livello più basso può comunque raggiungere il percorso vulnerabile;
• impostare un post_max_size basso: 8M per le applicazioni che non richiedono upload di file, 32M se gli upload sono necessari, mantenendo upload_max_filesize inferiore a post_max_size. Valutate anche limiti a livello di web server o proxy su dimensione della richiesta decodificata, numero di campi, parti multipart, numero di header e profondità di annidamento, validi anche per le richieste senza un Content-Length utilizzabile;
• usare un limite di memoria a livello di container o di cgroup come barriera per la disponibilità del servizio, preferibilmente con una politica che termini solo il processo coinvolto. Non usare al suo posto RLIMIT_AS o RLIMIT_DATA, che possono provocare proprio il fallimento di allocazione vulnerabile.

Per CVE-2026-109619, stato globale obsoleto:

• impostare session.upload_progress.enabled=0 e riavviare tutti i processi. L’impostazione va messa in php.ini, nel pool di PHP-FPM o nella configurazione del server, cioè dove si applica prima dell’elaborazione della richiesta: non con ini_set() né con i file .user.ini. Blocca i percorsi confermati legati alle sessioni, ma non altre varianti;
• su PHP 8.5, impostare fatal_error_backtraces=0 e riavviare tutti i processi. Blocca solo il percorso confermato legato ai backtrace degli errori fatali;
• rimuovere le impostazioni non valide o deprecate applicate per singola richiesta che generano messaggi diagnostici prima dell’inizializzazione. Nasconderli con error_reporting, display_errors o con l’operatore @ non serve;
• correggere gli errori fatali e i timeout di esecuzione che un attaccante può provocare, compresi quelli nei callback, nell’elaborazione di upload e importazioni e nelle operazioni di pulizia.

Exploit già in circolazione

Già nella mattinata del 21 ottobre, prima del rilascio ufficiale, erano comparsi online codici dimostrativi in grado di sfruttare le vulnerabilità, ripresi da diverse testate di sicurezza informatica. L’avviso ufficiale conferma l’esistenza di un exploit dimostrato. Con le correzioni ora pubbliche, confrontare il codice prima e dopo la patch diventa ancora più semplice: è ragionevole aspettarsi scansioni e attacchi automatizzati su larga scala nelle prossime ore e nei prossimi giorni.

Le sezioni che seguono descrivono la situazione della mattina del 21 ottobre, prima dell’avviso ufficiale, e restano come cronaca di come si è sviluppata la vicenda.

Cosa era confermato prima del rilascio

La fonte ufficiale è una sola: l’avviso pubblicato sul sito di PHP. Dice esattamente questo:

• esistono due vulnerabilità critiche, valutate entrambe 9.2 su 10 con il sistema CVSS v4.0;
• la release che le corregge è prevista per il 21 ottobre 2026 alle 14:00 UTC;
• il team si riserva di anticipare il rilascio se i dettagli dovessero diventare pubblici o se comparissero prove di sfruttamento attivo;
• dettagli tecnici, versioni coinvolte e versioni corrette saranno pubblicati solo insieme alla release;
• tutti gli utenti di PHP sono invitati a prepararsi ora per aggiornare non appena le patch saranno disponibili.

Un avviso preventivo di questo tipo, con data e ora del rilascio annunciate in anticipo, è una scelta che il progetto PHP riserva ai casi davvero seri. È il segnale che va preso sul serio.

Cosa si diceva prima del rilascio

Attorno all’avviso ufficiale si sono accumulate molte informazioni provenienti da fughe di notizie e da società di sicurezza. Sono utili per capire la portata del problema, ma vanno lette per quello che sono: anticipazioni non verificate dal progetto PHP.

• Il nome PHP2Shell circola tra i ricercatori, ma non compare nel comunicato ufficiale.
• Gli identificativi CVE-2026-109618 e CVE-2026-109619 sono stati riservati, ma al momento non hanno una descrizione pubblica e il comunicato di PHP non li cita.
• La natura delle falle: secondo watchTowr si tratta di vulnerabilità di esecuzione di codice da remoto (RCE), cioè la possibilità per un attaccante di eseguire comandi sul server. La società dichiara di aver riprodotto una delle due, senza pubblicare dettagli.
• Le versioni coinvolte: si parla di PHP 5, 7 e 8. Se fosse vero, il problema riguarderebbe praticamente ogni versione di PHP in uso negli ultimi quindici anni.
• Il rischio per le versioni obsolete: le patch dovrebbero arrivare solo per i rami di PHP 8 ancora supportati. Chi usa PHP 5, PHP 7 o versioni di PHP 8 fuori supporto potrebbe restare senza una correzione ufficiale.
• Il punteggio: alcune fonti parlano di CVSS 10, contro il 9.2 dichiarato da PHP.

Alla prima pubblicazione di questo articolo non risultavano sfruttamenti attivi né exploit pubblici. Nel giro di poche ore la situazione è cambiata: come spiegato più sopra, sono comparsi codici dimostrativi pubblici. E diversi analisti si aspettano attacchi automatizzati di massa a brevissima distanza dalla pubblicazione delle patch: una volta che le correzioni sono pubbliche, confrontarle con il codice precedente permette di capire dov’era il problema e di costruire un attacco in tempi molto brevi.

Perché riguarda praticamente tutti

Se la vulnerabilità si trova nel motore di PHP e non in una singola applicazione, il perimetro è enorme. PHP fa girare WordPress, WooCommerce, PrestaShop, Magento, Joomla, Drupal, OpenCart, moltissimi gestionali, aree riservate, pannelli di controllo come cPanel e Plesk, e una quantità di software che nemmeno dichiara di usarlo.

Non importa quanto sia aggiornato WordPress o quanto siano curati i plugin: se il problema è nell’interprete che li esegue, la protezione deve arrivare dall’aggiornamento di PHP stesso. Ed è un aggiornamento che, per la maggior parte dei siti, non dipende da chi gestisce il sito ma da chi gestisce il server.

Il caso più delicato è quello dei server dimenticati: vecchie installazioni con PHP 5 o PHP 7, siti mai migrati, hosting condivisi non più seguiti, ambienti di test esposti su Internet. Sono proprio quelli che rischiano di non ricevere mai una correzione ufficiale, e che saranno i primi bersagli degli attacchi automatizzati.

Cosa fare, oltre ad aggiornare

L’aggiornamento resta la priorità assoluta. Intorno all’aggiornamento, ci sono alcune cose da fare subito.

• Fate l’inventario. Censite ogni server e ogni sito che usa PHP, con la versione esatta e il modo in cui è installato: pacchetti della distribuzione, repository esterni, pannelli di controllo, container, versioni compilate a mano.
• Preparate la procedura di aggiornamento. Chi aggiorna, su quali server, in quale ordine, con quali verifiche dopo l’aggiornamento e quale piano di ritorno indietro in caso di problemi.
• Date la priorità ai sistemi esposti. Prima i siti pubblici, gli e-commerce e i server che ospitano molti siti; poi gli ambienti interni.
• Verificate i backup. Che esistano, che siano recenti, che siano conservati fuori dal server e che si sappia come ripristinarli.
• Affrontate le versioni obsolete. Se avete siti su PHP 5 o PHP 7, è il momento di pianificare la migrazione a una versione di PHP 8 supportata. Nel frattempo, valutate se limitarne l’esposizione.
• Seguite solo le fonti ufficiali. L’annuncio di PHP, gli avvisi di sicurezza della vostra distribuzione Linux e del vostro fornitore. Non agite sulla base di voci o di presunti exploit pubblicati sui social.

Dopo il rilascio, oltre all’aggiornamento, conviene tenere d’occhio i segnali di una possibile compromissione: processi di sistema avviati dai processi di PHP, file nuovi nella cartella del sito, utenti o attività pianificate mai create.

Cosa stiamo facendo in Managed Server

Ci stiamo già adoperando con Ansible, lo strumento di automazione che usiamo per gestire la configurazione dei sistemi, per il patching di tutti i sistemi che gestiamo. I playbook sono pronti per distribuire le versioni corrette di PHP su tutti i server in modo coordinato, non appena saranno disponibili, senza dover intervenire macchina per macchina.

È proprio in situazioni come questa che si vede la differenza tra un’infrastruttura gestita in modo strutturato e una gestita a mano: quando una vulnerabilità critica coinvolge un componente presente ovunque, il tempo che passa tra il rilascio della patch e l’aggiornamento dell’ultimo server è ciò che separa un sistema protetto da un sistema esposto agli attacchi automatizzati.

Per i clienti con versioni di PHP non più supportate, valuteremo caso per caso le azioni da intraprendere e la migrazione verso un ramo di PHP 8 supportato.

Se il vostro sito non è ospitato da noi e non sapete con certezza chi aggiornerà PHP sul vostro server, e quando, è il momento di chiederlo. Se avete bisogno di aiuto per l’inventario, l’aggiornamento o la migrazione da versioni obsolete, la nostra assistenza sistemistica Linux è a disposizione.

Aggiornamenti

Il progetto PHP ha pubblicato la release e l’avviso ufficiale, riportati in apertura. Aggiorneremo questo articolo con eventuali nuove indicazioni ufficiali.

Fonti

• PHP, “Security advisory: Critical remote code execution vulnerabilities, update now” del 21 ottobre 2026
• PHP, annuncio “Upcoming Critical PHP Security Release” del 20 ottobre 2026
• TurboLab, “Allarme rosso PHP: due vulnerabilità critiche”
• BleepingComputer, avviso del team PHP e dichiarazioni di watchTowr
• Cyber Security News, proof of concept pubblica per PHP2Shell
• PentestIT, cosa sappiamo su CVE-2026-109618 e CVE-2026-109619
• Huntress, stato delle informazioni e raccomandazioni operative