CVE-2026-119179: falla nel driver MongoDB per Node.js, come verificare e aggiornare

CVE-2026-119179 è una vulnerabilità nel driver MongoDB per Node.js, con punteggio CVSS 4.0 di 8.3 (gravità alta). Il difetto sta nel livello di gestione delle connessioni: una connessione del pool può essere rimessa a disposizione mentre ha ancora dati in sospeso da un'operazione precedente. Nelle applicazioni che attivano il timeout opzionale lato client, un utente anonimo che invia richieste ordinarie può far sì che le risposte del database vengano abbinate alla richiesta sbagliata. L'effetto pratico è che un utente può vedere record di altri utenti, ricevere risultati errati o vedere fallire richieste legittime. Non risulta sfruttamento attivo nel catalogo CISA KEV. Se gestisci un'applicazione Node.js che parla con MongoDB, vale la pena fare le verifiche che descrivo sotto.

Cosa è successo: la vulnerabilità CVE-2026-119179 nel driver MongoDB per Node.js

Il driver MongoDB per Node.js mantiene un pool di connessioni verso il database per non aprirne una nuova a ogni query. Quando un'operazione viene interrotta da un timeout lato client, la connessione dovrebbe essere scartata o svuotata prima di tornare nel pool. Per questa falla la connessione torna invece nel pool con una risposta ancora in arrivo. La richiesta successiva che usa quella connessione può ricevere la risposta destinata all'operazione precedente. È un problema di coerenza tra richieste e risposte, non di accesso diretto al database: l'attaccante non ha bisogno di credenziali, gli basta poter usare l'applicazione come un qualsiasi visitatore.

Chi è colpito: versioni vulnerabili del driver MongoDB per Node.js

Il brief non riporta l'elenco delle versioni interessate né la versione corretta: vanno verificati sull'advisory del produttore e sulla scheda NVD. Sono da considerare potenzialmente esposte le applicazioni che:

• usano il pacchetto mongodb per Node.js, direttamente o tramite librerie che lo includono (per esempio ODM come Mongoose, che si appoggiano al driver ufficiale);
• hanno attivato il timeout opzionale lato client sulle operazioni. Se questa opzione non è abilitata, la condizione descritta nell'advisory non si verifica;
• servono più utenti sulla stessa istanza applicativa, perché è in quel caso che una risposta può finire nelle mani della persona sbagliata.

Il server MongoDB in sé non è il componente vulnerabile: il difetto è nel driver che gira dentro l'applicazione.

Quanto è grave: punteggio CVSS e sfruttamento attivo di CVE-2026-119179

Il vettore è CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:L. In parole semplici: attacco via rete, bassa complessità, nessun privilegio e nessuna interazione dell'utente. Il valore AT:P indica che serve una condizione preesistente, cioè il timeout lato client attivo. L'impatto principale è sulla riservatezza (alta): esposizione di record di altri utenti. Integrità e disponibilità sono colpite in misura bassa: risultati errati e richieste che falliscono. Non si tratta di esecuzione di codice remoto né di escalation di privilegi, ma per un'applicazione che tratta dati personali una fuga di record tra utenti è un incidente a tutti gli effetti, con possibili obblighi di notifica ai sensi del GDPR. Il catalogo CISA KEV non segnala al momento sfruttamento attivo.

Come capire se sei esposto: verifica versione, esposizione e log

Verifica la versione del driver MongoDB installata

Nella cartella del progetto esegui:

• npm ls mongodb per vedere la versione installata e da quale pacchetto dipende;
• npm ls mongodb --all per trovare copie annidate incluse da altre librerie;
• controlla package-lock.json o yarn.lock per la versione effettivamente risolta, che può differire da quella scritta in package.json.

Se usi container, ripeti il controllo dentro l'immagine in esecuzione, non solo sul repository.

Verifica se il timeout lato client è attivo

Cerca nel codice e nelle configurazioni le opzioni passate a MongoClient e alle singole operazioni. Nel driver Node.js il timeout lato client è di norma esposto come opzione timeoutMS: controlla l'advisory per il nome esatto nella tua versione. Se l'opzione non è presente, la condizione di sfruttamento non è soddisfatta, ma l'aggiornamento resta consigliato.

Esposizione e indicatori nei log

