PHP2Shell è una vera minaccia? Gli exploit funzionano davvero?

Un aggressore può davvero eseguire comandi arbitrari su un server PHP limitandosi a inviare richieste HTTP sulla porta 80 o 8080, senza conoscere le credenziali di accesso e senza sfruttare vulnerabilità nell’applicazione Web? Le due falle critiche battezzate PHP2Shell hanno sollevato proprio questo interrogativo, alimentando una proliferazione di exploit pubblici che promettono di compromettere facilmente qualunque installazione vulnerabile.

Abbiamo avuto modo di verificare che molti dei Proof of Concept (PoC) comparsi su GitHub, tuttavia, non funzionano con un’installazione tipica di PHP! Alcuni presuppongono platealmente l’utilizzo di configurazioni insicure, altri l’esistenza di una seconda vulnerabilità e altri ancora dimostrano soltanto la possibilità di provocare un crash.

Eppure, gruppi di ricerca come Wiz Research e Datadog hanno documentato attacchi capaci di ottenere realmente l’esecuzione di codice da remoto (RCE), anche quando il codice dell’applicazione PHP non contiene errori sfruttabili.

PHP2Shell è quindi una minaccia concreta oppure un caso di allarmismo alimentato da exploit generati con l’intelligenza artificiale? Separiamo i risultati verificati dalle affermazioni non dimostrate, comprendendo soprattutto come il contenuto di una semplice richiesta HTTP possa arrivare ad alterare il funzionamento dell’interprete PHP.

PHP2Shell e gli exploit che non funzionano: da dove nasce lo scetticismo

Il 21 ottobre 2026, poco dopo la pubblicazione degli aggiornamenti di sicurezza, lo sviluppatore Elias Taylor ha sollevato una critica argomentata rispetto alla reale sfruttabilità di PHP2Shell. Il suo ragionamento parte da un’osservazione: nonostante la comparsa di numerosi repository che promettono exploit funzionanti, non è al momento possibile arrivare alla compromissione di un’installazione PHP standard.

Taylor non contesta l’esistenza delle vulnerabilità e di certo non suggerisce di ignorare gli aggiornamenti. Sostiene piuttosto che la complessità necessaria per trasformare i difetti individuati nell’interprete PHP in una RCE affidabile sia stata ampiamente sottostimata.

Nel 2021, configurazioni vulnerabili della libreria Java Log4j potevano essere attaccate attraverso stringhe appositamente costruite che raggiungevano il sistema di logging. Le prime dimostrazioni pubbliche permisero rapidamente di comprendere e riprodurre il problema, arrivando alla documentazione del noto attacco Log4Shell.

Nonostante l’assonanza con il nome, PHP2Shell presenta caratteristiche differenti. Non basta inserire una stringa speciale in un parametro HTTP per obbligare PHP a eseguire un comando. Le vulnerabilità interessano la gestione della memoria nativa dell’interprete: costruire un exploit completo richiede di influenzare le allocazioni, superare alcune protezioni e provocare una precisa sequenza di operazioni.

Un problema ricorrente nei PoC pubblici per lo sfruttamento di PHP2Shell consiste nella dipendenza da una Local File Inclusion (LFI), ossia una vulnerabilità applicativa che permette di includere un file locale scelto dall’attaccante. Altri progetti modificano le impostazioni delle sessioni PHP oppure fanno leva su applicazioni vulnerabili.

Se per ottenere un’esecuzione remota di codice bisogna prima introdurre un errore di programmazione nell’applicazione, la prova non rappresenta le condizioni ordinarie di un’installazione di produzione. Tuttavia, l’inaffidabilità “generalizzata” di numerosi exploit non implica che le vulnerabilità PHP sottostanti siano soltanto teoriche!

Come può una richiesta HTTP provocare l’esecuzione di codice sul server PHP?

Per capire perché PHP2Shell sia tecnicamente possibile, immaginiamo un server Linux con Apache che espone soltanto la porta TCP 80. Il client remoto può inviare richieste HTTP, ma non dispone di SSH, non conosce credenziali amministrative e non può modificare direttamente i file ospitati dal server. L’applicazione potrebbe contenere soltanto queste istruzioni:

<?php
echo "Hello World";

Lo script non utilizza $_GET, non legge $_POST, non interagisce con il filesystem e non richiama funzioni come system(), exec() o eval().

In condizioni normali, una richiesta HTTP diretta alla pagina restituisce semplicemente la stringa Hello World. Non esiste alcuna funzionalità applicativa che permetta di impartire comandi al sistema operativo.

