CosmosEscape espone ogni database Azure Cosmos DB con una chiave globale

🛡️ Executive Summary

• CosmosEscape evade il sandbox della Gremlin API e ottiene esecuzione di codice sui gateway multi-tenant di Azure Cosmos DB.
• Una chiave globale permetteva di enumerare gli account e recuperare la chiave primaria di qualsiasi database, anche privato o isolato.
• Microsoft ha bloccato il vettore entro 48 ore e completato la correzione architetturale; non sono richieste azioni ai clienti.

Wiz Research ha scoperto CosmosEscape, una catena di vulnerabilità che avrebbe permesso di ottenere accesso completo in lettura e scrittura a qualsiasi database ospitato su Azure Cosmos DB. L’attacco partiva da una query inviata alla Gremlin API, evadeva il sandbox utilizzato dal motore Microsoft e raggiungeva una chiave di firma valida attraverso tenant, regioni e differenti interfacce del servizio. Da quel punto un aggressore avrebbe potuto enumerare gli account Cosmos DB e recuperare le relative chiavi primarie, comprese quelle appartenenti a Microsoft. La falla è stata corretta a livello di piattaforma e Microsoft afferma di non avere trovato prove di sfruttamento oltre ai test autorizzati dei ricercatori.

Una query Gremlin evade il sandbox di Cosmos DB

La ricerca è iniziata da un’eccezione .NET restituita durante l’esecuzione di una query Gremlin. Il comportamento indicava che Azure Cosmos DB non utilizzava uno stack Gremlin tradizionale basato sulla Java Virtual Machine, ma un motore personalizzato capace di tradurre le query in codice .NET ed eseguirle all’interno di un ambiente ristretto. Le regole del sandbox avrebbero dovuto limitare le operazioni alle funzionalità previste dal linguaggio per grafi, ma non gestivano correttamente alcune possibilità offerte dalla reflection di .NET. Wiz è riuscita così a costruire primitive per leggere e scrivere file e, successivamente, a eseguire comandi arbitrari sui sistemi backend che elaboravano le query. Il codice non veniva eseguito direttamente sui server contenenti i database dei clienti, ma sul DB Gateway, un servizio distribuito su cluster multi-tenant di Azure Service Fabric e incaricato di ricevere le richieste, applicare i controlli di rete e raggiungere gli account Cosmos DB.

Questa distinzione non riduceva l’impatto, perché il gateway possedeva proprio gli accessi necessari per comunicare con i database per conto dei clienti. La vulnerabilità mostra nuovamente come un sandbox escape in un servizio cloud condiviso possa superare le barriere logiche tra tenant, un rischio analogo a quello emerso negli attacchi contro agenti e sandbox cloud capaci di raggiungere credenziali tra cluster.

La Cosmos Master Key funzionava attraverso tenant e regioni

Analizzando le credenziali disponibili sul cluster, i ricercatori hanno individuato una chiave di firma utilizzata dal DB Gateway per richiedere la chiave primaria dell’account destinatario. La chiave primaria di Cosmos DB concede accesso completo in lettura e scrittura, ma il segreto individuato da Wiz non era limitato al database del ricercatore o a uno specifico tenant.

La cosiddetta Cosmos Master Key funzionava sull’intera piattaforma, attraversando organizzazioni, sottoscrizioni, regioni e API differenti, comprese le interfacce SQL, MongoDB, Cassandra e Gremlin. Attraverso endpoint pubblicamente raggiungibili, un aggressore capace di completare la catena avrebbe potuto richiedere la chiave primaria di un account scelto e assumere il controllo dei relativi database. Il problema non consisteva quindi soltanto nell’evasione del sandbox, ma nella presenza di un segreto con privilegi globali all’interno dello stesso confine raggiungibile dal codice controllato dal tenant. Questa architettura trasformava la compromissione di un singolo componente condiviso in un percorso potenziale verso l’intero servizio. Il caso conferma perché le credenziali service-to-service debbano essere ristrette per tenant, funzione e durata, evitando segreti capaci di superare contemporaneamente più confini di isolamento. Il tema è centrale anche nelle vulnerabilità cloud che espongono token, identità e accessi tra servizi Azure, dove la compromissione di un livello intermedio può propagarsi verso risorse con privilegi più elevati.

Il Config Store permetteva di scegliere ogni organizzazione

