Una vulnerabilità critica in MongoDB sta creando non poca preoccupazione nella community degli amministratori di sistema e degli esperti di sicurezza informatica. Battezzata MongoBleed e catalogata come CVE-2025-14847, la falla sta venendo attivamente sfruttata in rete per estrarre credenziali, chiavi API e dati sensibili da oltre 80.000 server potenzialmente vulnerabili esposti su internet. La presenza di un exploit pubblico funzionante e la facilità di sfruttamento – non sono necessarie credenziali valide – rendono questa vulnerabilità particolarmente pericolosa per le infrastrutture che non hanno ancora applicato le patch di sicurezza rilasciate il 19 dicembre.
Il cuore del problema risiede nella gestione dei pacchetti di rete processati dalla libreria zlib, utilizzata da MongoDB per la compressione dei dati senza perdita. Come spiegato dai ricercatori di Ox Security, il server restituisce la dimensione della memoria allocata anziché la lunghezza effettiva dei dati decompressi durante l'elaborazione dei messaggi di rete. Un attaccante può quindi inviare un messaggio malformato che dichiara una dimensione maggiore una volta decompresso, costringendo il server ad allocare un buffer di memoria più grande e causando il leak dei dati sensibili presenti in memoria sul client.
L'aspetto più preoccupante della vulnerabilità è che l'exploit può essere eseguito prima della fase di autenticazione. Questo significa che un aggressore remoto non necessita di credenziali valide per attaccare un'istanza MongoDB esposta: è sufficiente conoscere l'indirizzo IP del server per iniziare a estrarre informazioni dalla memoria. Il ricercatore di sicurezza Kevin Beaumont ha confermato la validità del codice proof-of-concept pubblicato da Joe Desimone di Elastic Security, sottolineando come richieda soltanto "un indirizzo IP di un'istanza MongoDB per iniziare a scovare in memoria elementi come password dei database (che sono in chiaro), chiavi segrete AWS e altro".
I dati trapelabili attraverso MongoBleed includono credenziali di accesso, chiavi API e cloud, token di sessione, informazioni personalmente identificabili, log interni, configurazioni di sistema, percorsi di file e dati correlati ai client. La natura pre-autenticazione dell'exploit amplifica drammaticamente la superficie di attacco, trasformando ogni istanza MongoDB esposta pubblicamente in un potenziale punto di compromissione senza necessità di bypass di credenziali o escalation di privilegi.
La distribuzione geografica delle istanze vulnerabili vede quasi 20.000 server MongoDB negli Stati Uniti, seguiti da circa 17.000 in Cina e poco meno di 8.000 in Germania. In ambito europeo, la situazione richiede particolare attenzione considerando le normative GDPR che impongono severi obblighi di notifica in caso di data breach: la perdita di dati personali attraverso MongoBleed potrebbe esporre le organizzazioni a sanzioni significative oltre al danno reputazionale.
I dati telemetrici della piattaforma di sicurezza cloud Wiz rivelano che il 42% dei sistemi visibili presenta almeno un'istanza MongoDB in una versione vulnerabile a CVE-2025-14847. Queste istanze comprendono sia risorse interne che sistemi esposti pubblicamente, suggerendo che l'impatto potenziale si estende ben oltre i server direttamente raggiungibili da internet. Wiz ha confermato di aver osservato attività di sfruttamento di MongoBleed in scenari reali e raccomanda alle organizzazioni di dare priorità assoluta all'applicazione delle patch.
Alcuni attori della minaccia, sebbene non verificati, stanno rivendicando l'utilizzo della falla MongoBleed in una recente violazione di Rainbow Six Siege. Se confermato, questo rappresenterebbe uno dei primi casi pubblici di compromissione su larga scala attribuibile a questa vulnerabilità, sottolineando l'urgenza dell'intervento di mitigazione.
Eric Capuano, co-fondatore di Recon InfoSec, avverte che l'applicazione delle patch rappresenta solo una parte della risposta al problema MongoBleed. Le organizzazioni devono anche verificare la presenza di segni di compromissione nei loro sistemi. In un post sul blog, il ricercatore illustra un metodo di rilevamento che include la ricerca di "un indirizzo IP sorgente con centinaia o migliaia di connessioni ma zero eventi di metadati". Tuttavia, Capuano avverte che questo metodo si basa sul codice exploit proof-of-concept attualmente disponibile e che un attaccante potrebbe modificarlo per includere metadati client falsi o ridurre la velocità di sfruttamento, rendendo più difficile il rilevamento.
Florian Roth, creatore dello scanner APT THOR e di migliaia di regole YARA, ha utilizzato la ricerca di Capuano per sviluppare il MongoBleed Detector, uno strumento che analizza i log di MongoDB e identifica potenziali tentativi di sfruttamento della vulnerabilità CVE-2025-14847. Questo tipo di strumenti di analisi forense diventano essenziali per le organizzazioni che sospettano di essere state compromesse prima dell'applicazione delle patch.
MongoDB ha rilasciato gli aggiornamenti di sicurezza il 19 dicembre, con una raccomandazione forte agli amministratori di aggiornare alle versioni sicure: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.30. Il vendor ha assegnato alla vulnerabilità un punteggio di gravità di 8.7 e l'ha gestita come "correzione critica", riflettendo la serietà della minaccia per le infrastrutture che utilizzano il database.
L'elenco delle versioni MongoDB impattate da MongoBleed è estremamente ampio, coprendo rilasci che vanno dal tardo 2017 fino a novembre 2025. Sono vulnerabili tutte le versioni dalla 3.6 alla 8.2.3, con l'eccezione delle versioni con patch specifiche rilasciate a dicembre. Questo ampio spettro temporale significa che anche organizzazioni che utilizzano versioni legacy per requisiti di compatibilità sono esposte al rischio e devono valutare urgentemente strategie di mitigazione.
I clienti di MongoDB Atlas, il servizio di database multi-cloud completamente gestito, hanno ricevuto la patch automaticamente e non necessitano di alcuna azione. Questa è una delle poche note positive nella situazione, evidenziando i vantaggi dei servizi gestiti in termini di sicurezza e rapidità di risposta agli incidenti.
MongoDB ha dichiarato esplicitamente che non esiste alcuna soluzione alternativa per la vulnerabilità oltre all'aggiornamento. Per le organizzazioni che non possono immediatamente migrare a una nuova versione, il vendor raccomanda di disabilitare la compressione zlib sul server, fornendo istruzioni dettagliate su come procedere. Alternative sicure per la compressione dei dati senza perdita includono Zstandard (zstd) e Snappy, mantenuti rispettivamente da Meta e Google, che non presentano la stessa vulnerabilità di implementazione.
