Vulnerabilità critiche in PHP e Node.js, le correzioni del 21 ottobre

Il 21 ottobre 2026 sono stati pubblicati due bollettini di sicurezza distinti: uno per PHP, l'altro per Node.js. Entrambi riguardano vulnerabilità che possono permettere l'esecuzione di codice da remoto, cioè la possibilità per un attaccante di eseguire comandi su un sistema senza bisogno di credenziali.

Per PHP sono state segnalate due falle, CVE-2026-109618 e CVE-2026-109619. La prima riguarda la gestione della memoria quando le risorse del sistema si esauriscono: alcuni dati della richiesta possono restare inizializzati solo in parte e venire comunque trattati come validi durante la pulizia. Il problema è stato dimostrato su configurazioni con Apache e mod_php, e può manifestarsi prima che l'applicazione controlli le credenziali dell'utente. Anche PHP-FPM è considerato a rischio, anche se per questa variante non esiste ancora una dimostrazione completa dell'attacco. La seconda falla riguarda dati interni che un processo PHP può conservare dopo aver liberato la memoria di una richiesta precedente: una richiesta successiva può finire per accedere a quei riferimenti non più validi.

Per Node.js il bollettino segnala CVE-2026-111497, una falla ad alta gravità nel decoder del formato di compressione Brotli, usato anche nel traffico dei siti web. Anche in questo caso la vulnerabilità può portare all'esecuzione di codice da remoto, sebbene il rischio concreto dipenda da come l'applicazione elabora i dati compressi che riceve. Lo stesso aggiornamento di Node.js corregge anche problemi legati al DNS e alla verifica dei certificati TLS.

Le correzioni sono incluse nelle versioni più recenti rilasciate dai due progetti, ma individuare la versione giusta non è sempre semplice. Una distribuzione Linux può aver già applicato la correzione mantenendo un numero di versione che sembra vecchio: per PHP 8.3 su Ubuntu 24.04, per esempio, la correzione corrisponde al pacchetto 8.3.6-0ubuntu0.24.04.13, non a un salto di versione visibile a prima vista.

Per chi gestisce server PHP esiste uno strumento libero, php2shell-audit, pubblicato su GitHub. Elenca le installazioni di PHP presenti su una macchina, ne legge la versione esatta e il pacchetto della distribuzione da cui provengono, e le confronta con le versioni corrette, tenendo conto delle correzioni applicate dalle distribuzioni. Può anche cercare nei log le tracce di un tentativo di attacco. Lo scanner non prova a sfruttare le falle: sui siti remoti si limita a leggere le intestazioni della risposta, e va usato solo su sistemi propri o per cui si ha l'autorizzazione.

Lo stesso confronto, in forma passiva, è applicato all'amministrazione pubblica dal Censimento della sicurezza del settore pubblico svizzero, un progetto di Webcracy che ogni giorno verifica circa 2200 comuni, cantoni e uffici federali leggendo solo dati pubblici. Tra le altre cose indica quanti degli enti che mostrano la propria versione di PHP sono già passati a una versione corretta. Un'intestazione assente, però, non basta a dire che un sito sia al sicuro.

Il lavoro di verifica dietro l'aggiornamento

Webcracy, software house di Locarno che segue siti e applicazioni per aziende ticinesi, ha raccontato come ha gestito l'aggiornamento per i propri clienti. Il primo passo è stato capire quali versioni di PHP e Node.js stessero davvero servendo le richieste: su uno stesso server possono convivere il PHP del sistema, quello dentro un container e quello di un'applicazione separata, e correggerne uno lascia gli altri com'erano. Anche il Node.js già caricato in memoria da un gestore di processi come PM2 continua a girare finché non viene riavviato, qualunque sia la versione installata nel frattempo.

Prima di intervenire sono state conservate le versioni precedenti dei container e copie dei database, per poter tornare indietro in caso di problemi. Le modifiche sono state provate su copie isolate degli ambienti, con i test automatici delle applicazioni e controlli manuali sulle funzioni che contano per chi le usa ogni giorno: accessi, database, documenti. Il passaggio in produzione è avvenuto senza interruzioni: il monitoraggio degli endpoint ha continuato a ricevere risposte corrette.

Il caso mostra perché un sito protetto da una VPN o aggiornato solo a livello di CMS non è automaticamente al sicuro: la correzione riguarda il runtime PHP o Node.js che esegue l'applicazione, non solo il software scritto sopra di esso. Un'applicazione può inoltre continuare a usare una versione vecchia del runtime dentro un'immagine Docker, anche dopo che il sistema operativo è stato aggiornato.