PHP2Shell supera anche ASLR: con il bypass cade una delle principali difese dei server

Una delle principali protezioni utilizzate dai sistemi operativi moderni per ostacolare gli attacchi alla memoria non è più sufficiente a fermare PHP2Shell. I ricercatori di VulnCheck hanno dimostrato che è possibile sfruttare una delle due vulnerabilità critiche recentemente scoperte in PHP anche sui server x86-64 con ASLR (Address Space Layout Randomization) attivo. Non solo: l’exploit funziona con la visualizzazione degli errori disabilitata, come normalmente avviene nelle configurazioni di produzione.

La scoperta cambia quindi sensibilmente la valutazione del rischio per milioni di installazioni PHP esposte su Internet.

Le vulnerabilità CVE-2026-109618 e CVE-2026-109619, entrambe classificate con un punteggio CVSS 4.0 di 9,2, sono emerse pubblicamente il 20 ottobre 2026, quando alcune informazioni hanno anticipato il rilascio delle correzioni ufficiali. Il giorno successivo, il team PHP ha pubblicato quattro aggiornamenti di sicurezza. Nel frattempo, però, i ricercatori hanno iniziato a studiare come trasformare i difetti individuati nell’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 necessità di adattamenti tra le diverse release. L’attacco combina una perdita di informazioni dalla memoria con una successiva fase di Remote Code Execution (RCE). Il risultato dimostra che alcune difese considerate importanti per limitare lo sfruttamento dei problemi di corruzione della memoria possono rivelarsi insufficienti quando l’aggressore riesce a concatenare più primitive di attacco.

Cos’è ASLR e perché protegge i server dagli attacchi informatici

Introdotta progressivamente nei principali sistemi operativi a partire dai primi anni 2000, la tecnologia ASLR modifica la disposizione delle aree di memoria utilizzate dai processi, rendendo meno prevedibile la posizione del codice eseguibile, delle librerie condivise, dello stack e di altre strutture.

Un programma, durante l’esecuzione, utilizza indirizzi virtuali per accedere alle proprie istruzioni e ai dati. In assenza di randomizzazione, un aggressore che conosce la versione del software e la configurazione del sistema può spesso prevedere dove si trovino determinate informazioni. Una vulnerabilità di corruzione della memoria diventa così più semplice da sfruttare per alterare il flusso di esecuzione.

Con ASLR attivo, invece, gli indirizzi cambiano tra differenti esecuzioni del processo: l’aggressore non può necessariamente riutilizzare posizioni conosciute in precedenza e deve trovare un modo per individuare quelle effettivamente assegnate dal sistema operativo.

Su Linux, ad esempio, il parametro kernel.randomize_va_space controlla il comportamento della randomizzazione. Il valore 2 abilita la modalità più completa normalmente disponibile, mentre 0 la disattiva. La protezione opera a livello di processo e non dipende direttamente dal linguaggio utilizzato dall’applicazione.

Come PHP2Shell riesce ad aggirare ASLR

La novità consiste nel fatto che i ricercatori di VulnCheck sono riusciti a realizzare un exploit per CVE-2026-109618 che sfrutta una perdita di informazioni dalla memoria (memory leak) per ottenere dati utili a superare l’incertezza introdotta dalla randomizzazione degli indirizzi con ASLR.

Se una vulnerabilità consente di ottenere informazioni sugli indirizzi effettivamente utilizzati dal processo, una parte del vantaggio offerto dalla randomizzazione può scomparire.

Quando l’aggressore combina tale capacità con un secondo difetto che permette di alterare le strutture interne del processo, può costruire una catena di sfruttamento molto più efficace rispetto all’utilizzo isolato della corruzione della memoria.

VulnCheck descrive proprio una concatenazione tra memory leak e successiva RCE:  l’exploit supera ASLR su x86-64 e funziona anche quando PHP utilizza la configurazione display_errors=off, normalmente raccomandata sui server accessibili da Internet.

Un exploit che funziona su più versioni di PHP senza modifiche

Abbiamo analizzato il PoC aggiornato di PHP2Shell pubblicato dal ricercatore 9bie, che documenta una tecnica per ottenere l’esecuzione remota di codice anche con ASLR attivo, senza sfruttare vulnerabilità nel codice dell’applicazione Web. Gli aspetti tecnici più interessanti sono:

