PHP2Shell: le falle critiche di PHP e cosa fare subito

In breve: Le vulnerabilità chiamate PHP2Shell (CVE-2026-109618 e CVE-2026-109619) permettono di eseguire codice da remoto su un server PHP. Sono corrette in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35: chi usa una versione precedente deve aggiornare. Il 23 ottobre PHP ha chiesto anche di disattivare session.upload_progress in attesa della prossima versione. WordPress e WooCommerce non vanno aggiornati: va aggiornato il PHP del server.

PHP fa girare buona parte dei siti del mondo: WordPress, WooCommerce, i gestionali scritti in casa, molti negozi online. Il 21 ottobre 2026 il progetto PHP ha corretto due vulnerabilità che permettono di eseguire codice sul server da remoto. Tradotto: in certe condizioni chi attacca può prendere il controllo della macchina. Il 23 ottobre è arrivato un secondo avviso. Ecco cosa è successo e cosa controllare oggi.

Cosa è successo

Il 20 ottobre PHP ha annunciato un rilascio di sicurezza per due falle critiche. Il giorno dopo sono uscite le versioni corrette: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le due vulnerabilità hanno un punteggio CVSS v4.0 di 9,2 su 10 e sono note con il nome PHP2Shell:

• CVE-2026-109618: quando la memoria finisce PHP può fermarsi a metà mentre prepara i dati della richiesta. La pulizia successiva tratta quei dati incompleti come validi.
• CVE-2026-109619: alcuni dati di una richiesta sopravvivono dopo che la loro memoria è stata liberata. Una richiesta successiva sullo stesso processo può usarli prima che vengano azzerati.

Secondo l'avviso di PHP sono coinvolte tutte le installazioni web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto è con mod_php: qui l'attacco dimostrato parte prima ancora che il codice del sito venga eseguito.

Il secondo avviso, del 23 ottobre

Due giorni dopo PHP ha pubblicato un avviso informativo su un caso legato al monitoraggio del caricamento dei file nelle sessioni (session upload progress), registrato come CVE-2026-115560. Le versioni del 21 ottobre non lo chiudono: la correzione arriverà con la prossima versione di manutenzione.

Il caso è raro. Serve che il sito imposti nella configurazione un gestore di serializzazione delle sessioni php_binary o php_serialize e poi lo cambi in php durante l'esecuzione con ini_set() prima di session_start(). Serve inoltre che il monitoraggio del caricamento sia attivo. Chi non cambia mai il gestore durante l'esecuzione può lasciare la funzione accesa.

La raccomandazione è comunque semplice: impostare session.upload_progress.enabled=0 fino al prossimo aggiornamento. Era già tra le mitigazioni della seconda falla: chi lo ha fatto il 21 ottobre deve lasciarlo così. L'impostazione va nel php.ini, nel pool di PHP-FPM o nella configurazione del server web e poi vanno riavviati i processi PHP. Non basta scriverla con ini_set() o nel file .user.ini.

Lo stesso giorno l'Agenzia per la cybersicurezza nazionale ha aggiornato il suo bollettino (AL07/261021/CSIRT-ITA). Chiede di aggiornare e di cercare nei registri tracce di attacco: richieste HTTP anomale, errori di memoria esaurita, processi PHP interrotti all'improvviso, processi non previsti, file modificati senza motivo e connessioni di rete strane. Se un servizio non si può aggiornare in tempi brevi l'ACN invita a valutare la sospensione dell'accesso.

Lo stanno già sfruttando?

Ci sono segnali concreti. Amazon ha registrato sui suoi server esca un tentativo di sfruttamento il 17 ottobre, prima che le falle fossero rese pubbliche. Dopo la divulgazione sono circolati codici di attacco dimostrativi e diverse società di sicurezza hanno visto scansioni su larga scala.

Il quadro è meno drammatico di quanto sembri a una prima lettura. Sansec ha verificato che gli exploit pubblici non funzionano su un'installazione di PHP con le impostazioni predefinite. Arctic Wolf parla di molte scansioni e pochi successi. Questo non cambia la conclusione: la versione corretta va installata comunque perché gli attacchi migliorano in fretta.

WordPress e WooCommerce: cosa cambia

WordPress.org e WooCommerce lo hanno chiarito il 21 ottobre: non c'è nessun aggiornamento di WordPress o di WooCommerce da fare per queste falle. Il problema sta in PHP. Va aggiornato il PHP del server, tramite il fornitore di hosting o chi gestisce la macchina.

Per vedere la versione apri la bacheca e vai in Strumenti → Salute del sito → Info → Server. Conta il numero completo. Se il sito è su PHP 8.3 serve almeno la 8.3.36; su 8.4 almeno la 8.4.27 e così via. WooCommerce consiglia PHP 8.3 o successivo.

Cosa fare, caso per caso

Hosting condiviso (cPanel, Plesk e simili)

