MongoBleed: come funziona la vulnerabilità che per 8 anni ha permesso di leggere la memoria dei database esposti

Parlando di vulnerabilità critiche, ce ne sono alcune che non colpiscono solo per l’impatto tecnico, ma per ciò che rivelano sulle fragilità strutturali dei sistemi moderni. MongoBleed, identificata come CVE-2025-14847, appartiene proprio a questa categoria. Si tratta di una lacuna di sicurezza (heap memory disclosure pre-autenticazione) che interessa praticamente tutte le versioni di MongoDB rilasciate dal 2017 in poi. Il difetto consente a un attaccante remoto di leggere porzioni arbitrarie della memoria, potenzialmente contenenti credenziali in chiaro, token di sessione, dati applicativi e informazioni di sistema.

Il parallelo con la storica vulnerabilità di Heartbleed, che affliggeva una libreria di OpenSSL, non è casuale: anche qui siamo davanti a un errore di fiducia nei confronti di un valore dichiarato dal client, che porta il server a esporre parti della memoria che non avrebbero mai dovuto essere condivise.

Cos’è MongoDB e perché è un bersaglio ideale

Per comprendere la falla MongoBleed, rimasta silenziosa “sotto il cofano” per oltre 8 anni, è necessario chiarire alcuni elementi fondamentali dell’architettura di MongoDB.

MongoDB è un database NoSQL open source orientato ai documenti. Invece di usare tabelle e righe come i database relazionali, MongoDB memorizza i dati in documenti BSON (Binary JSON), permettendo maggiore flessibilità nella struttura dei dati. Rilasciato nel 2009, è cresciuto rapidamente grazie alla sua capacità di scalare orizzontalmente e gestire grandi volumi di dati non strutturati. Oggi è adottato da aziende di ogni dimensione, dalle startup alle grandi corporation.

Secondo statistiche recenti, milioni di istanze MongoDB sono in uso, con oltre 200.000 esposte pubblicamente su Internet, anche se non tutte in produzione.

Campi applicativi di MongoDB

MongoDB è impiegato per:

• Archiviazione di dati non strutturati o semi-strutturati (documenti JSON).
• Applicazioni ad alta scalabilità grazie alla possibilità di distribuire i dati su cluster (sharding).
• Analisi in tempo reale e pipeline di aggregazione dati.
• Caching e session management nelle applicazioni Web.
• Flessibilità e velocità rendono MongoDB ideale per progetti dove i dati cambiano spesso e la struttura non è rigida.

Protocollo wire proprietario

MongoDB non utilizza HTTP o gRPC, ma un protocollo binario custom su TCP, progettato per massimizzare le prestazioni. Tutte le operazioni passano attraverso un unico opcode logico, OP_MSG, che incapsula comandi e dati in formato BSON.

Il formato BSON è ottimizzato per la velocità di serializzazione e deserializzazione, sfruttando strutture dati tipiche del mondo C/C++. Tra queste, un ruolo centrale è giocato dalle stringhe C null-terminated, che sono apparse decisive nello sfruttamento della vulnerabilità.

Compressione a livello di protocollo

MongoDB supporta la compressione dei messaggi di rete (zlib, snappy, zstd). Quando un messaggio è compresso, non viene inviato come OP_MSG, ma come OP_COMPRESSED, che contiene: opcode originale, dimensione dichiarata del payload una volta decompresso, algoritmo di compressione, payload compresso. Ed è proprio qui che nasce la vulnerabilità MongoBleed.

Il cuore del problema: fiducia nell’input dell’attaccante

MongoBleed nasce dalla combinazione di due assunzioni errate fatte dal server MongoDB durante la fase di parsing dei messaggi compressi: la fiducia cieca nelle dimensioni dichiarate dal client e l’uso di memoria heap non inizializzata in un contesto pre-autenticazione.

Quando un client invia un messaggio OP_COMPRESSED, specifica esplicitamente il campo uncompressedSize, che indica quanto spazio il server deve allocare per il payload una volta decompresso. MongoDB utilizza questo valore ma non verifica che la reale dimensione dei dati decompressi coincida con quella dichiarata.

Se il payload reale è più piccolo, l’area di memoria eccedente rimane popolata da contenuti residui di precedenti operazioni del processo. Questo comportamento, tipico dei programmi C/C++ che non azzerano la memoria allocata, espone il server a una classica heap memory disclosure. L’attacco diventa sfruttabile quando il contenuto della memoria è successivamente interpretato come parte di una struttura BSON: inviando un BSON intenzionalmente malformato e privo di terminatori nulli nei nomi dei campi, l’attaccante forza il parser a leggere oltre i limiti dei dati reali, attraversando la memoria heap non inizializzata.

I byte così letti sono trattati come stringhe valide, spesso esponendo dati riservati precedentemente presenti in memoria. Infine, nel tentativo di segnalare un errore di parsing, MongoDB include il nome del campo ritenuto non valido nel messaggio di errore restituito al client, trasformando di fatto una debolezza di validazione in un canale diretto di esfiltrazione dei contenuti in memoria.

Una vulnerabilità silente per 8 anni e il conto salato da pagare

MongoBleed rappresenta un caso emblematico di vulnerabilità rimasta latente per quasi 8anni, a dimostrazione di come le debolezze più pericolose non siano sempre quelle complesse o “esotiche”, ma spesso quelle introdotte in componenti fondamentali e mai più riesaminate criticamente.

Il bug viene inserito nel codice di MongoDB nel 2017 e sopravvive indisturbato attraverso numerose major release, fino a essere corretto solo nel 2025 con una modifica minima, quasi banale dal punto di vista implementativo.

Il fatto che alcune versioni ormai fuori supporto non riceveranno mai la patch amplifica ulteriormente il rischio, lasciando una superficie di attacco permanente in ambienti legacy ancora molto comuni. Questa lunga invisibilità solleva interrogativi profondi sulla qualità degli audit del codice storico, sulla gestione sicura della memoria in componenti di rete ad alta esposizione e sulla maturità dei processi di disclosure e comunicazione.

Come accennato in precedenza, le correzioni sono, paradossalmente, molto semplici: aggiornare immediatamente alle versioni sicure o, in alternativa, disabilitare la compressione zlib a livello di protocollo permettono di proteggere adeguatamente le istanze di MongoDB.

Resta comunque invariata una regola fondamentale della sicurezza operativa: un database non dovrebbe mai essere esposto su Internet.

Nel complesso, MongoBleed dimostra ancora una volta quanto la sicurezza della memoria in C/C++ sia fragile, come ottimizzazioni pensate per migliorare le prestazioni possano trasformarsi in vettori di attacco e quanto sia pericoloso fidarsi dei dati dichiarati dal client. Non è una vulnerabilità sofisticata, ma proprio per questo è estremamente pericolosa: la sua semplicità la rende sfruttabile anche da attori poco qualificati, mentre il suo impatto potenziale è devastante.