Set di repliche MongoDB: use-after-free pre-autenticazione può mandare in crash i server (CVE-2026-118383)

Cosa è successo

Il 10 novembre 2026 MongoDB ha reso pubblico il CVE-2026-118383, un use-after-free nel componente di replica di MongoDB Server. Ha un punteggio di 9.0 secondo CVSS. Il difetto può verificarsi quando un primario di un set di repliche appena eletto completa la fase di allineamento. Richieste che non richiedono autenticazione possono attivarlo. Il risultato può essere l'arresto imprevisto del processo del server. In determinate condizioni, può anche portare all'esecuzione arbitraria di codice nel contesto del processo del server.

Secondo The Hacker News, il rischio riguarda un membro di un set di repliche rimasto indietro che diventa primario, ad esempio durante un failover. MongoDB ha rilasciato le correzioni. La vulnerabilità non è inserita nel catalogo CISA delle vulnerabilità note sfruttate e nessuna delle fonti segnala attacchi.

Chi è interessato

• Interessati: processi mongod che funzionano come membri di un set di repliche. Ne fanno parte i set di repliche degli shard e dei config server dei cluster shardati.
• Non interessati: istanze mongod standalone che non fanno parte di un set di repliche.

Il difetto può essere attivato prima dell'autenticazione, quindi attivare l'autenticazione non La protegge. Il rischio maggiore riguarda i membri dei set di repliche raggiungibili da reti non attendibili o da molti host applicativi.

Cosa fare ora

1. Elenchi i membri del set di repliche. Su ciascun server MongoDB verifichi se mongod viene eseguito come parte di un set di repliche (vedere la sezione seguente). Le istanze standalone non richiedono interventi urgenti per questo CVE.
2. Individui la versione corretta per la sua serie di release. Il ticket MongoDB SERVER-138119 (collegato sotto) fa parte della correzione. Elenca le versioni corrette 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 e 4.4.32. Confronti con SERVER-138175 per confermare la versione della sua serie.
3. Esegua un backup della configurazione. Salvi /etc/mongod.conf (o l'equivalente) e verifichi che esista un backup recente dei dati.
4. Aggiorni un membro alla volta. Inizi dai secondari. Aggiorni il pacchetto (ad esempio apt install mongodb-org oppure dnf update mongodb-org), riavvii mongod e attenda che il membro torni SECONDARY in rs.status(). Esegua poi rs.stepDown() sul primario e lo aggiorni per ultimo. Nei cluster shardati aggiorni il set di repliche dei config server e ogni set di repliche degli shard.
5. Limiti l'accesso di rete. La porta 27017 (o la porta personalizzata) dovrebbe essere raggiungibile solo dai server applicativi e dagli altri membri del cluster. Usi il firewall o bindIp per applicarlo, sia ora sia dopo l'aggiornamento.
6. Controlli eventuali arresti. Verifichi i log di mongod e il monitoraggio dei servizi per riavvii imprevisti, in particolare durante elezioni e failover.

Come verificare se è interessato

• Verifichi la versione con mongod --version, oppure in mongosh con db.version().
• Verifichi l'appartenenza al set di repliche in mongosh con db.hello().setName. Se viene restituito un nome, l'istanza è un membro di un set di repliche ed è interessata finché non viene aggiornata. Se non viene restituito nulla e rs.status() segnala che l'istanza non funziona con la replica, si tratta di un'istanza standalone e non è interessata.
• Per i cluster shardati, esegua la verifica su ogni membro degli shard e su ogni membro dei config server.
• Se un membro è su una versione precedente alla versione corretta della sua serie di release, lo aggiorni.

Fonti

• https://nvd.nist.gov/vuln/detail/CVE-2026-118383
• https://jira.mongodb.org/browse/SERVER-138119