Dal pannello scegli il ramo di PHP, per esempio 8.3. La versione esatta dentro quel ramo invece la installa il fornitore. Controlla il numero in Salute del sito. Un numero sotto quello corretto non vuol dire per forza che il server sia scoperto: alcuni fornitori hanno ricompilato PHP con la correzione lasciando lo stesso numero di versione. In quel caso conta la data di compilazione (Build Date) che compare nella pagina phpinfo(): una data dal 21 ottobre 2026 in poi è un buon segno ma solo il fornitore può confermarlo. Il file con phpinfo() va cancellato subito dopo il controllo. Nel dubbio scrivi all'assistenza e chiedi se la correzione è applicata e se le impostazioni consigliate da PHP sono attive.

Se il sito usa ancora PHP 8.1 o una versione più vecchia il passaggio a un ramo supportato non è più rimandabile. Prima prova il sito su una copia: temi e plugin molto vecchi possono non funzionare con PHP 8.2 o successivi.

VPS e server dedicati

• Aggiorna i pacchetti di PHP dal gestore del sistema operativo o dal repository che usi.
• Le distribuzioni Linux spesso applicano la correzione senza cambiare il numero di versione principale: controlla l'avviso di sicurezza della distribuzione e la versione del pacchetto, non solo quella di PHP.
• Riavvia PHP-FPM o il server web. I processi già avviati continuano a usare il codice vecchio finché non ripartono.
• Se usi container, ricostruisci le immagini partendo da un'immagine di base aggiornata e rimettile in funzione.
• Imposta session.upload_progress.enabled=0 come indicato nell'avviso del 23 ottobre.
• Guarda i registri dal 17 ottobre in avanti con l'elenco dell'ACN in mano.

Se non puoi aggiornare subito

PHP indica alcune mitigazioni parziali e dice chiaramente che nessuna è completa. Per la prima falla: limiti più bassi alla dimensione delle richieste (post_max_size a 8 MB se il sito non riceve file, 32 MB se li riceve) e limiti imposti dal server web o dal proxy. Per la seconda: disattivare session upload progress, togliere le impostazioni non valide o deprecate che generano avvisi a ogni richiesta e correggere gli errori fatali che un visitatore può provocare. Nascondere gli avvisi con display_errors o @ non serve.

Un firewall applicativo aiuta. Dal 21 ottobre Cloudflare ha attivato regole specifiche anche nel piano gratuito. E ha già visto traffico di attacco reale. È un filtro davanti alla porta, non una serratura nuova: non sostituisce l'aggiornamento.

Le versioni vecchie

PHP 8.1 e precedenti sono fuori supporto e il progetto PHP non rilascia più aggiornamenti per questi rami. Esistono correzioni minime per i rami 7.4, 8.0 e 8.1 e alcuni fornitori le distribuiscono ma restare lì significa dipendere da altri per ogni falla futura. Anche PHP 8.2 si avvicina alla fine: il supporto termina il 31 dicembre 2026. Chi deve aggiornare comunque conviene che passi direttamente a 8.3 o 8.4.

Questo articolo riassume gli avvisi ufficiali disponibili al 24 ottobre 2026. Non sostituisce una verifica tecnica del tuo server: le indicazioni possono cambiare con le prossime versioni di PHP.

Approfondimenti: sicurezza di WordPress e WooCommerce: le misure che contano · hosting per un negozio WooCommerce

Domande frequenti

Cos'è PHP2Shell?

È il nome dato a due vulnerabilità critiche di PHP, CVE-2026-109618 e CVE-2026-109619, corrette il 21 ottobre 2026. Permettono a un attaccante di eseguire codice sul server da remoto. Il punteggio CVSS v4.0 è 9,2 su 10.

Quali versioni di PHP sono sicure?

Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 o successive. PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti dal progetto PHP: vanno portate a un ramo supportato oppure servono correzioni del fornitore.

Devo aggiornare WordPress o WooCommerce?

No. WordPress.org e WooCommerce hanno chiarito che il problema è in PHP e non nel loro codice. Va aggiornato il PHP del server: su un hosting condiviso lo fa il fornitore, su un VPS chi lo gestisce.

Come vedo la versione di PHP del mio sito WordPress?

Nella bacheca apri Strumenti, poi Salute del sito, poi la scheda Info e la sezione Server. Il numero completo, per esempio 8.3.36, dice se la correzione c'è. Alcuni hosting e distribuzioni Linux applicano la correzione senza cambiare numero: in quel caso contano la loro comunicazione ufficiale e la data di compilazione indicata da phpinfo().

Cosa dice l'avviso del 23 ottobre?

PHP consiglia di impostare session.upload_progress.enabled=0 fino alla prossima versione di manutenzione, contro un caso raro registrato come CVE-2026-115560. L'impostazione va nel php.ini o nella configurazione del pool FPM e richiede il riavvio dei processi PHP.

Basta un firewall applicativo come quello di Cloudflare?

No. Cloudflare ha attivato regole anche nel piano gratuito e blocca molti tentativi ma lo dice chiaramente: il firewall riduce il rischio e non sostituisce l'aggiornamento di PHP.