In questo articolo Indice dei contenuti 2 sezioni
Il bypass di ASLR messo a segno da PHP2Shell cambia parecchio le carte in tavola per chi gestisce server web. I ricercatori di VulnCheck hanno dimostrato che una delle due vulnerabilità critiche scoperte di recente in PHP può essere sfruttata anche su macchine x8664 con ASLR (Address Space Layout Randomization) attivo. E non è tutto, perché l’attacco va a segno pure con la visualizzazione degli errori disattivata, cioè nella configurazione tipica dei sistemi in produzione. Per milioni di installazioni esposte su Internet la valutazione del rischio diventa quindi decisamente diversa.
Le due falle, entrambe con un punteggio CVSS 4.0 di 9,2, sono emerse pubblicamente il 20 ottobre 2026, quando alcune informazioni hanno anticipato le correzioni ufficiali. Il giorno dopo il team di PHP ha distribuito quattro aggiornamenti di sicurezza, ma nel frattempo i ricercatori avevano già cominciato a studiare come trasformare quei difetti dell’interprete in attacchi capaci di eseguire codice da remoto senza autenticazione. VulnCheck ha annunciato un exploit funzionante su PHP dalla versione 8.4.10 alla 8.4.26 senza bisogno di adattamenti tra una release e l’altra. Il meccanismo unisce una perdita di informazioni dalla memoria a una successiva fase di Remote Code Execution.
Come PHP2Shell riesce ad aggirare ASLR
Per capire la portata della scoperta conviene ricordare a cosa serve ASLR. Introdotta gradualmente nei principali sistemi operativi dai primi anni 2000, questa tecnologia rimescola la disposizione delle aree di memoria usate dai processi e rende meno prevedibile la posizione del codice eseguibile, delle librerie condivise e dello stack. Senza randomizzazione chi conosce versione del software e configurazione del sistema può spesso indovinare dove si trovano certi dati e sfruttare con più facilità una corruzione della memoria. Con la protezione attiva gli indirizzi cambiano a ogni esecuzione e l’aggressore deve prima trovare un modo per scoprirli.
Ed è proprio qui che entra in gioco il memory leak. L’exploit sfrutta una lettura fuori dai limiti della memoria per recuperare gli indirizzi dell’heap e della libreria PHP, annullando di fatto l’incertezza introdotta dalla randomizzazione. Poi arriva la seconda fase. Richieste HTTP multipart provocano un esaurimento della memoria durante la gestione delle sessioni e lasciano in giro riferimenti a memoria non più valida, i cosiddetti dangling pointers, che servono poi ad alterare le strutture interne dell’interprete. Ottenuti gli indirizzi necessari, la prova di concetto pubblicata dal ricercatore 9bie manipola una struttura zendarray e il relativo puntatore pDestructor, spingendo il runtime a richiamare una funzione al momento della distruzione della struttura.
I test sono stati condotti con PHP 8.4.26, Apache e mod_php, visualizzazione degli errori spenta, limite di memoria a 128M e 150 worker Apache. Il risultato dichiarato parla di 10 tentativi riusciti su 10, con esecuzione di codice in circa 3 o 4 secondi. La dimostrazione riguarda comunque una specifica build e non garantisce lo stesso esito su altre versioni senza modifiche.
Aggiornare resta l’unica vera difesa
Questo non vuol dire che ASLR sia diventato inutile. Semplicemente una falla capace di rivelare informazioni dalla memoria ne riduce l’efficacia e rende fattibili attacchi altrimenti molto più complessi. La raccomandazione principale è passare a PHP 8.5.12, 8.4.27, 8.3.36 oppure 8.2.35, versioni pubblicate il 21 ottobre 2026 e disponibili tramite i canali ufficiali e i repository delle distribuzioni. Chi non può applicare subito le patch può ricorrere ad alcune misure temporanee, come impostare il limite di memoria a meno uno in una configurazione non modificabile dalle applicazioni, ridurre le dimensioni delle richieste POST e controllare gli upload a livello di web server o reverse proxy. Per la seconda vulnerabilità il progetto consiglia anche di disattivare il monitoraggio dell’avanzamento degli upload nelle sessioni e riavviare tutti i processi coinvolti. Il 23 ottobre è stato poi segnalato un ulteriore caso legato proprio a questa funzionalità. Nessuno di questi accorgimenti offre però una protezione completa e lo stesso team PHP ribadisce che aggiornare l’interprete è l’unica soluzione definitiva.
Anche i numeri raccontano molto. VulnCheck ha individuato PHP su 2.608.039 host raggiungibili da Internet, quasi 1,5 milioni dei quali dichiarano una versione precedente a quelle corrette, mentre altri 1,1 milioni non espongono abbastanza dettagli per stabilirlo. Si tratta di una stima, dato che le distribuzioni Linux possono integrare correzioni tramite backport senza cambiare il numero di versione. Più di 1,1 milioni di host, poi, girano su rami che non ricevono più supporto ufficiale. Intanto i sensori della società hanno già intercettato i primi tentativi di sfruttamento di PHP2Shell, con richieste HTTP POST multipart dirette a file come index.php e User Agent riconoscibili, pensate per sollecitare i meccanismi che gestiscono il caricamento dei file prima ancora dell’esecuzione del codice applicativo.
Fonte: TecnoAndroid