Investigadores de Wiz lograron escapar del sandbox del motor Gremlin de Azure Cosmos DB y llegar a la «Cosmos Master Key», el secreto de firma que abría cuentas de cualquier inquilino en todas las APIs y regiones del servicio.
Microsoft ya corrigió la falla, bautizada CosmosEscape, y afirma no haber encontrado evidencia de impacto en clientes. No hay acción requerida del lado de los usuarios.
De una consulta Gremlin a ejecución de código
El motor Gremlin de Cosmos DB traduce las consultas a código .NET que corre en un entorno restringido. Ese es el punto de partida del ataque.
Los investigadores usaron reflexión de .NET para saltear las restricciones y construir primitivas de lectura y escritura de archivos, antes de llegar a ejecución arbitraria de código.
Como demostración ejecutaron un comando hostname en el backend. El resto de la cadena de explotación quedó reservado para una presentación en Black Hat USA el 6 de agosto.
Qué quedó expuesto
El alcance de lo alcanzado desde el backend es lo más significativo del hallazgo:
- La Cosmos Master Key a nivel plataforma, un secreto de firma que abría todas las cuentas probadas.
- Un directorio regional de Config Store con nombres de cuenta, IDs de suscripción y de inquilino, configuración de red y tags.
- Las claves primarias de las cuentas apuntadas.
La clave maestra funcionó contra todas las variantes de API del servicio: SQL, MongoDB, Cassandra y Gremlin. Wiz verificó que la región de un inquilino contenía miles de bases de datos internas de Microsoft.
El aislamiento de red no protegía
Este es el detalle que más debería incomodar a cualquiera que haya diseñado su postura de seguridad alrededor de Private Link y reglas de firewall.
El ataque podía alcanzar cuentas privadas y aisladas por red, porque los gateways comprometidos eran justamente los que aplicaban esos límites de manera interna.
Dicho de otro modo: el control que uno configura como frontera dura estaba, en este caso, del lado equivocado de la falla.
Ocho meses entre el reporte y el cierre completo
La línea de tiempo del caso también dice algo sobre la escala del problema.
- Reporte a Microsoft: 20 de noviembre de 2025, con acuse de recibo el mismo día.
- Hotfix que bloqueó el punto de entrada vulnerable de la API Gremlin: 22 de noviembre, es decir 48 horas después.
- Corrección arquitectónica completa desplegada en todas las regiones de Azure: julio de 2026.
- Divulgación pública: 30 de julio de 2026.
Hay un detalle del hallazgo que conecta con lo que viene pasando este año: parte del trabajo se hizo con Atlas, el sistema autónomo de investigación de vulnerabilidades de Wiz, presentado públicamente el 27 de julio de 2026.
La reacción inicial fue rápida. Lo que llevó ocho meses fue propagar el arreglo definitivo por toda la superficie del servicio, que es exactamente la clase de trabajo que un cliente no ve ni puede acelerar.
Qué implica para quien opera en Azure
No hay parche que aplicar ni configuración que cambiar: la falla estaba en el plano de control del proveedor, no en el tenant del cliente.
Lo que sí queda como tarea es el ejercicio de modelado de amenazas. Si el servicio administrado que usás guarda una clave que abre todo, tu aislamiento vale lo que valga la custodia de esa clave.
De ahí que sigan teniendo sentido las prácticas básicas que no dependen del proveedor: rotación periódica de claves de cuenta, uso de identidades administradas y RBAC de datos en lugar de claves compartidas, y auditoría de accesos.
¿Cuánta de tu seguridad depende de un control que no podés verificar?
El modelo de responsabilidad compartida está escrito en todos los contratos, pero rara vez se traduce en una lista concreta de supuestos que uno acepta al elegir un servicio administrado.
¿Tienen documentados esos supuestos para sus bases de datos en la nube? Te leemos en los comentarios.
Fuentes