Il requisito è poter inviare richieste ordinarie all'applicazione: qualsiasi app pubblica su internet soddisfa questa condizione. Nei log applicativi cerca:

• errori di timeout sulle operazioni MongoDB seguiti da risposte anomale;
• segnalazioni di utenti che hanno visto dati non propri o risultati incoerenti;
• errori di deserializzazione o di tipo nei risultati delle query, che possono indicare risposte abbinate alla richiesta sbagliata;
• picchi di richieste da un singolo indirizzo che provocano timeout ripetuti.

Come risolvere la vulnerabilità CVE-2026-119179: patch, aggiornamento e rimedio

La versione corretta del driver non è indicata nel brief e va letta sull'advisory ufficiale di MongoDB e sulla GitHub Security Advisory. Una volta nota, l'aggiornamento si fa con npm install mongodb@<versione> o aggiornando la dipendenza in package.json e rigenerando il lock file. Se il driver arriva tramite Mongoose o un'altra libreria, aggiorna anche quella, perché potrebbe vincolare una versione vecchia del driver. Dopo l'aggiornamento ripeti npm ls mongodb --all per confermare che non restino copie vulnerabili, poi ricostruisci le immagini e ridistribuisci. Se la patch per il tuo ramo di versione non è disponibile, applica i workaround della sezione successiva e tieni monitorato l'advisory.

Cosa fare subito: mitigazioni e hardening per il driver MongoDB

1. Disattiva temporaneamente il timeout lato client se l'aggiornamento non è immediato: rimuove la condizione necessaria allo sfruttamento. Valuta l'impatto su richieste lente e usa altri meccanismi di protezione (limiti a livello di server o di reverse proxy).
2. Aggiorna il driver appena la versione corretta è confermata dall'advisory e testa l'applicazione in staging.
3. Limita la frequenza delle richieste sul reverse proxy o sul WAF, così da ridurre la capacità di un attaccante di provocare timeout a ripetizione.
4. Riduci l'esposizione: se l'applicazione serve solo utenti interni, mettila dietro VPN o restringi gli IP ammessi.
5. Attiva log dettagliati sulle operazioni MongoDB e sui timeout per avere evidenze se si presentasse un problema.

Non serve ruotare le credenziali del database per questa falla, perché non vengono esposte. Se però nei log emergono accessi anomali, trattali come incidente separato. Un audit dell'infrastruttura applicativa rientra nei servizi di consulenza IT e sicurezza dello studio.

Se sospetti una compromissione: incident response e analisi forense

Qui l'esposizione riguarda dati di altri utenti, quindi la priorità è capire cosa è stato mostrato e a chi. Non cancellare log, non riavviare il servizio prima di aver salvato lo stato e non sovrascrivere i file di registro con una nuova distribuzione. Conserva i log del reverse proxy, dell'applicazione e di MongoDB per la finestra temporale sospetta, con hash dei file per garantirne l'integrità. Se l'applicazione gira su un server dedicato o una VM, valuta una copia forense del disco e della memoria prima di intervenire. Ricostruisci quali richieste hanno ricevuto risposte abbinate male e quali record sono stati esposti: serve per decidere se c'è l'obbligo di notifica al Garante entro 72 ore e di comunicazione agli interessati. Un intervento di incident response e analisi forense parte da 1.500 € con preventivo a prezzo fisso. Per le prime ore puoi seguire anche la checklist dell'articolo su cosa fare nelle prime 24 ore, adattandola a un incidente di esposizione dati.

Fonti ufficiali su CVE-2026-119179

• Scheda NVD di CVE-2026-119179 (National Vulnerability Database), con descrizione ufficiale e vettore CVSS.
• Catalogo CISA KEV, da consultare per eventuali aggiornamenti sullo stato di sfruttamento.
• GitHub Security Advisories per il pacchetto mongodb, dove sono indicate le versioni interessate e quella corretta.
• Advisory e note di rilascio di MongoDB per il driver Node.js.

Serve una mano a verificare la tua applicazione?

Se non sai quale versione del driver gira in produzione, se il timeout lato client è attivo o come leggere i log per capire se qualcuno ha visto dati non suoi, posso fare la verifica con te. Lavoro di persona a Varese, Como e Milano e da remoto in tutta Italia. Richiedi un preventivo gratuito, rispondo entro 24 ore, oppure scrivimi dalla pagina contatti.