Azure SRE Agent: una verificación de token multi-tenant permitía que extraños observaran sus incidentes (CVE-2026-32173)

¿De qué se trata?

El 20 de abril de 2026, Yanir Tsarimi (Enclave AI) publicó How We Could Watch Your Azure SRE Agent In Real Time, el informe público de CVE-2026-32173 — una falla de divulgación de información en Azure SRE Agent de Microsoft. La CVE se publicó inicialmente el 2 de abril de 2026, con un puntaje CVSS de 8.6 y la clasificación CWE-287 (Improper Authentication). El Microsoft Security Response Center confirmó la falla, la calificó como crítica y aplicó un parche del lado del servidor; no se requiere acción de los clientes que adopten el producto en GA.

La vulnerabilidad nace en la intersección de dos decisiones de ingeniería bien conocidas: un hub SignalR sobre WebSocket para difundir la actividad de un agente de IA, y una app registration de Entra ID configurada como multi-tenant. Cada una, por separado, es válida. Combinadas sin la verificación de tenant ausente, expusieron a escucha silenciosa entre tenants cada Azure SRE Agent activo hasta el parche de Microsoft.

Cómo funciona

Azure SRE Agent alcanzó disponibilidad general el 10 de marzo de 2026. Es el agente de operaciones siempre activo de Microsoft: conectado a un entorno Azure, vigila alertas, diagnostica incidentes, ejecuta comandos de Azure CLI, reinicia servicios y se integra con PagerDuty y ServiceNow. Para hacer todo esto legible a humanos, el agente transmite cada evento — prompts del usuario, respuestas del modelo, trazas de razonamiento interno, llamadas a herramientas con argumentos, salidas de herramientas — a través de un endpoint WebSocket llamado /agentHub, alojado en el Azure SRE Agent Gateway como un SignalR Hub.

El hub filtraba las conexiones entrantes mediante un bearer token. La lógica de validación verificaba la firma y la audiencia, ambos elementos que cualquier cuenta Entra ID, en cualquier tenant, puede producir frente a una app registration multi-tenant. Faltaban dos controles:

# Lo que el hub validaba (esquema — ilustrativo, no es código de exploit)
token_signature_valid   # ✅
audience_matches_app    # ✅

# Lo que no validaba
caller_tenant == target_agent_tenant   # ❌
caller_has_role_on_resource            # ❌

Una vez establecida la conexión WebSocket, el hub no filtraba los eventos por identidad del llamante. Difundía cada evento a cada cliente conectado. Unirse al flujo de un objetivo sólo requería el subdominio de su agente — descrito por Enclave como predecible y enumerable — y aproximadamente 15 líneas de Python para obtener un token desde login.microsoftonline.com y conectarse al SignalR hub.

La transcripción visible del otro lado incluía los prompts del usuario, las respuestas del agente, la cadena de razonamiento privada del agente, cada invocación de CLI con sus argumentos completos y la salida del comando. En la prueba de Enclave, esa salida contenía credenciales de despliegue de aplicaciones web en producción. El ataque no dejaba huella en el tenant víctima; el único registro existía en el terminal del atacante.

Por qué importa

Tres lecciones tienen más alcance que la propia CVE.

La primera es estructural. Un hub SignalR detrás de Entra ID no es exótico. El error reproduce aquí el mismo patrón de confusión de autorización que afecta a SaaS multi-tenant desde hace una década — token válido ≠ usuario autorizado — aplicado a un flujo de valor inusualmente alto. Todo equipo que conecta un canal en tiempo real a un agente de IA hereda esta superficie de riesgo.

La segunda es la observabilidad. Los agentes de IA agregan por diseño un estado que normalmente está fragmentado entre endpoints: tickets, dashboards, secret stores, pipelines de despliegue, trazas de razonamiento. Cuando un único canal expone esa agregación, el radio de impacto es todo lo que el agente alguna vez tocó, sintetizado para el atacante. Una fuga de API ordinaria pierde los datos de un endpoint. Una fuga de agente pierde la visión del mundo del modelo.

La tercera es la ausencia de telemetría del lado de la víctima. Los tenants no tenían logs para acotar el alcance de la exposición ni señales para investigar a posteriori. Para agentes de IA en operaciones productivas, la telemetría sobre quién consume el flujo dejó de ser negociable.

Defensas

Acciones concretas que se derivan de esta divulgación.

Si ejecutó Azure SRE Agent durante la ventana de preview (entre el 10 de marzo y el parche del lado del servidor), trate ese periodo como potencialmente expuesto: rote credenciales y secretos que pudieran haber pasado por transcripciones de agente o salidas de CLI, y revise los datos de configuración a los que el agente tuvo acceso.

Para cualquier agente propio que transmita actividad sobre WebSocket/SignalR/SSE, valide tenant Y autorización en el propio hub, no sólo la firma del bearer. Trate la claim tid y la ACL del recurso como controles obligatorios antes de suscribir a un cliente a cualquier grupo. Marque las app registrations como single-tenant salvo cuando multi-tenant sea un requisito de producto deliberado — y cuando lo sea, escriba la lógica de aislamiento de tenants explícitamente.

Para SignalR en particular, use groups indexados por tenant o ID de recurso y agregue un filtro de autorización en OnConnectedAsync. Rechace conexiones cuyas claims no incluyan un rol sobre el recurso objetivo. Trate el hub como cualquier otra superficie de API en su modelo de amenazas.

Convierta las transcripciones de agentes de IA en una superficie auditable de primera clase. Emita eventos por suscriptor a su log de seguridad, expóngalos al tenant cliente y alerte sobre suscriptores inesperados. El hecho de que las víctimas de Azure SRE Agent no pudieran ver a los escuchas es el defecto que transformó un bug de autorización en un incidente sigiloso.

Por último, modele los agentes como canales de tránsito de credenciales. Si el agente puede leer secretos para realizar su trabajo, cada canal que expone su traza es un canal de manipulación de secretos y debe clasificarse como tal.

Estado

Elemento	Detalle
CVE	CVE-2026-32173
CVSS	8.6 (HIGH)
CWE	CWE-287 (Improper Authentication)
Publicación (NVD)	2 de abril de 2026
Informe público	20 de abril de 2026 (Enclave AI)
Componente afectado	Azure SRE Agent Gateway, SignalR Hub /agentHub
Fecha GA del producto	10 de marzo de 2026
Corrección	Del lado del servidor, desplegada por Microsoft. Sin acción del cliente.
Reportador	Yanir Tsarimi, Enclave AI