Impatto Sistemico

Alto (65.64)

Sintesi

Aggiornamenti di sicurezza sanano 2 nuove vulnerabilità con gravità “critica” in PHP, noto interprete del linguaggio di scripting per lo sviluppo web. Tali vulnerabilità interessano la componente php-src e, qualora sfruttate, potrebbero permettere a un utente malintenzionato remoto di eseguire codice arbitrario sui sistemi interessati.

Tipologia

• Remote Code Execution

Descrizione e potenziali impatti

La vulnerabilità identificata dalla CVE-2026-109618 – di tipo “Use After Free” e con score CVSS v4.0 pari a 9,2 – è dovuta a una gestione non adeguata delle condizioni di esaurimento della memoria (out-of-memory), nelle quali PHP utilizza la funzione longjmp() per interrompere l’elaborazione delle richieste. Tale comportamento può lasciare alcune strutture interne in uno stato non valido, qualora l’interruzione avvenga prima del completamento della loro inizializzazione. Un attaccante remoto non autenticato, tramite richieste opportunamente predisposte – ad esempio sfruttando la gestione delle richieste multipart – potrebbe provocare una condizione di esaurimento della memoria e determinare una corruzione della stessa, con conseguente possibilità di eseguire codice arbitrario con i privilegi del processo worker PHP sui sistemi target.

La vulnerabilità identificata dalla CVE-2026-109619 – di tipo “Use After Free” e con score CVSS v4.0 pari a 9,2 – è dovuta a una gestione non adeguata dello stato globale interno di PHP che, in seguito a errori critici, timeout, condizioni di esaurimento della memoria o determinate operazioni diagnostiche, potrebbe mantenere riferimenti a memoria già liberata. Un attaccante remoto non autenticato, tramite una sequenza di richieste opportunamente predisposte e gestite dallo stesso processo worker, potrebbe provocare l’utilizzo di tali riferimenti durante l’elaborazione di richieste successive, ad esempio attraverso i meccanismi di monitoraggio dell’avanzamento degli upload di sessione o la gestione delle impostazioni di configurazione. Tra le condizioni che possono determinare la persistenza dello stato obsoleto rientra anche la generazione dei backtrace degli errori fatali in PHP 8.5. Lo sfruttamento della vulnerabilità potrebbe consentire l’esecuzione di codice arbitrario con i privilegi del processo worker PHP sui sistemi target.

Prodotti e versioni affette

PHP

• 8.5.x, versioni precedenti alla 8.5.12
• 8.4.x, versioni precedenti alla 8.4.27
• 8.3.x, versioni precedenti alla 8.3.36
• 8.2.x, versioni precedenti alla 8.2.35

Azioni di mitigazione

Si raccomanda di aggiornare i prodotti vulnerabili seguendo le indicazioni dei bollettini di sicurezza riportati nella sezione Riferimenti.

Si evidenzia che per tutte le versioni di PHP 8.1 e precedenti il vendor non rilascerà alcun workaround e/o patch considerata la data di fine supporto (EOL)

Qualora non fosse possibile aggiornare tempestivamente le istanze vulnerabili, si riportano di seguito le misure di mitigazione suggerite dal vendor:

• CVE-2026-109618 : configurare memory_limit=-1 a livello amministrativo, limitare post_max_size a 8 MB senza upload o a 32 MB quando gli upload sono necessari, mantenere upload_max_filesize inferiore a post_max_size. Valutare l’applicazione, a livello di web server o proxy, di limiti relativi alla dimensione decodificata delle richieste, al numero di campi di input, di parti multipart e di intestazioni, nonché alla profondità di annidamento. Tali limiti devono essere applicati anche alle richieste prive di un valore Content-Length utilizzabile.
• CVE-2026-109619 : impostare session.upload_progress.enabled=0 e riavviare tutti i worker. Applicare la configurazione tramite php.ini, un pool FPM o una configurazione del server che venga caricata prima dell’elaborazione delle richieste. Su PHP 8.5, impostare fatal_error_backtraces=0 e riavviare tutti i worker. Rimuovere le impostazioni non valide o deprecate applicate a livello di singola richiesta che generano messaggi diagnostici prima dell’inizializzazione. Nascondere tali messaggi tramite error_reporting , display_errors o l’operatore @ non costituisce una mitigazione efficace. Correggere gli errori fatali e i timeout di esecuzione raggiungibili da un attaccante, comprese le anomalie nei callback e nelle operazioni di caricamento, importazione e pulizia.