Cinco formas de entrar al Azure de otro cliente: lo que encontró Binary Security en las API Connections

Un investigador de la firma de seguridad Binary Security publicó el 30 de octubre de 2026 la tercera parte de su serie Azure's Weakest Link, y el resumen cabe en una línea: encontró cinco vulnerabilidades críticas de elevación de privilegios en las API Connections de Azure, la pieza que usan las Logic Apps para hablar con otros servicios. Cada una permitía lo mismo: tomar la conexión de otro cliente de Azure, en otro tenant, y usar sus credenciales contra su backend. Eso incluye leer secretos de un Key Vault ajeno o escribir en una base de Azure SQL que no es tuya. Según el autor, todas quedaron corregidas y las recompensas sumaron 200,000 dólares. Si tienes flujos en Logic Apps conectados a algo importante, la historia no es solo de chisme: explica dónde vive el riesgo de este tipo de integraciones.

Cómo funcionan las API Connections

Cuando una Logic App se conecta a Key Vault, SQL, Jira o Salesforce, no guarda la credencial dentro del flujo. Microsoft lo documenta así: hay un almacén de credenciales y metadatos que guarda la información de conexión, las listas de acceso (ACL) y las credenciales, y una instancia de Azure API Management (APIM) que es "el punto de entrada para todas las llamadas" a los conectores.

El investigador lo resume en cuatro pasos:

La Logic App llama al APIM compartido.
El APIM revisa en la definición OpenAPI del conector que la acción sea válida.
El token de quien llama se intercambia por el token o la llave configurada en la conexión.
El APIM hace la llamada al backend con esa credencial.

Ese APIM no es tuyo. Es infraestructura compartida entre clientes. Si logras que trabaje sobre una conexión que no te pertenece, usas el token del dueño en su servicio. A eso le dedica la serie: buscar formas de engañar a ese intermediario.

A esto se suma un detalle que el autor marca como advertencia: la conexión opera con los permisos que le dio quien la creó. En conexiones OAuth es el token de la persona que la configuró. En las de API key, escribe, casi nadie se toma la molestia de limitar el alcance.

Las cinco vulnerabilidades

1. DynamicInvoke con path traversal. Fue la que contó en agosto de 2025. Azure Resource Manager (ARM) tiene un endpoint no documentado, DynamicInvoke, que llama al APIM con privilegios que alcanzan a todas las conexiones. Con un conector personalizado y una ruta con ../ codificado, la petición salía de tu conexión y caía en la de otro. Lo reportó a Microsoft el 7 de abril de 2025, lo confirmaron tres días después y hubo mitigación en una semana. En ese momento dijo haber recibido 40,000 dólares. La corrección fue una lista negra que bloquea ../ y algunas variantes codificadas en el parámetro path.

2. DynamicList y sus hermanos ocultos. Al revisar el código de una Logic App Standard (que te da un host dedicado al que puedes entrar por SSH), encontró que junto a DynamicInvoke había otras funciones sin documentar en la misma ruta. Una de ellas, DynamicList, no tenía la lista negra. Con el mismo truco, pasando los segmentos de la ruta como parámetros, consiguió escribir en una base Azure SQL de otro tenant. Microsoft respondió bloqueando esos endpoints. El investigador advierte que no ve otra mitigación, así que si algún día se reabren, supone que volverían a ser vulnerables.

3. Logic Apps Consumption y el parámetro host.api.RuntimeUrl. Aquí cambió de puerta. Las Logic Apps Standard crean conexiones versión 2 y autorizan a la app con su identidad administrada. Las Consumption, que comparten infraestructura con otros clientes, crean conexiones versión 1 y no hay identidad que autorizar. Su conclusión: cada Logic App Consumption tenía acceso implícito a cualquier conexión V1, y lo único que lo frenaba era la validación de entradas. Desde la vista de código del flujo encontró el parámetro host.api.RuntimeUrl, que permite cambiar la URL de ejecución de la conexión. Mientras el host terminara en azure-apihub.net, la plataforma agregaba la cabecera de autorización. Apuntándolo a la conexión de otra persona, el flujo le devolvía el secreto de la víctima.

