Sono stati pubblicati gli aggiornamenti correttivi PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, oltre a patch per le versioni non supportate PHP 7.4, PHP 8.0 e PHP 8.1 (le versioni vulnerabili da 5.4 a 7.3 rimangono senza patch), in cui sono state corrette due vulnerabilità critiche:
- CVE-2026-109618 — esecuzione remota di codice causata dal fatto che, quando si esaurisce la memoria libera disponibile per il processo, il gestore della mancanza di memoria tramite l'esecuzione della funzione longjmp() può interrompere l'interprete PHP in uno stato in cui sono state inizializzate solo alcune strutture interne legate alla gestione della richiesta. Successivamente, la funzione di completamento della richiesta fa riferimento a queste strutture come se fossero state già inizializzate, anche se non è stata allocata memoria per esse.
Il principale vettore di attacco è la manipolazione delle richieste multipart per creare condizioni che esauriscano la memoria disponibile per il processo. Per evitare il limite di post_max_size, l'intestazione Content-Length può non essere specificata e possono essere trasmessi un numero enorme di intestazioni HTTP. È possibile eseguire anche attacchi mirati su operazioni specifiche nelle applicazioni PHP che consumano eccessivamente memoria. È stata confermata la presenza di un exploit per mod_php, poiché chiama la funzione shutdown() anche in caso di errore. PHP-FPM chiude il processo figlio in caso di errore, rendendo difficile l'esecuzione dell'attacco, ma teoricamente non lo esclude.
- CVE-2026-109619 — esecuzione remota di codice causata dall'accesso alla memoria dopo la sua liberazione a causa di una pulizia inadeguata dello stato globale associato a una richiesta specifica. In caso di interruzione della richiesta a causa di un errore fatale, timeout o mancanza di memoria, lo stato globale potrebbe non essere azzerato e i puntatori rimarranno attivi, nonostante la memoria a cui fanno riferimento sia stata liberata. Durante l'elaborazione della richiesta successiva nello stesso processo, potrebbe verificarsi un accesso tramite il puntatore rimanente allo stato globale precedente.
Per l'utilizzo può essere creata una condizione di esaurimento della memoria disponibile durante l'elaborazione di una richiesta multipart nel codice per l'indicazione del progresso del caricamento (session.upload_progress). In questo caso, il principale e confermato vettore di attacco menzionato è il gestore fatal_error_backtraces in PHP 8.5, che non ripristina lo stato della traccia alla conclusione. Nel primo caso, l'attacco è possibile su mod_php e PHP-FPM, mentre nel secondo solo su mod_php. Viene inoltre menzionata la possibilità non confermata di attacchi in configurazioni che includono direttive che portano all'emissione di avvisi nelle fasi iniziali dell'elaborazione della richiesta (ad esempio, avvisi sull'uso di parametri obsoleti).
Si afferma che il completo blocco delle vulnerabilità è possibile solo tramite l'installazione di un aggiornamento. Le seguenti misure possono ridurre la probabilità di attacchi riusciti, ma non rendono il sistema completamente sicuro:
- Impostare nel php.ini il parametro «memory_limit=-1», che rende difficile per l'attaccante controllare l'esaurimento dei limiti di memoria.
- Impostare il parametro «post_max_size = 8M», se non è necessaria la caricamento di file di grandi dimensioni. Il valore del parametro «upload_max_filesize» deve essere inferiore a quello di «post_max_size».
- Impostare un limite sul consumo di memoria a livello di sistema, attraverso cgroup memory.max o parametri di consumo di memoria del contenitore, ma non tramite limiti di sistema RLIMIT_AS e RLIMIT_DATA, che provocano solo la chiamata problematica longjmp().
- Se le prestazioni non sono importanti, è possibile limitare il numero di richieste elaborate da un singolo processo di lavoro tramite pm.max_requests=1 in PHP-FPM e MaxRequestsPerChild in Apache httpd.
- Impostazione a livello di php.ini o di configurazione server non tramite ini_set() o FPM .user.ini, poiché il parametro deve essere attivo prima dell'inizio dell'elaborazione della richiesta, impostando il parametro «session.upload_progress.enabled=0».
- Quando si utilizza la versione PHP 8.5, impostare il parametro «fatal_error_backtraces=0».
- Rimuovere le impostazioni obsolete o errate associate a singole richieste (come assert.* e percorsi errati in open_basedir) che portano all'emissione di messaggi diagnostici prima dell'inizializzazione.
- Eliminare nel codice PHP situazioni che portano a timeout e errori fatali, ad esempio relativi ai fallimenti nei callback e nel caricamento dei file.
- Per bloccare la prima vulnerabilità nel codice delle vecchie versioni di PHP, è possibile sostituire la chiamata a longjmp() nel gestore della memoria esaurita con _exit().
- In aggiunta, è possibile ridurre il valore del parametro max_input_nesting_level nel php.ini e bloccare le richieste multipart, come indicato nell'anteprima.
Lo stato della risoluzione delle vulnerabilità nei vari distributivi può essere valutato su queste pagine: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Supplemento 1: Le vulnerabilità sono state identificate utilizzando modelli AI GPT‑5.6 e Gemini 4 Argon. OpenAI ha pubblicato uno strumento php2shell-checker per controllare l'esposizione alle vulnerabilità di siti web e file eseguibili locali, ma questo strumento verifica solo il numero di versione di PHP restituito dal server HTTP o dal comando "php -v", senza un'analisi approfondita.
Supplemento 2: L'autore del prototipo dell'exploit, che sfrutta la vulnerabilità causata da un doppio rilascio di memoria (double-free), ha riferito che il problema rimane non risolto nella versione PHP 8.5.12 e l'exploit continua a funzionare. In precedenza, i rappresentanti di PHP avevano dichiarato che questa vulnerabilità non era correlata ai prossimi aggiornamenti e non costituiva un problema reale. L'autore dell'exploit ha affermato che si tratta di una vulnerabilità completamente diversa.
Fonte: opennet.ru
