La vulnerabilità nel decoder Brotli di Node.js
Il 21 ottobre 2026 il progetto Node.js ha pubblicato aggiornamenti di sicurezza per i rami 22.x, 24.x e 26.x. Il problema più importante è CVE-2026-111497, una scrittura fuori dai limiti della memoria nel decoder Brotli che, in determinate condizioni, può consentire l’esecuzione di codice da remoto.
L’avviso ufficiale assegna alla vulnerabilità gravità alta, non critica. La distinzione è importante per comunicare correttamente il rischio, ma non cambia l’azione consigliata: aggiornare il runtime usato dalle applicazioni esposte.
Versioni Node.js corrette
- Node.js 22.23.4 o successiva nel ramo 22;
- Node.js 24.22.1 o successiva nel ramo 24;
- Node.js 26.12.1 o successiva nel ramo 26.
Perché aggiornare npm non basta
CVE-2026-111497 si trova nel runtime Node.js. Eseguire un aggiornamento delle dipendenze npm o rigenerare il file lock non cambia il binario che esegue l’applicazione. Bisogna controllare ogni ambiente in cui Node viene realmente avviato: computer di sviluppo, server, immagini Docker, funzioni serverless e pipeline CI/CD.
Un progetto può dichiarare una versione recente nel file di configurazione e continuare a girare in produzione su un’immagine base vecchia. Per questo la verifica deve essere eseguita nel container o nel processo in esecuzione, non soltanto nel repository.
Checklist per applicazioni SaaS, API e siti web
- Censire le applicazioni Node.js. Includi API, dashboard, job pianificati, webhook e strumenti interni.
- Verificare la versione in produzione. Controlla il runtime effettivo su ogni ambiente.
- Aggiornare immagini e build. Modifica la base Docker o il runtime cloud e ricostruisci l’applicazione.
- Eseguire i test. Verifica compressione, upload, download, proxy, autenticazione e integrazioni.
- Rilasciare gradualmente. Usa staging, health check e possibilità di rollback.
- Controllare log e metriche. Cerca crash, errori anomali e richieste sospette prima e dopo il rilascio.
Quando bisogna ruotare API key e segreti?
La presenza di una vulnerabilità non dimostra automaticamente che il server sia stato compromesso. La rotazione delle credenziali diventa prioritaria quando emergono indicatori sospetti, il runtime vulnerabile era esposto a input non fidati o non è possibile ricostruire con certezza cosa sia accaduto.
In quel caso occorre cambiare segreti del database, token cloud, chiavi dei provider AI, webhook, chiavi SSH e credenziali dei registri privati. La procedura deve partire dalle credenziali con più privilegi e considerare anche copie presenti in pipeline, log, backup e ambienti di test.
La vulnerabilità è stata trovata con l’AI?
L’avviso Node.js attribuisce CVE-2026-111497 a ricercatori di OpenAI Codex Security. È quindi corretto dire che sistemi di sicurezza assistiti da AI stanno contribuendo alla scoperta di vulnerabilità. Non è invece corretto estendere questa attribuzione alla falla PHP2Shell o affermare che un modello specifico abbia scoperto entrambe le vulnerabilità senza una fonte ufficiale.
Per le imprese il messaggio utile è operativo: la velocità con cui vengono trovati e sfruttati i problemi rende indispensabili inventario, aggiornamenti rapidi e procedure di emergenza. Non basta affidarsi a un controllo manuale eseguito una volta all’anno.
Come può intervenire Agentix
Agentix può mappare applicazioni e runtime, aggiornare immagini e pipeline, predisporre test di regressione e definire una procedura di rotazione dei segreti. Per sistemi critici possiamo introdurre inventario delle dipendenze, scansioni automatiche, ambienti di staging e alert sulle versioni fuori supporto.
Se la tua infrastruttura utilizza Railway o altri PaaS, leggi anche la guida su API key e variabili d’ambiente. Per WordPress e applicazioni PHP vedi invece l’analisi PHP2Shell.
Domande frequenti
Quali versioni Node.js correggono CVE-2026-111497?
Le versioni correttive pubblicate dal progetto Node.js sono 22.23.4, 24.22.1 e 26.12.1. Occorre installare almeno la patch indicata per il proprio ramo supportato.
Aggiornare package-lock.json risolve la vulnerabilità?
No. La vulnerabilità è nel runtime Node.js e non in una dipendenza npm. Va aggiornato il binario usato da server, container, pipeline e ambienti di produzione.
Il problema riguarda anche applicazioni che non usano Brotli?
Il rischio concreto dipende da come l’applicazione elabora dati compressi e da quali ingressi sono controllabili da utenti esterni. La raccomandazione ufficiale resta comunque aggiornare le versioni interessate.