Perché PHP2Shell può non toccare il codice applicativo

PHP2Shell, però, non deve per forza sfruttare il codice dell’applicazione: può colpire le operazioni che il motore PHP svolge per preparare l’ambiente di esecuzione, prima ancora di raggiungere la prima istruzione dello script.

Quando un server Web riceve una richiesta destinata a un’applicazione PHP, l’interprete deve elaborare diversi elementi controllabili dal client: parametri HTTP, intestazioni, contenuti POST, dati multipart ed eventuali upload. Per farlo costruisce e modifica strutture interne, utilizzando codice nativo scritto prevalentemente in C.

Il runtime PHP deve quindi elaborare dati provenienti da una fonte non attendibile, anche se l’applicazione non intende utilizzare esplicitamente quei dati.

Prendiamo una richiesta POST con corpo application/x-www-form-urlencoded: prima che lo script possa utilizzare i parametri ricevuti, PHP esegue il parsing del corpo della richiesta e prepara le strutture associate a $_POST. La gestione di queste strutture richiede allocazioni di memoria, inizializzazione di variabili, inserimenti nelle tabelle hash e successive operazioni di liberazione delle risorse.

Se una delle routine coinvolte contiene un errore di gestione della memoria, i dati controllati dal client possono provocare un comportamento anomalo nell’interprete stesso.

L’attaccante non chiede quindi a PHP di interpretare direttamente un comando come codice applicativo: cerca di alterare il flusso di esecuzione del programma nativo che implementa PHP.

Perché non serve esporre PHP-FPM direttamente su Internet

Lo stesso principio aiuta a chiarire un dubbio frequente sulle installazioni che utilizzano Nginx e PHP-FPM.

In una configurazione ordinaria, Nginx espone le porte HTTP e/o HTTPS, mentre PHP-FPM riceve le richieste attraverso un socket Unix oppure una connessione FastCGI locale. La porta utilizzata internamente da PHP-FPM non deve essere accessibile dalla rete pubblica.

Quando un utente richiede una pagina PHP, Nginx trasferisce comunque al runtime le informazioni necessarie per elaborarla. Se il percorso di gestione della richiesta contiene una vulnerabilità raggiungibile attraverso quei dati, l’aggressore può tentare di sfruttarla attraverso il normale server Web.

L’assenza di un servizio FastCGI pubblico elimina una superficie di attacco diretta, ma – come abbiamo spiegato appena poco fa – non impedisce lo sfruttamento di vulnerabilità presenti nel motore PHP durante l’elaborazione delle richieste inoltrate dal server Web.

Una catena funzionante su Apache con mod_php (questa è stata dimostrata, come abbiamo visto negli altri nostri articoli e come ricordiamo di seguito) non è automaticamente trasferibile a PHP-FPM, perché cambiano la gestione dei processi, il ciclo di vita delle richieste e la disposizione della memoria.

La prova di Datadog: PHP esegue un comando prima di avviare lo script

Una delle dimostrazioni più significative arriva da Datadog Security Labs, che ha pubblicato un’analisi tecnica della falla di PHP CVE-2026-109618. I ricercatori hanno riprodotto una catena RCE utilizzando PHP 8.5.11 e Apache con mod_php. L’attacco parte da una richiesta HTTP POST non autenticata e raggiunge un percorso vulnerabile durante la preparazione dei dati della richiesta.

Il dettaglio decisivo è che l’esecuzione del comando avviene prima dell’avvio del codice applicativo: non servono una pagina PHP predisposta per l’attacco, una funzione di upload vulnerabile oppure una LFI.

Datadog ha ricostruito il problema esaminando le operazioni dello Zend Engine durante l’inserimento di elementi nelle tabelle hash. Una delle routine coinvolte è _zend_hash_str_add_or_update_i(), utilizzata per aggiungere o aggiornare elementi identificati da chiavi stringa. La vulnerabilità nasce da una sequenza di operazioni nella quale alcuni metadati della struttura possono essere aggiornati prima che il nuovo elemento sia stato completamente inizializzato.

In particolare, una condizione di memoria esaurita, indicata come Out Of Memory (OOM), può interrompere l’operazione nel momento sbagliato.

La dimostrazione di Datadog chiarisce anche perché molti PoC diffusi pubblicamente grattino (ancora) soltanto la superficie.