• Aggiramento di ASLR: l’exploit sfrutta una lettura fuori dai limiti della memoria (out-of-bounds read) per recuperare indirizzi dell’heap e della libreria PHP, superando la randomizzazione.
• Manipolazione della memoria: richieste HTTP multipart provocano una condizione di out-of-memory durante la gestione delle sessioni, lasciando riferimenti a memoria non più valida (dangling pointers). L’attacco sfrutta successivamente tali riferimenti per alterare strutture interne di PHP.
• Esecuzione del codice: dopo aver ricavato gli indirizzi necessari, il PoC manipola una struttura zend_array e il relativo puntatore pDestructor, inducendo il runtime a richiamare una funzione durante la distruzione della struttura.
• Configurazione di produzione: funziona nei test con PHP 8.4.26, Apache e mod_php, display_errors=Off, memory_limit=128M e 150 worker Apache. L’autore documenta una tecnica per mantenere le richieste coinvolte nello stesso processo.
• Risultati: il ricercatore dichiara 10 tentativi riusciti su 10, con esecuzione di codice come utente www-data in circa 3-4 secondi.

La dimostrazione riguarda una specifica build di PHP 8.4.26 e non garantisce che l’exploit funzioni senza adattamenti su altre versioni. Il dato significativo è che ASLR rimane attivo, ma il memory leak consente di neutralizzarne l’efficacia, rendendo possibile la compromissione del processo PHP anche con impostazioni normalmente raccomandate per la produzione.

Come difendersi da PHP2Shell: ASLR non basta, servono gli aggiornamenti

La scoperta di VulnCheck non significa che ASLR sia inutile o che la protezione abbia smesso di funzionare. Dimostra piuttosto che una vulnerabilità capace di rivelare informazioni dalla memoria può ridurne l’efficacia di una misura protettiva storica, consentendo di portare a termine attacchi che altrimenti risulterebbero più complessi.

La raccomandazione principale resta quella di aggiornare PHP alle versioni 8.5.12, 8.4.27, 8.3.36 oppure 8.2.35, tutte pubblicate il 21 ottobre 2026. I pacchetti sono disponibili attraverso i canali ufficiali PHP e i repository delle distribuzioni.

Per le installazioni che non possono ricevere immediatamente le patch, gli sviluppatori suggeriscono alcune misure temporanee:

1. Impostare memory_limit=-1 mediante una configurazione che le applicazioni non possano modificare elimina uno specifico percorso di errore legato al limite PHP, senza impedire l’effettivo esaurimento della memoria disponibile.
2. Limitare le dimensioni delle richieste POST, controllare gli upload e applicare restrizioni a livello di Web server o reverse proxy. Per CVE-2026-109619, il progetto raccomanda di disabilitare session.upload_progress.enabled e riavviare tutti i processi PHP interessati. Su PHP 8.5, anche fatal_error_backtraces=0 riduce uno dei percorsi di attacco documentati.
3. Il 23 ottobre il team PHP ha inoltre segnalato un ulteriore caso particolare, identificato come CVE-2026-115560, che coinvolge il monitoraggio dell’avanzamento degli upload e modifiche a runtime del gestore di serializzazione delle sessioni. La raccomandazione prudenziale è mantenere disabilitata tale funzionalità fino alla successiva correzione, quando non risulti necessaria.

Nessuna di queste misure temporanee garantisce una protezione completa: lo stesso team PHP precisa che l’aggiornamento dell’interprete è l’unica soluzione definitiva.

Milioni di server potenzialmente vulnerabili, mentre iniziano gli attacchi

Le misurazioni di VulnCheck identificano PHP su 2.608.039 host raggiungibili da Internet: di questi, quasi 1,5 milioni dichiarano una versione precedente a quelle corrette, mentre altri 1,1 milioni non espongono informazioni sufficienti per determinarla.

La società considera quindi oltre 2,6 milioni di host vulnerabili o presumibilmente tali. È una stima, non la dimostrazione che ogni sistema possa subire un exploit funzionante. Le distribuzioni Linux, ad esempio, possono integrare correzioni di sicurezza tramite backport senza cambiare il numero di versione visualizzato.

Colpisce soprattutto il peso delle installazioni obsolete: più di 1,1 milioni di host utilizzano rami PHP che non ricevono più aggiornamenti ufficiali dal progetto.

Nel frattempo, la rete di sensori di VulnCheck ha intercettato i primi tentativi di sfruttamento di PHP2Shell. Gli aggressori hanno inviato richieste HTTP POST multipart verso file come index.php, utilizzando User-Agent riconoscibili, tra cui php2shell-scan/109618.

L’obiettivo era verificare la presenza della vulnerabilità sollecitando i meccanismi interni di PHP che gestiscono il caricamento dei file, prima ancora dell’esecuzione del codice applicativo. Proseguono, inoltre, tentativi sempre più elaborati e “creativi” per aggredire i server di mezzo mondo basati su PHP.