{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Dettagli sulle vulnerabilit\u00e0 critiche in PHP sono stati rivelati e sono stati pubblicati aggiornamenti correttivi.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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\u00e0 critiche:<\/p>\n
\n
CVE-2026-109618 \u2014 esecuzione remota di codice causata dal fatto che, quando la memoria disponibile per il processo si esaurisce, il gestore di esaurimento della memoria tramite l'esecuzione della funzione longjmp() pu\u00f2 interrompere l'interprete PHP in uno stato in cui solo parte delle strutture interne relative alla gestione della richiesta \u00e8 stata inizializzata. In seguito, la funzione di completamento della richiesta accede a queste strutture come se fossero gi\u00e0 state inizializzate, anche se la memoria per esse non \u00e8 stata allocata.\n
Il principale vettore di attacco \u00e8 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\u00f2 non essere specificata e possono essere trasmessi un numero enorme di intestazioni HTTP. \u00c8 possibile eseguire anche attacchi mirati su operazioni specifiche nelle applicazioni PHP che consumano eccessivamente memoria. \u00c8 stata confermata la presenza di un exploit per mod_php, poich\u00e9 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. <\/p>\n
CVE-2026-109619 \u2014 esecuzione remota di codice causata dall'accesso alla memoria dopo che \u00e8 stata liberata a causa della pulizia inadeguata dello stato globale legato a una richiesta specifica. Nel caso di interruzione della richiesta dovuta a un errore fatale, timeout o esaurimento della memoria, lo stato globale potrebbe non essere azzerato e i puntatori rimarranno attivi, nonostante la liberazione della memoria a cui si riferiscono. Durante l'elaborazione della richiesta successiva nello stesso processo, pu\u00f2 verificarsi un accesso tramite il puntatore rimasto a uno stato globale obsoleto.\n
Per l'utilizzo pu\u00f2 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 \u00e8 il gestore fatal_error_backtraces in PHP 8.5, che non ripristina lo stato della traccia alla conclusione. Nel primo caso, l'attacco \u00e8 possibile su mod_php e PHP-FPM, mentre nel secondo solo su mod_php. Viene inoltre menzionata la possibilit\u00e0 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).<\/p>\n<\/ul>\n
Si afferma che il completo blocco delle vulnerabilit\u00e0 \u00e8 possibile solo tramite l'installazione di un aggiornamento. Le seguenti misure possono ridurre la probabilit\u00e0 di attacchi riusciti, ma non rendono il sistema completamente sicuro:<\/p>\n
\n
Impostare nel php.ini il parametro \u00abmemory_limit=-1\u00bb, il che rende difficile per un aggressore controllare l'esaurimento dei limiti di memoria.\n
Impostare il parametro \u00abpost_max_size = 8M\u00bb se non \u00e8 necessario caricare file di grandi dimensioni. Il valore del parametro \u00abupload_max_filesize\u00bb deve essere inferiore al parametro \u00abpost_max_size\u00bb.\n
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().\n
Se le prestazioni non sono importanti, \u00e8 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.\n