Due ping anonimi piantano una bomba a orologeria nel failover MongoDB

CVE-2026-118383 è una use-after-free pre-autenticazione con CVSS 4.0 di 9.5: due comandi ping creano attenditori persistenti che causano crash quando un primario in ritardo vince l'elezione.

MongoDB ha pubblicato il 10 novembre 2026 la correzione di CVE-2026-118383, una use-after-free con punteggio CVSS 4.0 di 9.5 che si attiva durante l'elezione di un nuovo primario in un replica set. La scoperta, condotta internamente da MongoDB e riprodotta dai laboratori di Datadog, rivela un attacco a due tempi: l'aggressore invia due richieste, attende il cambio di topologia, e il crash avviene in un momento successivo.

Punti chiave

La vulnerabilità è una use-after-free (CWE-416) nel codice di catch-up della replica MongoDB, con CVSS 4.0 di 9.5 secondo la CNA MongoDB.
L'attacco richiede due comandi ping non autenticati con readConcern.afterOpTime; le richieste non causano crash immediato ma creano attenditori persistenti.
Il crash avviene solo quando un membro che ha ricevuto le richieste vince un'elezione da primario in ritardo rispetto a un altro nodo.
Le versioni corrette sono la 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 e 4.4.32; il ramo 8.2, in end-of-life dal 31 luglio 2026, non riceve patch.

Come funziona l'attacco decoupled

Il meccanismo tecnico separa azione e effetto. Un client con connettività di rete verso un membro del replica set invia due comandi ping con parametro readConcern.afterOpTime. MongoDB, anche su versioni con autenticazione abilitata, accetta queste richieste prima del login: il protocollo consente operazioni di basso livello pre-autenticazione, e il ping con quel parametro rientra in questa superficie esposta.

Le due richieste generano attenditori nella coda interna del nodo. Secondo l'analisi di Datadog Security Labs, questi attenditori permangono fino a riavvio del processo mongod, rollback o step-down manuale. Fino alla loro cancellazione, il nodo funziona normalmente e i log non mostrano anomalie critiche.

La detonazione avviene in una finestra successiva. Quando il membro che ha ricevuto i ping vince un'elezione da primario, se risulta in ritardo rispetto a un altro nodo, entra in fase di catch-up per sincronizzarsi. In questa fase, la funzione CatchupState::abort_inlock() gestisce la pulizia degli attenditori. Per effetto dei due ping, la pulizia viene eseguita due volte: la seconda iterazione riutilizza memoria già liberata, generando la use-after-free.

Datadog ha riprodotto il crash su MongoDB Server 8.0.34 in laboratorio. I ricercatori hanno osservato un segmentation fault che ha reso il replica set privo di primario. Il cluster può eleggere un nuovo primario e continuare a funzionare, quindi lo stallo permanente non è garantito.

Perché questo cambia il threat model

La natura decoupled di CVE-2026-118383 altera le logiche di rilevamento tradizionali. Non è una vulnerabilità che si manifesta nel momento dell'attacco iniziale: le due richieste ping non generano allarmi immediati e lasciano pochi indicatori. Il crash avviene solo in seguito a un evento di failover, che l'attaccante non può né prevedere né controllare. Questo asincronismo richiede strategie di detection basate sulla correlazione temporale tra richieste pre-auth sospette e successivi eventi di elezione primaria anomala.

Perché l'autenticazione non blocca

Un aspetto che distingue questa vulnerabilità è la sua natura pre-autenticazione. MongoDB consente operazioni di rilevamento e handshaking prima del completamento dell'autenticazione, e il ping con readConcern.afterOpTime sfrutta questa finestra. Datadog ha verificato che abilitare l'autenticazione su versioni vulnerabili non impedisce l'accettazione delle due richieste: il controllo di sicurezza comune non si applica al vettore d'ingresso.

La scoperta solleva questioni strutturali sulla superficie pre-auth del protocollo wire di MongoDB. I database replica set sono spesso esposti a reti interne ritenute affidabili. La possibilità di piantare payload persistenti con privilegi zero riduce la barriera all'ingresso per un aggressore con foothold di rete.

