In questo articolo Indice dei contenuti 2 sezioni
Le due vulnerabilità critiche ribattezzate PHP2Shell hanno messo sul tavolo una domanda che inquieta chiunque gestisca un server PHP, ovvero se un aggressore possa davvero eseguire comandi arbitrari limitandosi a inviare richieste HTTP sulla porta 80 o 8080. Il tutto senza conoscere le credenziali di accesso e senza approfittare di errori presenti nell’applicazione Web. Attorno a questo interrogativo è cresciuta in fretta una vera ondata di exploit pubblici che promettono di compromettere con estrema facilità qualunque installazione vulnerabile.
Le cose però sono un po’ più complicate di come vengono raccontate. Molti dei Proof of Concept comparsi su GitHub non funzionano affatto con un’installazione tipica di PHP. Alcuni danno per scontato l’uso di configurazioni palesemente insicure, altri si appoggiano a una seconda vulnerabilità e altri ancora si limitano a dimostrare che è possibile mandare in crash il sistema.
Allo stesso tempo gruppi di ricerca come Wiz Research e Datadog hanno documentato attacchi in grado di ottenere davvero l’esecuzione di codice da remoto, cioè la cosiddetta RCE, anche quando il codice dell’applicazione PHP non contiene difetti sfruttabili. Il dubbio quindi è legittimo. PHP2Shell rappresenta una minaccia concreta oppure si tratta di allarmismo gonfiato da exploit generati con l’intelligenza artificiale? Per orientarsi conviene separare i risultati verificati dalle affermazioni prive di prove e capire come il contenuto di una banale richiesta possa arrivare ad alterare il comportamento dell’interprete PHP.
Gli exploit che non funzionano e le ragioni dello scetticismo
Il 21 ottobre 2026, poco dopo il rilascio degli aggiornamenti di sicurezza, lo sviluppatore Elias Taylor ha espresso una critica ben argomentata sulla reale sfruttabilità di PHP2Shell. Il punto di partenza è semplice. Nonostante la comparsa di numerosi repository che garantiscono exploit funzionanti, al momento non risulta possibile arrivare alla compromissione di un’installazione PHP standard.
Taylor non mette in discussione l’esistenza delle falle e non invita certo a trascurare gli aggiornamenti. La sua tesi è un’altra, e cioè che la complessità necessaria per trasformare i difetti scoperti nell’interprete in una RCE affidabile sia stata ampiamente sottovalutata.
Il paragone con Log4Shell viene spontaneo ma regge poco. Nel 2021 alcune configurazioni vulnerabili della libreria Java Log4j potevano essere attaccate tramite stringhe costruite ad arte che finivano nel sistema di logging. Le prime dimostrazioni pubbliche consentirono di comprendere e riprodurre il problema in tempi rapidissimi, fino alla documentazione del celebre attacco. Con PHP2Shell, malgrado l’assonanza nel nome, lo scenario cambia parecchio. Non basta infilare una stringa speciale in un parametro HTTP per costringere PHP a lanciare un comando. Le vulnerabilità riguardano la gestione della memoria nativa dell’interprete e mettere in piedi un attacco completo significa influenzare le allocazioni, aggirare alcune protezioni e innescare una sequenza di operazioni molto precisa.
C’è poi un problema che ricorre spesso nei PoC pubblici, ovvero la dipendenza da una Local File Inclusion. Si tratta di una vulnerabilità applicativa che permette all’attaccante di includere un file locale a sua scelta. Altri progetti intervengono sulle impostazioni delle sessioni PHP oppure sfruttano applicazioni già vulnerabili di loro. Se per arrivare all’esecuzione remota di codice occorre prima introdurre un errore di programmazione nell’applicazione, la dimostrazione non riflette le condizioni normali di un ambiente di produzione. Questo però non significa che le debolezze sottostanti siano soltanto teoriche, perché l’inaffidabilità diffusa di tanti exploit è una questione ben diversa dalla pericolosità dei bug.
Come una richiesta HTTP può arrivare a toccare il server
Per capire perché un attacco basato su PHP2Shell sia tecnicamente possibile si può immaginare un server Linux con Apache che espone soltanto la porta TCP 80. Il client remoto è in grado di inviare richieste HTTP ma non ha accesso SSH, non conosce alcuna credenziale amministrativa e non può modificare direttamente i file ospitati sulla macchina. L’applicazione in esecuzione, in questo scenario, potrebbe contenere appena poche istruzioni elementari.
Fonte: TecnoAndroid