Analisi e correlazioni costruite anche grazie alla piattaforma Recorded Future (Insikt Group), che in questi casi è utile per mettere ordine nel caos tra segnali, rumor e priorità operative.

C’è una tradizione natalizia che nessuno ha chiesto ma che puntualmente arriva: panettone, parenti… e un bug pre-auth che fa uscire pezzi di memoria dal server come se fossero caramelle. Questa volta il regalo avvelenato si chiama MongoBleed, ovvero CVE-2025-14847, e colpisce MongoDB Server.

Non è la classica vulnerabilità “rompo tutto e ti cifro i dati”. È peggio in un modo più subdolo: ti porto via i segreti. E con i segreti ci apro tutto il resto.

Cosa succede

Il difetto nasce nella gestione dei messaggi compressi via zlib: con campi di lunghezza incoerenti, il server può finire a restituire heap memory non inizializzata a un client remoto non autenticato. Il risultato è un leak di dati “di passaggio” in memoria, molto in stile Heartbleed vibes, ma nel mondo MongoDB.

Qui il punto chiave è uno: prima dell’autenticazione. Se l’istanza è raggiungibile da Internet, l’attaccante non deve “indovinare” nulla. Deve solo parlare col servizio.

Parliamo di possibili leak di credenziali, token di sessione, API key, chiavi cloud, PII, config e frammenti di log. È materiale perfetto per fare pivot, escalation, e trasformare un leak “passivo” in compromissione “attiva” (e monetizzabile).

E no, non ti salva l’idea rassicurante “ma tanto Mongo è dietro al firewall”: spesso non lo è. O peggio, lo è “sulla carta”.

Patch

Le versioni fixate riportate pubblicamente includono 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30; NVD conferma la finestra di impatto e i rami coinvolti (inclusi quelli legacy dove la parola “migrazione” non è più un consiglio ma una condanna rimandata).

MongoDB ha rilasciato le patch il 19 dicembre 2025 e, come sempre, il tempo tra “fix disponibile” e “abuso in massa” si misura in sbadigli.

“In the wild”

Diverse analisi riportano sfruttamento attivo e un’accelerazione dopo la pubblicazione di dettagli/PoC. In parallelo, Censys fotografa l’elefante nella stanza: circa 87.000 istanze MongoDB esposte (con i soliti Paesi ai vertici).

E qui la nota di colore amara: nel 2025 discutiamo ancora di database lasciati su Internet come se fossero una landing page. Poi ci stupiamo se qualcuno passa a “raccogliere”.

Detection

Una delle parti più fastidiose di MongoBleed è proprio questa: non è detto che lasci tracce “facili” nei soliti flussi SIEM. Diversi ricercatori stanno spingendo artefatti e logiche di hunting (Velociraptor, query dedicate), perché intercettare i pattern del PoC richiede visibilità sul posto, non solo in periferia.

In pratica: se non hai logging decente sul nodo MongoDB, rischi di scoprire l’incidente dai sintomi, non dalla diagnosi.

Ubisoft / Rainbow Six Siege

Circola l’ipotesi che MongoBleed sia stato usato come vettore di accesso iniziale in un caso mediatico legato a Ubisoft / Rainbow Six Siege. VX-Underground riporta claim espliciti, mentre altre fonti trattano la vicenda come breach reale ma con vettore ancora non dimostrato pubblicamente. Morale: teniamolo sul radar, ma senza trasformare X in un tribunale.

Ed è esattamente qui che Recorded Future/Insikt, lato intelligence, torna comodo: separare fatti, probabilità e propaganda.

Cosa mi aspetto che succeda nelle prossime settimane

Succede sempre la stessa cosa: ondata di scanning, exploitation opportunistica, poi selezione dei bersagli “buoni” (quelli da cui puoi estrarre segreti utili per entrare altrove). MongoBleed è perfetta per questo modello: rubare chiavi è spesso più efficiente che bucare un perimetro a testate.

E in Italia? Non serve fare patriottismo dell’incidente: MongoDB è ovunque in stack moderni, spesso in mano a team piccoli, spesso “temporaneamente esposto” (cioè per sempre), spesso con l’idea che “tanto non interessa a nessuno”. Spoiler: interessa eccome. Soprattutto quando quello che esce dalla memoria sono token e credenziali riutilizzabili.

Cosa fare adesso

Patchare. Subito. Se non puoi patchare immediatamente, ridurre la superficie: niente esposizione diretta su Internet e, dove previsto come mitigazione temporanea, valutare la disabilitazione della compressione zlib finché non aggiorni (è una stampella, non una guarigione). Poi ragionare da incident responder, non da sysadmin ottimista: se l’istanza era esposta e sospetti attività, considera la rotazione dei segreti potenzialmente in memoria (credenziali, API key, token, chiavi cloud) e fai hunting mirato.

Perché la domanda non è “mi hanno bucato?”. La domanda, con MongoBleed, è più cinica: “quali segreti potrebbero essere già usciti?”

L'articolo MongoBleed (CVE-2025-14847): il database che “non perde”, sanguina proviene da Red Hot Cyber.