Provocare un errore del tipo Allowed memory size exhausted non dimostra che il server possa essere compromesso attraverso quella particolare richiesta. L’errore indica soltanto che PHP ha raggiunto un limite di memoria. Per trasformare la condizione OOM in una RCE, l’attaccante deve riuscire a far coincidere diversi eventi: il fallimento dell’allocazione nel punto vulnerabile, la presenza di dati riutilizzabili nella memoria, l’interpretazione anomala di tali dati e la deviazione del flusso verso una funzione utilizzabile.

La riuscita dipende quindi non soltanto dal numero di versione di PHP, ma anche dal comportamento dell’allocatore, dalla configurazione dei processi e dalle difese presenti sul sistema.

ASLR, indirizzi di memoria e perché un exploit PHP2Shell è difficile da generalizzare

Un ostacolo importante alla realizzazione di exploit affidabili è rappresentato da ASLR (Address Space Layout Randomization), la protezione che rende meno prevedibili gli indirizzi di memoria utilizzati dai processi. Per dirottare una chiamata verso una funzione della libreria C, l’attaccante deve poter individuare un indirizzo utilizzabile. Se la posizione delle librerie e delle strutture varia tra le esecuzioni, costruire un payload statico diventa molto più complicato.

ASLR può certamente rendere un exploit più complesso, ma non costituisce una garanzia contro PHP2Shell.

Allo stesso tempo, la necessità di ottenere indirizzi utilizzabili spiega perché un PoC capace di provocare un crash non debba essere automaticamente considerato una dimostrazione di RCE.

La seconda vulnerabilità PHP2Shell: quando una richiesta influenza quella successiva

La CVE-2026-109619 riguarda un altro problema di gestione della memoria: la persistenza di riferimenti a dati appartenenti a richieste precedenti.

I tecnici di Wiz Research hanno dichiarato di aver realizzato catene di attacco capaci di ottenere RCE senza autenticazione su WordPress, Drupal e Joomla, utilizzando immagini Docker ufficiali disponibili al momento delle verifiche. Wiz non ha dovuto introdurre deliberatamente una vulnerabilità LFI nel codice dei CMS per dimostrare l’esecuzione di codice.

I ricercatori spiegano inoltre che l’attacco può interessare anche applicazioni semplici, perché alcune primitive vulnerabili vengono raggiunte durante l’inizializzazione o la gestione interna delle richieste, indipendentemente dalla logica implementata dallo sviluppatore.

La ricerca comprende diverse tecniche: corruzione della memoria durante la gestione degli upload, informazioni residue provenienti da richieste precedenti, problemi nella gestione dei backtrace degli errori e anomalie relative allo stato interno. Combinando queste primitive, Wiz ha ottenuto risultati che vanno oltre un semplice crash del processo PHP.

Lo sviluppo degli exploit ha però richiesto test ripetuti, concatenazione di più vulnerabilità e adattamenti alla disposizione della memoria dei singoli bersagli.

Le prove contro WordPress, Drupal e Joomla svolte da Wiz dimostrano quindi che PHP2Shell può raggiungere applicazioni reali senza dipendere da errori del codice applicativo; non dimostrano l’esistenza (per il momento) di un singolo payload capace di compromettere ogni server PHP indipendentemente dalla configurazione.

Quali PoC PHP2Shell sono realmente credibili?

Valutare un exploit pubblico richiede più attenzione di quanto suggerisca il numero di stelle ricevute su GitHub o la presenza di una schermata che mostra una shell remota.

Il primo elemento da verificare è l’ambiente bersaglio. Un PoC dovrebbe documentare la versione di PHP, il sistema operativo, la modalità di esecuzione dell’interprete e le modifiche introdotte rispetto alle impostazioni predefinite.

Il secondo elemento è il risultato effettivamente ottenuto. Un codice che provoca un errore di memoria, un HTTP 500 o il riavvio di un worker può dimostrare il raggiungimento di un percorso vulnerabile, ma non necessariamente l’esecuzione di comandi arbitrari.

Il terzo elemento riguarda le dipendenze dell’attacco. Se la dimostrazione richiede una LFI, una funzione applicativa insicura o la disabilitazione di protezioni fondamentali, il risultato non può essere presentato come una RCE indipendente dalla configurazione.

Esiste un exploit pubblico PHP2Shell che funziona su qualunque installazione standard?

Alla data odierna, dalle verifiche che abbiamo svolto, non emerge un exploit pubblico, indipendentemente validato, capace di ottenere RCE in maniera generalizzata contro qualunque installazione vulnerabile di PHP, senza prerequisiti o adattamenti al sistema bersaglio.

Non aver individuato un exploit universale non significa che non esistano exploit funzionanti su installazioni ordinarie. Wiz ha documentato RCE contro applicazioni reali e Datadog ha fornito una spiegazione dettagliata di una catena che permette di eseguire un comando prima dell’avvio del codice applicativo.

