La fine del 2025 si è chiusa con due avvisi di sicurezza ad alta gravità che coinvolgono componenti centrali dell’infrastruttura digitale moderna: database distribuiti e framework per orchestrazione AI. Da un lato MongoDB ha confermato una vulnerabilità server-side che espone memoria heap non inizializzata a client non autenticati; dall’altro LangChain ha corretto una injection di serializzazione in grado di portare all’istanziazione di oggetti arbitrari, all’estrazione di segreti e persino all’esecuzione di codice.
Due difetti diversi per natura, ma accomunati da un fattore critico: la superficie d’attacco è ampia, il costo dell’exploit è basso e il contesto di utilizzo è estremamente diffuso, soprattutto in ambienti cloud, microservizi e pipeline AI.
Cosa leggere
Vulnerabilità CVE-2025-14847 in MongoDB
La vulnerabilità CVE-2025-14847 colpisce il server MongoDB e riguarda la gestione dei messaggi compressi tramite zlib. Il problema nasce da inconsistenze nei parametri di lunghezza durante la decompressione, classificate come CWE-130, che possono portare alla restituzione di memoria heap non inizializzata a un client remoto.
Il punto più critico è che l’attacco non richiede autenticazione e non necessita di alcuna interazione da parte dell’utente. Un attaccante remoto può sfruttare il bug semplicemente inviando pacchetti appositamente costruiti, con una complessità di attacco bassa e un potenziale impatto elevato.
MongoDB chiarisce che la vulnerabilità non è classificata formalmente come RCE, ma sottolinea come, in determinati scenari, l’accesso a memoria non inizializzata possa aprire la strada a comportamenti imprevedibili, inclusa l’esecuzione di codice arbitrario o la compromissione del processo.
Versioni MongoDB interessate e impatto reale
Il difetto interessa un ampio spettro di versioni, comprese release ancora largamente utilizzate in produzione. Risultano vulnerabili, tra le altre, le serie 8.2, 8.0, 7.0, 6.0, 5.0 e 4.4, oltre a tutte le versioni più datate come 4.2, 4.0 e 3.6. Questo significa che una parte significativa delle installazioni MongoDB nel mondo è esposta, soprattutto in ambienti legacy o con cicli di aggiornamento lenti.
Al momento MongoDB non segnala exploit attivi in the wild, ma la combinazione tra assenza di autenticazione, superficie di attacco di rete e meccanismi di compressione abilitati di default rende il rischio concreto, specialmente per istanze esposte direttamente su Internet o mal segmentate.
Patch disponibili e mitigazioni temporanee
MongoDB raccomanda come unica soluzione definitiva l’aggiornamento alle versioni corrette, tra cui 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 e 4.4.30, a seconda del ramo utilizzato. L’azienda sottolinea che l’upgrade deve essere considerato prioritario, anche in ambienti sensibili.
Per chi non può aggiornare immediatamente, viene indicata una mitigazione temporanea: la disabilitazione del compressore zlib avviando mongod o mongos con la configurazione networkMessageCompressors che escluda zlib. Questa misura riduce drasticamente il rischio, ma non sostituisce la patch, e può avere impatti sulle prestazioni.
CVE-2025-68664 in LangChain Core: la vulnerabilità LangGrinch
In parallelo, il framework LangChain Core ha corretto una vulnerabilità ancora più grave sul piano applicativo: CVE-2025-68664, con punteggio CVSS 9.3. Il difetto, soprannominato LangGrinch, riguarda una injection di serializzazione nelle funzioni dumps() e dumpd().
Il problema nasce dal fatto che chiavi speciali interne ("lc") non venivano adeguatamente escaped durante la serializzazione di strutture dati free-form. In LangChain, la chiave "lc" identifica oggetti interni del framework; se un attaccante riesce a inserirla in campi controllabili dall’utente, come metadata, additional_kwargs o response_metadata, la fase di deserializzazione può istanziare oggetti arbitrari.
Catena di attacco e impatti concreti
Questa vulnerabilità è particolarmente pericolosa perché si inserisce perfettamente nei flussi di orchestrazione LLM, dove input e output vengono serializzati e deserializzati più volte, spesso in modo automatico. Un attacco tipico può avvenire tramite prompt injection, sfruttando risposte del modello che vengono poi trattate come dati strutturati.
Gli impatti sono rilevanti. In configurazioni vulnerabili è possibile estrarre segreti dalle variabili d’ambiente, se l’opzione secrets_from_env è abilitata, e in alcuni casi arrivare all’esecuzione di codice arbitrario tramite template Jinja2. Questo rende la vulnerabilità estremamente critica in contesti enterprise, agent-based e pipeline AI multi-step.
Versioni affette e correzioni introdotte
La vulnerabilità interessa LangChain Core dalla versione 1.0.0 fino alla 1.2.4, oltre a versioni precedenti inferiori a 0.3.81. La patch è stata rilasciata con langchain-core 1.2.5 e 0.3.81, introducendo cambiamenti di sicurezza significativi.
Le nuove versioni bloccano per default il caricamento di template Jinja2, impostano secrets_from_env su False e introducono un meccanismo di allowlist che limita esplicitamente le classi consentite durante load() e loads(). Questo cambio di paradigma sposta la responsabilità verso lo sviluppatore, ma riduce drasticamente il rischio di abuso.
Un difetto simile è stato individuato anche nell’ecosistema JavaScript, come CVE-2025-68665 in LangChain.js, a conferma che il problema riguarda l’architettura di serializzazione più che una singola implementazione.
Implicazioni sistemiche per database e orchestrazioni AI
Questi due casi mettono in luce un problema strutturale. MongoDB rappresenta uno dei pilastri dei backend moderni, mentre LangChain è sempre più usato come collante per agenti AI, strumenti e pipeline di automazione. Vulnerabilità in questi componenti non colpiscono un singolo servizio, ma si propagano lungo intere catene applicative.
Nel caso MongoDB il rischio riguarda esposizione di memoria e potenziali compromissioni di processo. In LangChain il pericolo è ancora più subdolo, perché si innesta nel flusso logico dell’AI, sfruttando fiducia implicita nei dati prodotti dai modelli.
Raccomandazioni operative
Per MongoDB, la priorità è aggiornare immediatamente o, in alternativa temporanea, disabilitare zlib e limitare l’esposizione di rete. Per LangChain, l’aggiornamento è imprescindibile, insieme a una revisione delle pipeline di serializzazione, evitando il caricamento automatico di strutture non fidate.
In entrambi i casi, la lezione è chiara: componenti infrastrutturali e framework AI devono essere trattati come superfici d’attacco critiche, non come semplici librerie di supporto. Logging, segmentazione, validazione degli input e aggiornamenti rapidi restano gli strumenti più efficaci per ridurre il rischio.
