I ricercatori di Wiz hanno reso pubblici i dettagli di CosmosEscape, una vulnerabilità in Azure Cosmos DB che, prima della correzione, avrebbe permesso a un attaccante di ottenere accesso in lettura e scrittura ai database di qualsiasi cliente del servizio, in qualunque regione geografica e su tutte le API supportate (SQL, MongoDB, Cassandra, Gremlin). Microsoft ha bloccato il punto d'ingresso entro 48 ore dalla segnalazione, avvenuta a novembre 2025, e ha completato a luglio 2026 la correzione strutturale, eliminando la chiave condivisa a livello di piattaforma. Secondo l'azienda non ci sono evidenze di accessi a dati dei clienti al di fuori dei test dei ricercatori.

Come funzionava l'attacco

Il punto debole era l'API Gremlin, usata per i database a grafo. Cosmos DB traduce le query Gremlin in codice .NET eseguito sul backend del servizio, dentro una sandbox che dovrebbe impedire alle query di fare qualsiasi cosa che non sia un'operazione sul grafo. Le restrizioni, però, non tenevano adeguatamente conto della reflection di .NET, il meccanismo che consente al codice di ispezionare e invocare dinamicamente tipi e metodi arbitrari a runtime.

Sfruttando questa lacuna, i ricercatori hanno costruito passo dopo passo primitive di lettura e scrittura di file sul backend, fino ad arrivare all'esecuzione di codice arbitrario tramite query opportunamente costruite. Da lì hanno estratto quella che Wiz chiama la Cosmos Master Key: un segreto di livello piattaforma che permetteva di recuperare su richiesta la chiave primaria di qualunque account Cosmos DB e di enumerare i database del servizio, filtrandoli anche per identificativo dell'organizzazione. In pratica, una sola chiave apriva tutti i database della piattaforma.

Un déjà-vu per Cosmos DB

Non è la prima volta che il database di punta di Azure finisce al centro di una ricerca del genere: nel 2021 la falla ChaosDB, sempre scoperta da Wiz, aveva già esposto le chiavi primarie dei clienti attraverso i notebook Jupyter integrati. Il copione si ripete: una funzionalità accessoria eseguita lato servizio diventa il ponte verso segreti condivisi che non dovrebbero esistere. La differenza, positiva, è nella risposta: blocco in 48 ore, e soprattutto la rimozione definitiva della chiave master a livello di piattaforma, che elimina la classe di problema e non solo il singolo bug.

Cosa significa per le aziende italiane

Per le tante realtà italiane che hanno spostato dati e applicazioni su Azure, CosmosEscape è un promemoria scomodo: nel modello di responsabilità condivisa esiste una fascia di rischio che il cliente non può né vedere né mitigare direttamente. Nessuna configurazione lato cliente avrebbe impedito l'estrazione della chiave master, e nessun log a disposizione del cliente avrebbe mostrato un accesso avvenuto per quella via.

Questo ha due conseguenze concrete. La prima riguarda la gestione delle vulnerabilità: le falle dei servizi cloud gestiti spesso non ricevono una CVE — è il caso anche di CosmosEscape — e quindi non compaiono negli scanner né nei bollettini tradizionali. Chi basa il proprio vulnerability management solo sul catalogo CVE ha un punto cieco strutturale sul cloud. La seconda riguarda la governance: per i soggetti finanziari sottoposti a DORA, un servizio come Cosmos DB rientra a pieno titolo tra i servizi ICT di terze parti da censire nel registro delle informazioni, con tanto di valutazione del rischio di concentrazione. Un difetto che tocca contemporaneamente tutti i tenant di una piattaforma è l'esempio da manuale di rischio sistemico da fornitore cloud.

C'è infine il tema dell'autenticazione a chiave. La gravità di CosmosEscape derivava in gran parte dal fatto che il possesso della chiave primaria di un account equivale ad accesso completo ai dati: un modello "tutto o niente" che Microsoft stessa invita da tempo a superare a favore dell'autenticazione basata su Microsoft Entra ID con controllo degli accessi a ruoli.

Cosa fare subito

  • Se usate Cosmos DB, non è richiesta alcuna patch: la correzione è interamente lato Microsoft. Ha però senso ruotare le chiavi primarie e secondarie se non lo fate periodicamente.
  • Migrate l'autenticazione delle applicazioni da chiavi condivise a Microsoft Entra ID con RBAC e, dove possibile, disabilitate del tutto l'autenticazione basata su chiave (proprietà disableLocalAuth).
  • Limitate l'esposizione di rete degli account: endpoint privati, firewall a livello di account e niente accesso pubblico se non necessario.
  • Attivate e conservate i log del piano dati (diagnostic settings) per avere visibilità sugli accessi ai database.
  • Inserite le vulnerabilità dei servizi cloud gestiti nel vostro modello di rischio: seguite i bollettini dei provider e dei ricercatori (MSRC, Wiz, ecc.), non solo il flusso CVE.
  • Se siete soggetti DORA o NIS2, verificate che i servizi dati gestiti compaiano nel registro dei fornitori ICT con una valutazione aggiornata del rischio di concentrazione.

CosmosEscape si chiude senza vittime accertate, ma la lezione resta: nel cloud la domanda giusta non è solo "quanto è sicura la mia configurazione", bensì anche "cosa succede se a sbagliare è il mio provider".