Lo stesso PHP Security Team, nel proprio advisory ufficiale del 21 ottobre, identifica Apache con mod_php come la configurazione maggiormente esposta e conferma l’esistenza di un exploit dimostrato che può intervenire prima dell’esecuzione dello script PHP.

Al tempo stesso, una determinata combinazione di sistema operativo, versione del runtime, impostazioni e protezioni della memoria può richiedere un percorso di attacco differente.

PHP2Shell e AI: tra exploit reali e codice ingannevole

Il ruolo dell’intelligenza artificiale rende PHP2Shell ancora più interessante dal punto di vista della ricerca sulla sicurezza.

Wiz attribuisce ai modelli AI un contributo importante nella scoperta e nell’analisi delle vulnerabilità, nella costruzione delle catene di sfruttamento e nella verifica delle correzioni. I modelli possono aiutare i ricercatori a esaminare grandi quantità di codice, riconoscere anomalie nella gestione degli errori e individuare combinazioni di comportamenti che sarebbero difficili da studiare manualmente.

Nel caso di PHP2Shell, Wiz sostiene che l’assistenza dei modelli più avanzati abbia ridotto significativamente il lavoro necessario per sviluppare e adattare exploit complessi.

L’altra faccia della medaglia è la proliferazione di PoC generati automaticamente e privi di verifica sperimentale. Un modello può produrre uno script Python apparentemente convincente, accompagnato da spiegazioni sulle CVE e da una sequenza di richieste HTTP, senza che lo script riesca effettivamente a ottenere RCE.

La critica di Elias Taylor riguarda proprio la distanza tra la sicurezza con cui alcuni strumenti dichiarano di avere costruito un exploit e la sua effettiva riproducibilità. L’AI può di certo contribuire alla scoperta di exploit autentici, ma non sostituisce la verifica del comportamento del programma bersaglio.

Gli attacchi PHP2Shell sono già comparsi su Internet?

Il 21 ottobre, Amazon Threat Intelligence ha riferito di avere osservato tentativi di sfruttamento riconducibili a PHP2Shell attraverso la propria infrastruttura di honeypot MadPot. Secondo AWS, alcune attività risalgono al 17 ottobre 2026, 4 giorni prima della divulgazione pubblica delle vulnerabilità.

Il dato indica che soggetti esterni stavano già sperimentando tecniche d’attacco contro le falle prima della pubblicazione degli aggiornamenti.

Un conto, però, è la rilevazione di un tentativo di aggressione, un altro la conferma di una compromissione riuscita.

La presa di posizione di AWS resta comunque rilevante, perché conferma l’interesse degli attaccanti e riduce ulteriormente la ragionevolezza di un atteggiamento attendista.

Anche Cloudflare ha predisposto protezioni WAF dedicate a PHP2Shell, distribuendo contromisure prima della divulgazione pubblica nell’ambito delle attività coordinate di sicurezza. Le protezioni a livello di rete possono intercettare specifiche richieste malevole e ridurre l’esposizione, ma non costituiscono una sostituzione permanente delle correzioni del motore PHP.

PHP2Shell è una minaccia reale o soltanto fuffa?

Le evidenze disponibili permettono di arrivare a una conclusione netta: PHP2Shell non è certo una vulnerabilità “inventata” e non rappresenta soltanto un rischio teorico.

Il team PHP ha confermato le falle e pubblicato aggiornamenti straordinari. Datadog ha documentato una catena capace di trasformare una richiesta POST non autenticata nell’esecuzione di un comando durante la pulizia della memoria; Wiz ha dimostrato RCE contro applicazioni diffuse senza dover introdurre deliberatamente errori nel codice dei CMS.

La parte meno convincente della vicenda riguarda invece la quantità di exploit pubblici presentati come strumenti pronti all’uso.

Un server PHP vulnerabile può eseguire codice arbitrario attraverso HTTP: sappiamo già che è possibile. L’interrogativo principale riguarda quanto rapidamente gli exploit potranno diventare affidabili, portabili e utilizzabili contro un numero elevato di installazioni reali.

Gli amministratori, tuttavia, non dovrebbero fare particolari distinguo: aggiornare PHP rimane necessario. Attendere la comparsa di un exploit universale prima di applicare le correzioni significherebbe affidare la sicurezza del server alla difficoltà tecnica che gli attaccanti incontrano oggi, senza alcuna garanzia che la stessa difficoltà esista anche domani.