Una CosmosEscape falla crítica en el servicio de base de datos Azure Cosmos DB habría abierto la puerta a un tipo de ataque especialmente grave: comprometer, potencialmente, bases de datos en toda la plataforma. Según la firma de ciberseguridad Wiz, el problema permitiría a un atacante obtener una clave a nivel de plataforma y, con ella, recuperar información necesaria para acceder y operar sobre cuentas de Cosmos DB.
La investigación describe cómo, partiendo de un fallo que el equipo de Wiz rastreó con el nombre de CosmosEscape, un adversario podría pasar de leer metadatos hasta lograr acceso de lectura y escritura a las bases de datos objetivo. Este artículo explica, en términos claros, qué se reportó y cómo se corrigió la situación.
Qué es la CosmosEscape falla y por qué preocupaba
De acuerdo con Wiz, la vulnerabilidad afectaba a Azure Cosmos DB y podía haber permitido a un atacante comprometer todas las bases de datos del servicio. El punto central del riesgo era la capacidad de obtener una clave “global” que habilitaba acciones sobre cuentas de cualquier cliente.
Con la información adecuada, un atacante podía recuperar la clave primaria de cualquier cuenta de Cosmos DB. En la práctica, eso equivalía a alcanzar control total de lectura y escritura en toda la plataforma, según el escenario descrito por la firma.
Del acceso a las claves al control de bases de datos
Wiz afirma que, gracias a la clave a nivel de plataforma, un atacante podría listar bases de datos y además filtrarlas por identificadores de organización, como subscription IDs y tenant IDs. Así, la amenaza no sería solo “general”, sino que podría volverse precisa: identificar primero y comprometer después.
En palabras de la firma, al encadenar capacidades sería posible atacar objetivos específicos en escala, partiendo de endpoints públicamente accesibles, y llegando a la intrusión sobre bases de datos asociadas a entidades concretas.
El papel de Entra ID, Teams y Copilot
El informe de Wiz también resalta un aspecto de impacto potencial para Microsoft. La firma indica que Microsoft usa Cosmos DB para almacenar datos relacionados con Entra ID, Teams y Copilot. Por ese motivo, la CosmosEscape falla podría haber expuesto bases de datos del ecosistema a acceso no autorizado.
Es importante subrayar que, según el comunicado citado, no se evidenció acceso indebido fuera del entorno de pruebas del investigador y no se accedió a datos de clientes.
Cómo se explotaba: Gremlin y el bypass del sandbox
La explotación, según Wiz, podía realizarse mediante la Gremlin API. Gremlin es un lenguaje de consultas orientado a grafos que utiliza un motor Gremlin personalizado. Ese motor compila las consultas en código .NET que luego se ejecuta en un entorno restringido (un sandbox).
El motor imponía restricciones para evitar accesos fuera de las operaciones permitidas por Gremlin. Sin embargo, Wiz sostiene que esas medidas no contemplaban el uso de reflexión en .NET, lo que permitió construir “primitivas” de ejecución de código arbitrario.
Bypass del sandbox y ejecución en el DB Gateway
Al eludir el sandbox, Wiz afirma que el atacante podría conseguir ejecución de código en el DB Gateway. Este gateway es el componente que ejecuta consultas de clientes en nombre de los usuarios y que opera sobre clústeres de Service Fabric compartidos entre múltiples clientes (multi-tenant).
La consecuencia descrita es que el entorno de ejecución no solo aceptaba consultas, sino que, bajo el vector reportado, podía usarse para alcanzar capacidades más amplias que las previstas.
La “Cosmos Master Key” y el acceso transversal
Wiz también explica que el DB Gateway utilizaba una clave de firma para recuperar las claves primarias de las cuentas de los clientes. Lo más delicado, según la investigación, era que esa clave de firma funcionaba de manera amplia, atravesando tenant, regiones e incluso APIs.
La firma bautizó a ese elemento como “Cosmos Master Key”. Con ella, un atacante que explotara CosmosEscape podría recuperar la clave primaria de cualquier cuenta de Cosmos DB a través de endpoints públicamente accesibles.
El Config Store: el catálogo que facilitaba el ataque
Una vez obtenida la clave maestra, Wiz afirma que el atacante podía acceder a un configuration store que guardaba detalles de todas las cuentas de Cosmos DB. Ese repositorio incluía información como nombres, subscription IDs, tenant IDs y otros datos de configuración.
Según el informe, el Config Store en sí era una base de datos de Cosmos DB, lo que permitía consultarlo con la flexibilidad del motor SQL. Además, como el catálogo era consultable, la clave maestra podía recuperar su propia clave primaria, reforzando el ciclo de acceso.
Enumeración, filtrado y obtención de claves objetivo
Con el acceso a ese catálogo y a la clave maestra, el escenario de ataque descrito por Wiz se vuelve más operativo: enumerar cuentas, filtrarlas por identificadores (por ejemplo tenant) y luego obtener la clave primaria de la organización objetivo para conseguir lectura y escritura completas sobre sus bases de datos.
Alcance: cuentas aisladas, privadas y hasta bases de Microsoft
Wiz sostiene que el ataque podría montarse no solo contra cuentas públicas, sino también contra cuentas privadas o con aislamiento de red. Además, la firma afirma que el vector también podía afectar a bases de datos de Microsoft.
Esto amplía el riesgo porque sugiere que la mitigación mediante controles de red no habría sido suficiente, al menos frente al tipo de bypass y obtención de claves que describe la investigación.
Reporte a Microsoft y correcciones aplicadas
De acuerdo con Wiz, la vulnerabilidad fue reportada a Microsoft en noviembre de 2025. La firma indica que, dentro de dos días, Microsoft desplegó un hotfix para bloquear el vector de ataque.
Posteriormente, en julio, Microsoft completó el despliegue de una corrección arquitectónica de largo plazo en todas las regiones. Es decir, no se trató únicamente de un parche temporal, sino de un ajuste estructural para evitar que el problema persistiera.
¿Hubo actividad maliciosa? Qué se informó
Microsoft habría realizado revisiones extensas de los access logs y, según el texto citado, no encontró evidencia de actividad no autorizada fuera del marco de las pruebas realizadas por el equipo investigador. Asimismo, se indicó que no se accedió a datos de clientes.
También se remarca que no se requiere acción de los clientes, según el comunicado reproducido en el artículo fuente.
Qué pueden aprender los equipos de seguridad
Aunque el caso describe una corrección ya aplicada, la CosmosEscape falla deja varias lecciones útiles. Primero, la investigación muestra que un sandbox puede fallar cuando existen rutas no contempladas en componentes como .NET. Segundo, el acceso transversal mediante claves a nivel de plataforma puede convertir un problema localizado en uno de alcance masivo.
Por último, el informe subraya la importancia de auditar cómo funcionan los mecanismos de ejecución en componentes compartidos (como gateways multi-tenant) y de revisar si hay llaves o capacidades con alcance mayor al estrictamente necesario.
Conclusión
La investigación de Wiz sobre la CosmosEscape falla describe un escenario crítico: obtener una clave a nivel de plataforma, recuperar claves primarias y avanzar hacia acceso total de lectura y escritura en bases de datos de Azure Cosmos DB. La corrección, reporta el artículo, incluyó primero un hotfix en días y luego un cambio arquitectónico implementado en todas las regiones.
En este caso, el mensaje para los usuarios es claro: no se registró evidencia de acceso indebido fuera de las pruebas del investigador y no se exige acción. Aun así, la historia refuerza la necesidad de controles robustos contra bypass de sandboxes y de evitar que una sola clave habilite impactos a escala.
Fuente: https://www.securityweek.com/critical-flaw-led-to-azure-cosmos-db-pwnage/
