Cinco vulnerabilidades críticas en Azure API Connections permitieron al investigador de Binary Security usar conexiones de otros clientes para actuar contra sus servicios conectados. El impacto no dependía de romper directamente Key Vault, Azure SQL o una aplicación externa: consistía en inducir a la infraestructura de conectores de Azure a utilizar la autorización que ya tenía configurada la conexión de la víctima.
El investigador afirma que los hallazgos descritos le reportaron 200.000 dólares. También indica que Microsoft corrigió las vulnerabilidades tras recibir los informes, aunque la serie muestra cómo una corrección centrada en un endpoint podía dejar abierta otra ruta hacia la misma capacidad.
“In total, the vulnerabilities here netted me a cool $200,000.”
— autor de Binary Security
Una conexión que lleva consigo la autoridad
API Connections forma parte de Azure Logic Apps. Permite que un flujo de trabajo llame a servicios externos sin implementar por separado toda la autenticación y el intercambio de credenciales. Según la descripción de Binary Security, una Logic App consulta una instancia compartida de Azure API Management (APIM); esta valida la operación frente a la definición OpenAPI del conector, intercambia el token recibido por la credencial configurada para el servicio y envía la petición al backend.
Ese backend puede ser un servicio de Azure, como Key Vault o Azure SQL, o una aplicación externa como Jira o Salesforce. Por eso, el límite de seguridad no está solo en quién puede editar una Logic App: también importa si cada petición queda ligada a la conexión concreta que el solicitante tiene permiso para usar. Si APIM acaba operando sobre una conexión ajena, el backend recibe una llamada con la autoridad ya asociada a esa conexión.
flowchart LR A["Logic App o ARM"] --> B["APIM compartido"] B --> C["Valida operación y cambia credencial"] C --> D["Servicio conectado"] E["Conexión de otro cliente"] --> B
El esquema resume el mecanismo descrito por Binary Security: el problema aparecía cuando una petición lograba dirigir la operación hacia una conexión que no pertenecía al cliente que la enviaba. ARM, el plano de administración de Azure, también podía ser una vía para invocar operaciones de las conexiones a través de APIM.
De una ruta de acceso a varias correcciones parciales
El primer caso que el investigador repasa procede de una publicación anterior de su serie. Una vulnerabilidad de recorrido de rutas en el endpoint DynamicInvoke de la API REST de ARM permitió leer un secreto de Key Vault de otro tenant utilizando una conexión propia. El ejemplo publicado por Binary Security muestra una respuesta con el valor del secreto. El investigador dice que Microsoft marcó el fallo como corregido unas semanas después de que lo reportara.
La corrección parecía restringir las rutas aceptadas por DynamicInvoke, no resolver la cuestión de fondo: que la petición pudiera alcanzar la credencial asociada a otra conexión. Para comprobar qué otras superficies había, el investigador extrajo código del tipo de recurso de una Logic App Standard dedicada. Señala que no sabía si ese código se ejecutaba en los sistemas de Microsoft o era un artefacto incluido, pero encontró varias funciones públicas en la misma ruta, entre ellas DynamicList, que no estaban documentadas.
Al probar DynamicList, reprodujo la misma lógica de recorrido de rutas y demostró una escritura en una base de Azure SQL a través de la conexión de la víctima. Según su relato, Microsoft bloqueó los endpoints no documentados tras recibir ese informe. El investigador no describe esa decisión como una corrección de la causa común: plantea que, si esos endpoints volvieran a exponerse, podrían volver a ser vulnerables.
El cambio de superficie no cerró la investigación. El investigador pasó a los propios flujos de Logic Apps y encontró diferencias entre los modelos Consumption y Standard. Las Logic Apps Standard usan un host dedicado y crean conexiones de versión 2, autorizadas mediante la identidad administrada de la Logic App. Las Consumption, cuyos flujos comparten entorno con otros, crean conexiones de versión 1 y no tienen esa identidad propia para autorizar.
A partir de esa diferencia, el investigador dedujo que las Logic Apps Consumption podían tener acceso implícito a las conexiones de versión 1, y que la validación de entradas era la barrera efectiva. Cambiar directamente la referencia al conector de la víctima no funcionaba: el runtime comprobaba que la conexión perteneciera al usuario. Sin embargo, al revisar la definición del flujo encontró el parámetro host.api.RuntimeUrl, que permitía sustituir la URL de runtime incluida en la conexión.
El investigador afirma que, si el host indicado terminaba en azure-apihub.net, la petición seguía incluyendo la cabecera de autorización necesaria. Así podía superar la comprobación de propiedad de la conexión referenciada y dirigir la llamada a otra ruta. Microsoft añadió una comprobación para exigir que la URL coincidiera con el endpoint esperado para esa conexión. Pero, según Binary Security, la validación se hacía antes de normalizar la ruta: el runtime y APIM interpretaban de forma distinta el destino.
La secuencia de correcciones tuvo además un efecto inesperado. El investigador dice que, cuando Microsoft corrigió ese recorrido de rutas, dejó de validarse la ruta original de RuntimeUrl, lo que reabrió el ataque anterior. La investigación ilustra así algo más concreto que una sucesión de errores independientes: varias entradas y rutas llegaban a una capacidad común, y los cambios aplicados a una podían alterar el comportamiento de otra.
El alcance depende de los permisos de cada conexión
El impacto no equivale a obtener automáticamente privilegios ilimitados en todos los servicios conectados. Binary Security reconoce que los propietarios pueden limitar el alcance de tokens y claves. La capacidad obtenida en el backend queda condicionada por los permisos que ya tuviera la conexión: una credencial con acceso restringido ofrece menos margen que una con permisos amplios. El investigador considera que la limitación mínima no es habitual, pero esa apreciación es suya, no una medición de las configuraciones de los clientes.
Para los equipos que usan Logic Apps, la consecuencia práctica es revisar qué autoridad llevan sus conexiones, no solo quién puede modificar sus flujos. Una conexión de Key Vault, SQL o un servicio de terceros puede representar permisos concedidos por una identidad o por la persona que autorizó OAuth. Reducir esos permisos limita el daño potencial si una capa de aislamiento falla; no sustituye la obligación de comprobar que cada llamada solo puede usar la conexión correspondiente.
También importa cómo se evalúan las correcciones en servicios gestionados. En los casos descritos, Microsoft cambió el comportamiento del lado del servicio, por lo que el investigador no habla de instalar un parche en cada Logic App. Pero una restricción de ruta en un endpoint, el bloqueo de funciones no documentadas y una validación de URL antes de normalizarla son defensas distintas. La repetición de fallos en torno a la misma capacidad deja claro por qué una corrección debe verificarse frente a rutas alternativas y transformaciones de la petición.
Binary Security afirma que los cinco fallos críticos fueron corregidos en un plazo razonable después de los informes y expresa satisfacción general con la respuesta, pese a desacuerdos con MSRC. El investigador presentó además el trabajo en Blue Hat Asia 2026. Su publicación no establece que los casos demostrados en pruebas se tradujeran en accesos no autorizados a datos de clientes reales.
La pregunta que queda para las organizaciones no es si cada conexión concede acceso a todo su backend, sino qué operaciones permite realmente cada identidad o credencial, y si sus registros permiten detectar usos fuera de los flujos esperados.
Fuentes: Binary Security AS, The Protec Blog - Guarding Your Future, One Byte at a Time., Glonce, PAN