"A use-after-free in the replication component of MongoDB Server can occur when a newly elected replica set primary completes catch-up. The condition can be caused by requests that do not require authentication, and may result in the server terminating unexpectedly or, under certain conditions, arbitrary code execution in the context of the server process."
— Descrizione CVE-2026-118383, record CNA/NVD

Cosa Datadog ha verificato e cosa resta incerto

I ricercatori di Datadog Security Labs hanno condotto la più dettagliata riproduzione indipendente disponibile. Sulle versioni vulnerabili, hanno confermato il crash controllato; sulla versione corretta 8.0.37, hanno verificato che il server respinge entrambe le richieste come non autorizzate e il failover si completa regolarmente.

Per quanto riguarda l'esecuzione di codice arbitrario, i confini tra dichiarazione e dimostrazione sono netti. MongoDB, nella descrizione della CNA, afferma che condizioni particolari potrebbero permetterla. Datadog ha dichiarato esplicitamente di non aver raggiunto l'esecuzione di codice nel proprio ambiente di laboratorio. Il proof-of-concept disponibile su GitHub, in modalità affidabile, richiede un'impostazione disponibile solo in ambiente di test; l'autore sostiene che l'impatto si limiti a crash e corruzione di memoria.

Cosa fare adesso

Gli amministratori di deployment self-managed devono aggiornare ogni membro del replica set, inclusi shard e config server nei cluster sharded, alle versioni corrette: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 o 4.4.32. I container e i membri offline richiedono la stessa attenzione: un singolo nodo vulnerabile espone l'intero replica set al rischio di crash durante il failover. I cluster MongoDB Atlas ricevono le correzioni automaticamente durante le finestre di manutenzione programmate.

Per i deployment che non possono applicare immediatamente la patch, Datadog consiglia di limitare l'accesso di rete ai membri del replica set. Questa misura non elimina la vulnerabilità ma riduce la superficie di attacco, impedendo a un aggressore di piantare i due ping iniziali. L'abilitazione dell'autenticazione, pur raccomandata in generale, non blocca questo vettore specifico sulle versioni vulnerabili.

I team di sicurezza possono monitorare i log per tre indicatori correlati: il comando ping non autenticato con readConcern.afterOpTime che termina con MaxTimeMSExpired (ID log 51803); l'ingresso di un membro in fase di catch-up (ID 21359) seguito da due uscite consecutive (ID 21363); e segnali fatali o backtrace che coinvolgono CatchupState::abort_inlock(). La correlazione temporale tra richieste pre-auth e eventi di elezione primaria anomala offre il miglior segnale di detection.

Il contesto: 26 vulnerabilità in un solo aggiornamento

CVE-2026-118383 è la più grave di 26 vulnerabilità corrette da MongoDB nel medesimo aggiornamento di novembre 2026, secondo l'allerta dell'ACN italiana riportata da MeteoraWeb. Nessuna delle altre 25 raggiunge però la stessa criticità: la combinazione di accesso pre-autenticazione, impatto su disponibilità e integrità, e complessità di rilevazione rende questa use-after-free un caso a sé.

Il ramo 8.2, escluso dalla lista delle versioni affette e giunto a end-of-life il 31 luglio 2026, non riceverà correzioni. Gli utenti che ancora lo utilizzano devono pianificare la migrazione a un ramo supportato: 8.3, 8.0 o 9.0 a seconda delle esigenze di compatibilità.

Chiusura editoriale

CVE-2026-118383 rappresenta una mutazione nel threat model delle vulnerabilità di database: non serve un exploit complesso, non serve autenticazione compromessa, non serve nemmeno che l'attaccante controlli il momento del crash. Bastano due comandi banali e l'attesa. La barriera tecnica è bassissima, la barriera temporale invece — la necessità che un primario in ritardo vinca l'elezione — introduce un elemento di probabilità che non deve confondere il giudizio sul rischio. Un replica set senza primario è un servizio fermo, e nei sistemi che gestiscono transazioni finanziarie o dati sanitari, ogni secondo di indisponibilità ha un costo misurabile. La patch esiste, è testata, è disponibile per sette rami di versione. L'unica variabile rimasta è la velocità con cui gli amministratori la applicano.

Fonti

Fonti e riferimenti

Ricevi DeafLetter