CVE-2026-35435: los agentes M365 publicados desde Azure AI Foundry confiaron en quien no debían

¿De qué se trata?

El 7 de mayo de 2026, Microsoft divulgó CVE-2026-35435, una vulnerabilidad de elevación de privilegios en Azure AI Foundry que afecta a los agentes Microsoft 365 publicados. La falla está calificada con CVSS 8.6 (CRÍTICA) y clasificada como CWE-284 — Improper Access Control. Según el aviso de Microsoft y la cobertura posterior de Qualys, SecurityWeek y CybersecurityNews, la divulgación acompañó al Patch Tuesday de mayo de 2026 y Microsoft describe el problema como explotado en estado salvaje. En el momento de la divulgación no había un parche completo disponible; Microsoft publicó en su lugar un conjunto de controles compensatorios.

El bug reside en la ruta de autorización de los agentes publicados desde Azure AI Foundry hacia Microsoft 365. Un atacante remoto no autorizado puede eludir los controles de acceso del runtime y escalar de un rol con privilegios bajos a uno con un control extenso sobre los flujos de trabajo del agente, sus conectores de datos y los recursos a los que el agente estaba conectado.

Cómo funciona

Azure AI Foundry permite a las organizaciones construir agentes basados en LLM — asistentes de búsqueda, triadores de tickets, analizadores de documentos — y publicarlos en las superficies de Microsoft 365 (Teams, Outlook, SharePoint, endpoints de Copilot). Una vez publicado, el agente se ejecuta con un service principal que mantiene permisos delegados sobre los conectores y las fuentes de datos que se le entregaron en tiempo de diseño.

CVE-2026-35435 vive en la capa de autorización que filtra las llamadas a ese agente publicado en runtime. Según múltiples análisis que citan el aviso de Microsoft, el runtime del agente no vinculaba de manera consistente la identidad y el rol del llamador a una sesión validada en el servidor. El material de identidad provisto por el llamador — o su ausencia — se trataba como evidencia suficiente de autorización. El resultado, en el lenguaje de CWE-284, es que el agente aceptaba solicitudes de principals que debería haber rechazado y las enrutaba a flujos reservados para roles con forma de propietario.

Concretamente, las acciones post-explotación descritas en la cobertura pública incluyen: republicar o modificar la configuración de un agente con permisos elevados, abusar de las integraciones Microsoft 365 existentes del agente para leer correo y archivos o suplantar al usuario por el que el agente hablaba, y pivotar lateralmente dentro de un workspace de Azure AI Foundry hacia otros agentes y servicios conectados.

# Clase conceptual — ilustrativo, no código de explotación
llamador ─▶ runtime del agente
              ├── confía en la identidad declarada por el llamador   ❌
              └── enruta la llamada a un flujo de rol owner
                  ├── modificar la configuración del agente
                  ├── reutilizar permisos M365 delegados (correo, archivos)
                  └── pivotar a agentes hermanos del workspace

La vulnerabilidad no requiere interacción del usuario y es accesible por red. Es un bug de autorización puro — sin corrupción de memoria, sin prompt injection — pero se asienta sobre un runtime de agente LLM, por lo que el radio del impacto se dimensiona por todo lo que el agente tenía permitido hacer en nombre del usuario.

Por qué importa

Tres puntos merecen ser anclados.

Primero, la identidad es ahora la superficie de ataque del agente LLM. El modelo en sí no es la vulnerabilidad. La vulnerabilidad está en cómo el runtime decide quién habla con el agente y qué rol tiene ese llamador. Es la misma clase de falla que ha golpeado la pila de Microsoft dos veces en semanas recientes: CVE-2026-32173 en Azure SRE Agent (abril de 2026) confiaba en una comprobación de token multi-tenant que no debía; CVE-2026-35435 confía en la identidad del llamador para los agentes M365 publicados. Dos productos distintos, la misma lección — la identidad privilegiada del agente es el botín.

Segundo, los agentes publicados son una flota, no una funcionalidad. Una vez que una organización abre Azure AI Foundry a sus líneas de negocio, decenas o cientos de agentes aterrizan en M365 con permisos de conectores hechos a medida. Una EoP que permite a un atacante republicar o redirigir un agente hereda todos esos permisos de golpe. No hay forma sencilla de acotar el impacto sin un inventario de qué está publicado y a qué puede llegar cada agente.

Tercero, la explotación activa antes del parche reconfigura la línea de tiempo. La ventana estándar de 90 días de divulgación responsable no aplica cuando el proveedor es la fuente de la divulgación y reporta abuso en la naturaleza. La pregunta defensiva se vuelve inmediata: asuma que la población de agentes en su tenant pudo haber sido tocada y actúe en consecuencia.

Defensas

Los controles compensatorios publicados por Microsoft, sumados a lo que la divulgación impone a cualquier runtime de agente, conforman una lista corta.

Inventaríe y delimite primero. Catalogue cada workspace de Azure AI Foundry y cada agente M365 publicado en su tenant. Para cada uno, registre el service principal, los conectores a los que puede llegar, los alcances de datos que esos conectores sostienen y quién está autorizado a publicar o modificar el agente. No puede razonar sobre el radio del impacto sin esto.

Aplique mínimo privilegio a los service principals de agentes. La mayoría de los agentes publicados están sobre-permisionados por defecto. Recorte los conectores y los alcances de Graph API al mínimo que el agente realmente usa. Elimine accesos permanentes a buzones, sitios de SharePoint y canales de Teams que el agente no necesita en tiempo de diseño.

Aplique conditional access en la ruta del agente. Microsoft recomienda políticas de conditional access que impidan que los agentes operen desde ubicaciones no confiables, dispositivos no confiables o salidas de red anónimas. Trate al service principal del agente como una cuenta de usuario a efectos de estas políticas.

Desactive o ponga en cuarentena los agentes de alta exposición. Los agentes publicados accesibles públicamente o de forma anónima son la prioridad uno. Si no puede reducirles el alcance de inmediato, retírelos hasta que llegue el parche del runtime.

Lleve las decisiones de identidad al servidor. Esta es la lección arquitectónica que sobrevive al CVE específico. Cualquier framework de agente que permita al llamador afirmar quién es — mediante una bandera, un encabezado o un token no vinculado — tiene el mismo modo de falla que senderIsOwner=true en OpenClaw o el chequeo laxo de appid en Azure SRE Agent. Vincule el rol, el tenant y la propiedad a una sesión autenticada validada en el servidor. Nunca confíe en lo que afirma el llamador.

Registre, alerte y rote secretos. Levante alertas sobre cambios de configuración de agente (republicación, otorgamiento de permisos, intercambio de conector), sobre patrones de acceso inusuales desde service principals de agentes y sobre primeros llamadores hacia agentes publicados sensibles. Tras la remediación, rote los secretos que cada agente afectado tenía permiso de alcanzar.

Estado

Elemento	Detalle
CVE	CVE-2026-35435
CWE	CWE-284 (Improper Access Control)
CVSS	8.6 (CRÍTICA)
Divulgación	7 de mayo de 2026 (Microsoft, Patch Tuesday)
Proveedor	Microsoft
Producto afectado	Azure AI Foundry — agentes M365 publicados
Estado del parche	Sin parche al momento de la divulgación; mitigaciones publicadas
Explotación	Activa en estado salvaje según Microsoft
Vector de ataque	Red, sin interacción del usuario
Mitigación principal	Mínimo privilegio en service principals de agentes, conditional access, cuarentena de los agentes más expuestos