Een Azure Cosmos DB-kwetsbaarheid kreeg recent veel aandacht nadat beveiligingsbedrijf Wiz een technisch scenario beschreef waarmee een aanvaller extreem ver kon gaan. In het rapport staat de fout bekend als CosmosEscape en gaat het om een mogelijkheid om via publieke interfaces platformbrede sleutels te bemachtigen. Daarmee werd het in theorie mogelijk om database-toegang op service-niveau te verkrijgen.
Wiz stelt dat de bevindingen niet alleen gevolgen kunnen hebben voor accounts van klanten, maar ook relevant kunnen zijn voor datastromen die Microsoft gebruikt in zijn eigen diensten. Microsoft heeft de aanvalsvector inmiddels geblokkeerd en daarnaast gewerkt aan een structurele oplossing.
Wat is CosmosEscape en waarom is het zo ernstig?
De kern van CosmosEscape is dat een aanvaller een platform-wide key kon verkrijgen. Met die sleutel konden onderzoekers vervolgens de primaire sleutel van elk Cosmos DB-account ophalen. In beveiligingstermen betekent dat: volledige read en write-rechten binnen de service, zonder dat daarvoor per se extra authenticatie nodig was.
Vervolgens kon de aanvaller de service gebruiken om databases op te sommen. Belangrijk detail is dat er gefilterd kon worden op organisatieniveaus, bijvoorbeeld via subscription- en tenant-ID’s. Daarmee ontstaat een pad van “vinden” naar “gericht aanvallen”.
Wiz benadrukt dat deze keten op platform-schaal nauwkeurige targeting mogelijk maakt: je kunt eerst identificeren welke databases bij een specifieke organisatie horen, om ze daarna te compromitteren. Dat alles zou in hun beschrijving kunnen via publiek toegankelijke endpoints.
Rol van Gremlin en de sandbox die niet genoeg bleek
De exploitroute loopt via de Gremlin API. Gremlin is een grafquerytaal en maakt gebruik van een eigen engine die queries compileert naar .NET-code die in een sandbox wordt uitgevoerd. Die sandbox moest normaliter voorkomen dat code verder kon gaan dan de toegestane Gremlin-operaties.
Volgens Wiz hield de bescherming echter onvoldoende rekening met .NET reflection. Daardoor konden onderzoekers de sandbox-effecten omzeilen en uiteindelijk code execution realiseren op de DB Gateway.
De DB Gateway voert query’s uit namens klanten en draait op multi-tenant clusters. Dat maakt het extra riskant: als de uitvoering op gateway-niveau misbruikt kan worden, kan de impact potentieel verder reiken dan één specifieke klantcontext.
De “Cosmos Master Key” en wat je ermee kunt
Wiz ontdekte dat de gateway werkte met een signing key om de primaire sleutels van klantaccounts op te halen. Cruciaal daarbij: die signing key zou volgens het rapport werken over tenants, regio’s en zelfs over API’s heen.
Uit die bevinding concludeerde Wiz dat er sprake was van een platformbrede sleutel. Om die reden noemden zij dit de Cosmos Master Key.
Met die master key konden onderzoekers vervolgens een configuration store raadplegen. Dat opslagonderdeel bevat details over Cosmos DB-accounts, waaronder accountnamen, subscription IDs, tenant IDs en andere configuratie-informatie.
Van configuratie naar volledige database-toegang
De configuration store bleek volgens Wiz zelf opnieuw een Cosmos DB-database te zijn. Dat betekent dat je er met de SQL-engine van Cosmos DB op kunt zoeken en query’s kunt uitvoeren met dezelfde flexibiliteit als op andere Cosmos DB-data.
Daar zit een belangrijke versnelling in: omdat de master key primaire sleutels kon ophalen, kon diezelfde sleutel ook worden gebruikt om de primaire sleutel van de configuration store te bemachtigen. Hierdoor kon de aanval praktisch worden: je kunt accounts opsommen in een regio of gerichter filteren op tenant-ID’s om precies de doelorganisatie te vinden.
Wiz beschrijft het scenario als volgt: een aanvaller met de master key én toegang tot de configuration store kan alle Cosmos DB-accounts enumereren, selecteren wat nodig is en daarna de primaire sleutel van een doel terughalen. Daarmee verwerft de aanvaller volledige read/write-toegang tot de bijbehorende databases.
Toepassing op private en geïsoleerde accounts
Volgens Wiz kon de aanval ook worden uitgevoerd tegen private en network-isolated Cosmos DB-accounts. Daarnaast noemt Wiz dat ook de eigen databases van Microsoft door de beschreven route potentieel geraakt konden worden.
Het bedrijf verbindt hier ook een bredere impact aan: Microsoft gebruikt Cosmos DB voor opslag van data in verband met Entra ID, Teams en Copilot. Daardoor zou de kwetsbaarheid theoretisch kunnen bijdragen aan ongeautoriseerde toegang tot dat soort omgevingen.
Melding, fixes en wat klanten moesten (niet) doen
Wiz rapporteerde de kwetsbaarheid in november 2025 aan Microsoft. Binnen twee dagen zette Microsoft een hotfix in om de aanvalsvector te blokkeren. Later, in juli, rondde Microsoft de uitrol van een langetermijnarchitectuurfix af in alle regio’s.
Microsoft gaf daarnaast aan uitgebreide toegangslijsten te hebben onderzocht. Daarbij zou geen bewijs zijn gevonden van ongeautoriseerde activiteit buiten de testwerkzaamheden van de onderzoekers. Ook stelt Microsoft dat er geen klantdata is benaderd.
Volgens het bericht was er geen actie vereist voor klanten. Dat betekent dat de mitigatie via Microsoft zelf is opgepakt.
Waarom dit ook bredere lessen geeft
Los van deze specifieke bug laat CosmosEscape zien hoe belangrijk het is om “sandboxdenken” te toetsen aan de werkelijke programmeer- en runtimemogelijkheden. Als een omgevingsbeperking niet alle relevante technische paden afdekt, kan een aanvaller alsnog naar code execution bewegen.
Ook is het signaal duidelijk: als sleutels of configuratiegegevens platformbreed herbruikbaar zijn, vergroot dat de impact van een individuele fout tot een servicebrede gebeurtenis. Organisaties die cloudplatformen afnemen doen er daarom goed aan om alert te blijven op security advisories en de impact per dienst te begrijpen.
Samengevat: de Azure Cosmos DB-kwetsbaarheid CosmosEscape is een voorbeeld van een hoog-impact issue met kettingeffecten—maar met een snelle hotfix en een bredere architecturale correctie achteraf.
Bron: https://www.securityweek.com/critical-flaw-led-to-azure-cosmos-db-pwnage/