4. Path traversal dentro del RuntimeUrl. La corrección exigió que el RuntimeUrl coincidiera con el de la conexión. El problema fue el momento de la validación: se revisaba antes de normalizar la ruta. Una URL que empezaba igual a la correcta y luego subía directorios con .. pasaba el filtro, y el APIM terminaba en la conexión ajena.

5. La regresión. Cuando Microsoft corrigió la cuarta, el RuntimeUrl original dejó de validarse y el ataque número 3 volvió a funcionar tal cual.

Diagrama del flujo de API Connections en Azure, con el APIM compartido y el intercambio de tokens, y la lista de las cinco vulnerabilidades con su corrección

El autor cierra diciendo que las cinco se corrigieron en un tiempo razonable y que, aunque hubo diferencias con el MSRC (el centro de respuesta de seguridad de Microsoft), está contento con el resultado. También presentó el trabajo en BlueHat Asia 2026 y dice que agregará el video cuando se publique.

¿Hay CVE?

La publicación no menciona números de CVE. En la Security Update Guide de Microsoft hay varias entradas de 2026 para Azure Logic Apps del tipo "elevación de privilegios", por ejemplo la CVE-2026-21227 (path traversal, severidad crítica, CVSS 8.2, publicada el 22 de enero) y la CVE-2026-42823 (control de acceso indebido, CVSS 9.9, publicada el 12 de mayo). Ninguna de las dos acredita a un investigador en sus datos públicos, así que no puedo confirmar que correspondan a estos reportes. Lo que sí dicen: la 21227 ya está "totalmente mitigada por Microsoft" y no requiere acción; en la 42823, Microsoft indica que avisó a los clientes afectados por Azure Service Health con el ID de seguimiento 1P8-C0G y las instrucciones de remediación. Si administras Logic Apps, vale la pena buscar ese ID en tu portal.

Mi lectura

Lo interesante no son los cinco bugs, es el patrón. El propio investigador lo dice en su resumen: lo único que impedía la explotación eran "capas de validación de entradas" agregadas encima de los sistemas, y es muy difícil cubrir todos los casos raros. Los arreglos que describe atacan el síntoma. Bloquean ../, bloquean un endpoint, exigen que una URL coincida. El fondo sigue igual: hay un intermediario compartido con acceso a las credenciales de todos, y la frontera entre clientes depende de que cada filtro esté bien hecho. La regresión de la vulnerabilidad 5 es justo lo que pasa cuando la seguridad depende de parches sobre parches.

También hay que decir lo otro: Microsoft corrigió todo, pagó bien y el investigador pudo publicarlo. Así debería funcionar.

Qué puedes hacer tú

No hay parche que instalar: son fallas del servicio y, según el autor, ya están corregidas. Lo que sí controlas es cuánto daño haría una conexión comprometida, porque estos ataques heredan exactamente los permisos que le diste. Partiendo de la guía de seguridad de Logic Apps de Microsoft (no lo probé; esto sale de la documentación y del artículo del investigador):

Privilegio mínimo en cada conexión. Microsoft insiste en el principio de menor privilegio para usuarios, apps e identidades administradas. Una conexión a Key Vault que solo lee un secreto no necesita listar ni escribir todos.
Cuidado con las conexiones OAuth personales. Si la conexión usa la cuenta de un administrador, el atacante hereda al administrador. Usa cuentas de servicio o identidades administradas con alcance limitado.
Revisa quién es Contributor. La guía de Microsoft advierte que tener permisos de Contributor o de edición sobre un flujo equivale a tener los permisos de cada identidad administrada asignada a ese flujo.
Bloquea conectores que no uses. La misma guía explica cómo bloquear conexiones a conectores específicos.
Revisa Azure Service Health por el aviso 1P8-C0G y por cualquier notificación de Logic Apps.
Rota credenciales sensibles que vivan en conexiones viejas. La publicación no dice si alguien explotó estas fallas fuera de la investigación, y Microsoft marca las CVE de Logic Apps citadas arriba como no explotadas. Rotar es higiene barata.