TL;DR:
- Wiz publicó CosmosEscape, una cadena de fallas ya corregida en el API Gremlin de Azure Cosmos DB que daba lectura y escritura sobre cualquier base de datos del servicio.
- La llave de firma que encontraron no estaba acotada a una cuenta: funcionaba entre inquilinos, entre regiones y en las APIs de SQL, MongoDB, Cassandra y Gremlin, incluidas las bases privadas y aisladas por red.
- Microsoft desplegó una mitigación 48 horas después del reporte del 20 de noviembre de 2025, terminó el rediseño en julio de 2026 y afirma que ningún dato de clientes fue consultado.
Wiz destapó este 30 de julio de 2026 los detalles de CosmosEscape, una cadena de vulnerabilidades ya corregida en Azure Cosmos DB que habría permitido a un atacante leer y escribir en cualquier base de datos alojada en el servicio, incluidas las que Microsoft ocupa para sus propios productos. La firma, hoy propiedad de Alphabet, dice que llegó hasta una llave de plataforma que bautizó como Cosmos Master Key y que servía para dos cosas: pedir la clave primaria de cualquier cuenta y listar todas las cuentas de una región, con la opción de filtrarlas por empresa. Microsoft respondió que el problema quedó resuelto en cooperación con Wiz y que su investigación no encontró evidencia de impacto en clientes, de acuerdo con Reuters. Ningún usuario del servicio tiene que rotar claves ni tocar su configuración.
La puerta de entrada fue el API Gremlin, la interfaz que Cosmos DB ofrece para bases de datos de grafos. Yuval Avrahami y Lior Maman, que firman la publicación, andaban probando consultas cuando les saltó una excepción de .NET donde no tenía por qué haberla. Casi todas las implementaciones abiertas de Gremlin corren sobre Java, así que ese mensaje de error delató algo: Microsoft había escrito su propio motor.
Ese motor traduce cada consulta a código .NET y lo ejecuta dentro de un entorno restringido. Las restricciones no contemplaron bien la reflexión de .NET. Por ahí los investigadores armaron primitivas para leer y escribir archivos, y de ahí saltaron a ejecutar comandos en la infraestructura del servicio, todo con consultas lanzadas contra su propia base de datos.
El código terminó corriendo en el DB Gateway, el componente que ejecuta las consultas de los clientes sobre clústeres multiinquilino de Service Fabric. Las bases de los clientes no viven ahí, pero el gateway tiene que alcanzarlas de algún modo, y lo hace como cualquier otro cliente: con la clave primaria de la cuenta, esa que otorga control total sobre sus recursos.
La llave de firma no estaba amarrada a ninguna cuenta
Entre las credenciales disponibles en el clúster había una llave capaz de firmar la petición que recupera la clave primaria de una cuenta. Wiz descubrió que no tenía límites. Servía de un inquilino a otro, entre regiones y a través de los distintos sabores de API del servicio. Con eso en la mano, la cadena de ataque quedaba así:
- Consultar el Config Store, un registro regional con los nombres de cuenta, identificadores de suscripción y de inquilino, ajustes de red y etiquetas de cada cuenta de Cosmos DB.
- Filtrar ese registro por inquilino o por suscripción hasta dar con las bases de una empresa concreta.
- Pedir la clave primaria de ese objetivo y quedarse con permisos de lectura y escritura sobre todo lo que guarde.
El alcance cubría SQL, MongoDB, Cassandra y Gremlin, y también las cuentas privadas y aisladas por red: como el propio gateway es el que aplica ese aislamiento, comprometerlo abría la puerta directa. Wiz agrega que su acceso de escritura al Config Store sugería la posibilidad de reescribir la configuración de red de una cuenta ajena, aunque el reporte no dice que lo hayan demostrado contra un cliente.
Microsoft dice que no hubo impacto y el expediente público deja huecos
Microsoft sostiene que revisó a fondo los registros de acceso, que no halló actividad no autorizada fuera de las pruebas de los investigadores y que ningún dato de clientes fue consultado. Añade que hizo pruebas de penetración adicionales buscando vectores parecidos, sin encontrar ninguno, y que reforzó la autenticación entre servicios junto con nuevas protecciones de red y capacidades de monitoreo.
Lo que el expediente público no dice también cuenta. The Hacker News apuntó que la divulgación no trae identificador CVE ni puntaje de severidad, que no se precisa cuándo entró en producción el motor vulnerable y que tampoco se aclara qué periodo abarcó la revisión de bitácoras. Sin esos datos, la ventana real de exposición sigue sin conocerse, por más que el camino ya esté cerrado.
Otro matiz ordena la lectura: la cadena publicada arranca con una base de datos Gremlin controlada por el atacante y sus credenciales, no con acceso previo a la víctima. Cualquiera con una cuenta propia de Cosmos DB era un punto de partida válido.
Karl Fosaaen, vicepresidente sénior de la firma NetSPI, calificó el hallazgo ante Reuters como una mala noticia y recordó que Cosmos DB suele cargar con información sensible, aunque matizó que este tipo de descubrimientos aparece de forma periódica en los servicios de nube. Vaisha Bernard, copropietario de la neerlandesa Eye Security, dijo al mismo medio que los investigadores llevan una racha de vulnerabilidades graves en proveedores de infraestructura y que, si alguien más hubiera dado con esta antes que Wiz, el daño pudo haber sido considerable.
El director de tecnología de Wiz, Ami Luttwak, explicó a Reuters dónde acaba viviendo la información en ese servicio:
"Cuando construyes en la nube, y cuando es en Microsoft, normalmente está en CosmosDB."
Cinco años después de ChaosDB, esta vez el cliente no rota nada
En 2021, el mismo equipo encontró ChaosDB, otra falla en Cosmos DB, esa vez por la función de Jupyter Notebook. El desenlace fue distinto: Microsoft avisó por correo a miles de clientes y les pidió regenerar sus claves primarias, una tarea que la propia empresa no podía hacer por ellos. En 2022 llegó CosMiss, también ligada a los notebooks. CosmosEscape entró por otra puerta.
La diferencia práctica está en quién carga con el trabajo. Al eliminar la llave maestra y endurecer la autenticación interna, Microsoft cerró el problema del lado de la plataforma, y por eso repite que no hace falta ninguna acción del cliente. Ese arreglo tiene una contraparte incómoda, y es que el cliente tampoco tiene manera de comprobarlo por su cuenta. Hackread recomienda revisar de todos modos la actividad de la cuenta, los accesos a claves y las operaciones inesperadas sobre las bases, dentro del monitoreo habitual.
La revelación salió por el canal de divulgación coordinada del MSRC, el mismo modelo que Microsoft defendió públicamente en mayo cuando un investigador publicó fallas de sus productos sin avisarle antes.
Alejandro Castillo Leone
La firma que destapó la falla ahora pertenece a Google
Wiz no es la misma empresa que en 2021. Google cerró su compra el 11 de marzo de 2026 por 32,000 millones de dólares en efectivo, la adquisición más grande de su historia, y la integró a Google Cloud conservando la marca y el trabajo multinube. Dicho de otro modo, el equipo que acaba de publicar cómo tomar el control de la base de datos insignia de Azure trabaja hoy para el competidor directo de ese servicio. Por el reporte de ChaosDB, en 2021, Microsoft le pagó a Wiz 40,000 dólares.
Hay un detalle del método que dice bastante sobre hacia dónde va este oficio: Wiz señala que la investigación se apoyó en una versión temprana de Atlas, su investigador de vulnerabilidades asistido por IA. Robert Costello, director digital y de información de Merlin Group, comentó a Hackread que la IA está acelerando el ritmo y la sofisticación con que se descubren fallas, lo que vuelve más urgente la gestión de superficie de ataque. Ese mismo movimiento se ve en la apertura de herramientas de seguridad automatizada que otras empresas del sector empujan este año.
La cadena completa, con la consulta que ejecutó comandos en el backend, se presenta el 6 de agosto en Black Hat USA, en una charla titulada "One Key to Rule Them All: Taking Over a Flagship Cloud Service".
Qué cambia para las empresas hispanohablantes
Azure abrió su primera región en la nube en México con opción de residencia de datos dentro del país, y su mapa de geografías incluye España, Chile y Brasil. Ese argumento, el de que la información no cruza la frontera, se volvió central para bancos, gobiernos y aseguradoras de la región cuando migraron cargas a la nube. CosmosEscape muestra su límite: la falla vivía por debajo de cualquier configuración del cliente, así que ni el firewall de la cuenta ni la elección de región habrían servido de escudo. Hackread lo resume así: no había nada que un cliente pudiera arreglar cambiando su código o sus ajustes de Azure.
El Config Store, además, era regional. Un atacante con la llave podía pedir el listado completo de cuentas de una región y después afinar por identificador de inquilino hasta ubicar a una empresa específica, sin necesidad de tocarla antes.
Preguntas rápidas sobre CosmosEscape
¿Tengo que hacer algo si mi empresa usa Azure Cosmos DB?
No. Microsoft eliminó la llave de plataforma y terminó de desplegar el rediseño en todas las regiones en julio de 2026, así que no pide ninguna acción del cliente ni rotación de claves. Hackread sugiere, de todas formas, revisar la actividad de la cuenta y los accesos a claves como parte del monitoreo normal.
¿Hubo robo de datos por esta vulnerabilidad?
Microsoft afirma que revisó los registros de acceso y no encontró actividad no autorizada fuera de las pruebas de Wiz, ni acceso a datos de clientes. La divulgación no precisa qué periodo abarcó esa revisión ni desde cuándo existía la falla, así que la exposición previa no está documentada públicamente.
¿Es lo mismo que ChaosDB, la falla de 2021?
No. ChaosDB en 2021 y CosMiss en 2022 entraron por la función de Jupyter Notebook de Cosmos DB. CosmosEscape entró por el API Gremlin y llegó hasta una llave de firma que valía para toda la plataforma. Coinciden en el servicio afectado, no en la puerta de entrada.
Cosmos DB sostiene a Microsoft Teams, Entra ID y Copilot, además de aplicaciones de miles de empresas que ni siquiera saben que corre por debajo. Durante un lapso que nadie ha precisado en público, esa capa dependió de una sola llave de firma sin límites. Microsoft ya la eliminó; cuánto tiempo estuvo ahí sigue sin publicarse.