La Cosmos Master Key forniva anche accesso al Config Store, un registro regionale contenente i dati necessari a identificare e configurare gli account Azure Cosmos DB. Il database includeva nomi degli account, tenant ID, subscription ID, tag, impostazioni di rete e altre informazioni utilizzate dal gateway per determinare come raggiungere le risorse dei clienti. Poiché il Config Store era a sua volta ospitato su Cosmos DB, la chiave globale poteva recuperarne la chiave primaria e interrogarlo attraverso il motore SQL. Un aggressore non avrebbe quindi dovuto conoscere preventivamente il nome esatto di un database: avrebbe potuto elencare tutti gli account di una regione oppure filtrare i risultati utilizzando l’identificativo del tenant o della sottoscrizione di una specifica organizzazione.

La catena combinava così due capacità distinte ma complementari: enumerazione globale e takeover mirato. Dopo aver individuato gli account della vittima, l’attore avrebbe potuto utilizzare la Master Key per recuperare le chiavi primarie e ottenere pieno accesso ai dati. L’impatto comprendeva anche account configurati con private endpoint o restrizioni di rete, perché il DB Gateway era il componente incaricato di applicare quelle stesse separazioni. La compromissione del punto di controllo permetteva di raggiungere i database dall’interno del perimetro fidato e, secondo i ricercatori, l’accesso in scrittura al Config Store avrebbe potuto consentire anche la modifica delle impostazioni di isolamento. La ricostruzione tecnica pubblicata da Wiz Research descrive quindi una vulnerabilità del piano di servizio, non una configurazione errata attribuibile ai singoli clienti.

Teams, Entra ID e Copilot dipendono dallo stesso livello cloud

Azure Cosmos DB non ospita soltanto database creati direttamente dai clienti, ma viene utilizzato come infrastruttura sottostante da diversi servizi Microsoft. Wiz cita Microsoft Teams, Microsoft Entra ID e Microsoft Copilot tra le piattaforme che memorizzano dati su Cosmos DB, evidenziando la possibilità teorica che la vulnerabilità producesse un impatto a cascata sui servizi costruiti sopra il database. I ricercatori affermano che anche gli account interni di Microsoft erano potenzialmente raggiungibili attraverso la stessa chiave globale. Non risultano tuttavia prove che soggetti esterni abbiano utilizzato CosmosEscape per accedere a dati Microsoft o dei clienti. Il caso mostra una caratteristica strutturale del cloud: un servizio gestito può diventare dipendenza invisibile di numerosi prodotti, perciò una falla nel livello infrastrutturale possiede un raggio d’azione superiore a quello percepibile osservando il singolo componente. Un cliente può proteggere correttamente identità, endpoint privati e firewall, ma tali controlli non fermano un attacco che compromette il servizio responsabile della loro applicazione. L’isolamento multi-tenant deve quindi essere costruito assumendo che qualsiasi input controllato dal cliente sia ostile e racchiudendone l’esecuzione dentro un confine minimo, privo di credenziali globali e di percorsi verso API privilegiate. La stessa esigenza emerge negli ambienti Microsoft 365 e Azure, dove token e identità compromesse possono diventare canali trasversali verso più servizi, come mostrato dalle campagne di device code phishing capaci di aggirare l’MFA.

Microsoft elimina la chiave globale e ridisegna l’architettura

Wiz ha comunicato la vulnerabilità a Microsoft il 20 novembre 2025. Microsoft ha riconosciuto la segnalazione nello stesso giorno e, il 22 novembre, ha distribuito una mitigazione che bloccava il punto di ingresso nella Gremlin API. Secondo la dichiarazione riportata dai ricercatori, il vettore è stato neutralizzato entro 48 ore, mentre nei mesi successivi il team Cosmos DB ha lavorato a una correzione architetturale più ampia, completata in tutte le regioni nel luglio 2026. L’intervento ha eliminato la Cosmos Master Key, rafforzato l’autenticazione tra servizi e introdotto ulteriori protezioni di rete, monitoraggio e capacità di rilevamento. Microsoft ha analizzato i log disponibili senza individuare attività non autorizzate al di fuori delle prove effettuate da Wiz e dichiara che nessun dato dei clienti è stato consultato. Non è richiesta la rotazione delle chiavi né un intervento manuale sugli account, perché la vulnerabilità risiedeva nell’infrastruttura gestita dal provider ed è stata corretta centralmente. CosmosEscape resta però un caso significativo per la sicurezza cloud: la falla non dipendeva da password deboli, ruoli IAM eccessivi o database esposti su Internet, ma dalla combinazione tra esecuzione tenant-controlled, sandbox incompleto e credenziali valide sull’intera piattaforma. La correzione definitiva richiedeva quindi non soltanto una patch, ma la rimozione del segreto globale e la ridefinizione dei rapporti di fiducia tra gateway, configurazione e database.