MongoDB, falla critica CVSS 9.5 permette di bloccare i cluster senza autenticazione

🛡️ Executive Summary

• MongoDB corregge una vulnerabilità critica CVSS 9.5. CVE-2026-118383 può provocare il crash di un server durante l’elezione del nuovo nodo primario, senza richiedere autenticazione.
• Datadog Security Labs dimostra l’attacco con due richieste. La tecnica sfrutta una use-after-free nella procedura di sincronizzazione del replica set, ma richiede condizioni operative specifiche.
• Le patch sono disponibili per sette rami MongoDB. MongoDB Atlas riceve gli aggiornamenti durante la manutenzione, mentre gli ambienti autonomamente gestiti richiedono verifiche su tutti i nodi.

MongoDB ha corretto una vulnerabilità critica che consente a un attaccante remoto non autenticato di predisporre il crash di un server durante le operazioni di failover di un cluster. Il problema, identificato come CVE-2026-118383 e valutato CVSS 9.5, riguarda la gestione della memoria utilizzata dai nodi appartenenti a un replica set. L’attacco può essere preparato attraverso appena due richieste ping, senza credenziali, ma il blocco si verifica soltanto quando il nodo interessato viene successivamente eletto primario mentre deve ancora recuperare operazioni di replica. MongoDB ha pubblicato le correzioni il 10 novembre 2026, mentre Datadog Security Labs ha riprodotto il crash in laboratorio il giorno successivo. Il produttore segnala anche una possibile esecuzione di codice arbitrario in determinate condizioni, eventualità che i ricercatori non sono riusciti a dimostrare.

CVE-2026-118383 colpisce il meccanismo di failover dei replica set

La vulnerabilità interessa i sistemi MongoDB configurati in replica set, architettura nella quale più server conservano copie dello stesso database per garantire disponibilità e continuità operativa. Normalmente un nodo primario gestisce le scritture, mentre gli altri ricevono e applicano le modifiche. Quando il primario non è più disponibile, il cluster organizza un’elezione per individuarne un sostituto. Il nuovo nodo deve eventualmente completare una fase di recupero, denominata primary catch-up, prima di accettare nuove scritture. È proprio nella conclusione di questa procedura che si manifesta il difetto. Una gestione errata delle risorse può provocare una use-after-free, condizione nella quale il software tenta di utilizzare memoria precedentemente liberata. L’avviso ufficiale MongoDB precisa che sono interessati anche i membri dei replica set utilizzati nei cluster suddivisi in shard, compresi i config server. Le istanze standalone mongod, non appartenenti a un replica set, non sono vulnerabili a questo specifico problema.

Due richieste ping preparano il crash senza credenziali

L’analisi tecnica di Datadog Security Labs dimostra che un client senza autenticazione può inviare due comandi ping contenenti il parametro readConcern.afterOpTime, inducendo il server vulnerabile a registrare notifiche di attesa, chiamate waiter. Queste rimangono associate al processo anche dopo la scadenza delle richieste e possono sopravvivere fino a un successivo cambiamento dello stato del nodo. Quando il server viene eletto primario e deve recuperare operazioni arretrate, la procedura di pulizia può essere eseguita due volte, provocando l’accesso a memoria già liberata e il conseguente arresto del processo.

L’attacco non consente però di provocare direttamente l’elezione o di creare il ritardo nella replica. Queste condizioni devono verificarsi indipendentemente, per esempio durante un’interruzione o un’operazione di manutenzione. Datadog ha riprodotto il problema su MongoDB 8.0.34, ottenendo un segmentation fault che ha lasciato il cluster di prova senza primario. L’esperimento dimostra la possibilità concreta del crash, non la capacità di riprodurlo sistematicamente contro qualsiasi installazione. La ricerca distingue inoltre questa vulnerabilità dalla precedente MongoBleed, che permetteva di esporre porzioni di memoria attraverso richieste non autenticate.

Leggi anche: MongoDB e LangChain: vulnerabilità critiche impongono patch urgenti

MongoDB segnala una possibile RCE, ma Datadog dimostra soltanto il crash

MongoDB considera possibile anche l’esecuzione di codice arbitrario con i privilegi del processo database, ma non presenta pubblicamente una dimostrazione completa di questo scenario. Datadog conferma invece esclusivamente l’interruzione del servizio. I ricercatori precisano che il test ha richiesto privilegi amministrativi per simulare il ritardo di replica e forzare il failover nel laboratorio: le sole due richieste malevole sono state inviate senza autenticazione. Questo dettaglio impedisce di confondere una prova sperimentale controllata con un attacco remoto sempre riproducibile. Nel proprio comunicato di sicurezza del 10 novembre, MongoDB dichiara inoltre di non essere a conoscenza di tentativi di sfruttamento della vulnerabilità. Il quadro è quindi diverso da quello della precedente MongoBleed, inserita dalla CISA nel catalogo delle vulnerabilità sfruttate attivamente.

Le versioni corrette di MongoDB e gli aggiornamenti Atlas

Le correzioni sono disponibili nelle versioni MongoDB 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 e 4.4.32, prime release corrette dei rispettivi rami. Sono interessate le versioni precedenti all’interno delle linee indicate. MongoDB Atlas aggiorna automaticamente i cluster durante le finestre di manutenzione, ma i clienti che hanno rinviato gli interventi devono applicare le correzioni quanto prima. Per gli ambienti self-managed occorre invece aggiornare ogni membro del replica set, controllando anche le istanze containerizzate e i server rimasti temporaneamente offline. Datadog ha verificato che MongoDB 8.0.37 respinge immediatamente le due richieste non autenticate utilizzate nella dimostrazione, impedendo la preparazione della condizione vulnerabile. Il produttore ha inoltre modificato la logica di pulizia per evitare la doppia liberazione delle risorse.

Come individuare i tentativi di attacco nei log MongoDB

Gli amministratori possono ricercare nei log strutturati le richieste ping contenenti readConcern.afterOpTime e terminate con MaxTimeMSExpired. Datadog segnala come possibile indicatore l’evento 51803, associato alle slow query, soprattutto quando riguarda client non autenticati. In prossimità di un crash, la sequenza più significativa comprende l’ingresso nella fase di catch-up, identificato dall’evento 21359, seguito da due uscite ravvicinate dalla stessa fase, registrate con l’ID 21363. Un successivo errore fatale che coinvolga CatchupState::abort_inlock() rafforza l’ipotesi di sfruttamento. Una normale elezione o una singola uscita dal catch-up non costituiscono una prova di attacco. Occorre inoltre esaminare i log precedenti al failover, perché le richieste preparatorie possono essere state inviate molto prima dell’interruzione.

Continua con: PCPJack prende di mira server MongoDB, Docker e servizi cloud esposti

Aggiornare ogni nodo è indispensabile per proteggere la disponibilità del database

La priorità è applicare le patch a tutti i membri dei replica set vulnerabili, evitando che un nodo non aggiornato possa diventare primario durante una successiva elezione. In attesa della correzione, MongoDB e Datadog raccomandano di limitare l’accesso di rete al database esclusivamente ai sistemi autorizzati, riducendo la possibilità che un attaccante raggiunga il servizio. Questa mitigazione non elimina però il difetto di memoria. CVE-2026-118383 dimostra che anche un meccanismo progettato per garantire alta disponibilità può trasformarsi in un punto di interruzione, quando un errore nella sincronizzazione dei nodi viene raggiunto attraverso richieste che non richiedono autenticazione. La protezione deve quindi coinvolgere sia il controllo degli accessi sia la verifica delle versioni effettivamente in esecuzione.