SSRF en Azure OpenAI: cuando un servicio de IA gestionado se convierte en un relé de escalada de privilegios

¿De qué se trata?

El 2 de julio de 2026, Microsoft publicó un aviso de seguridad sobre una falla crítica de tipo server-side request forgery (SSRF) en Azure OpenAI, su servicio en la nube para ejecutar modelos de OpenAI (como la familia GPT) dentro de la plataforma Azure. La vulnerabilidad recibió una puntuación de 9.9 en la escala CVSS 3.1 y se clasificó como una escalada de privilegios. Según Microsoft y el análisis del Patch Tuesday de julio de 2026 de CrowdStrike, la falla fue mitigada por completo en la propia infraestructura de Microsoft, por lo que los clientes del servicio no tienen ningún parche que aplicar.

El interés de este hallazgo reside menos en el riesgo inmediato —ya corregido del lado del servidor— que en lo que ilustra: incluso una plataforma de IA totalmente gestionada hereda las mismas debilidades en el manejo de solicitudes web que han aquejado a las aplicaciones en la nube durante una década. Es un estudio de caso defensivo sobre una clase de vulnerabilidad, no un exploit utilizable tal cual.

Cómo funciona

El server-side request forgery ocurre cuando se puede engañar a un servicio para que realice solicitudes de red hacia destinos elegidos por el atacante. En un servicio de IA gestionado, la superficie de manejo de solicitudes es inusualmente amplia: la plataforma suele recuperar URL proporcionadas por el usuario para ingerir documentos destinados a la búsqueda, obtener imágenes para prompts multimodales o realizar llamadas de retorno a puntos de acceso de herramientas y funciones. Cualquiera de esas rutas de código puede convertirse en un sumidero SSRF si el destino no se valida estrictamente.

Según la ficha de NVD (CWE-918), la falla requería un atacante autenticado y con pocos privilegios (PR:L), no necesitaba ninguna interacción del usuario (UI:N), presentaba una baja complejidad de ataque (AC:L) y —punto decisivo— un alcance modificado (S:C). Ese cambio de alcance es lo que elevó la puntuación a 9.9: el componente vulnerable podía actuar sobre recursos más allá de su propio límite de seguridad. En la práctica, una SSRF dentro de un servicio en la nube permite a un atacante enviar solicitudes desde el servicio hacia puntos de acceso internos no expuestos a Internet: API de administración internas, servicios vecinos o el punto de acceso a los metadatos de instancia que entrega tokens de identidad. Alcanzar esas superficies internas desde una posición de confianza es como una falla de falsificación de solicitudes se transforma en una escalada de privilegios. No se publicó ninguna prueba de concepto pública y Microsoft no detalló el punto de inyección exacto.

Por qué importa

Las empresas tratan cada vez más los puntos de acceso de IA gestionados como infraestructura de confianza situada en el corazón de su red, conectada a repositorios de datos privados mediante identidades gestionadas. Esa confianza es precisamente el problema. Cuando el propio servicio de IA puede ser orientado para emitir solicitudes internas, su posición en la red y la identidad que le fue asignada pasan a ser las del atacante, no las suyas. El radio de impacto de una SSRF se mide por todo lo que el servicio comprometido tiene permitido alcanzar.

Este caso recuerda que la línea de «responsabilidad compartida» se desplaza, pero nunca desaparece. Microsoft era responsable de esta vulnerabilidad concreta y la corrigió. Pero la lección de arquitectura —que la capacidad de un servicio de IA para emitir solicitudes salientes es una superficie de ataque de pleno derecho— se aplica a cada servidor de inferencia autoalojado, pasarela y canalización de ingesta RAG que usted opere por su cuenta, donde ningún proveedor corregirá la falla en silencio.

Defensas

Endurecimiento concreto y no intrusivo para quien opere servicios de IA que recuperan contenido externo:

• Restrinja el tráfico saliente. Los componentes de ingesta y de llamada a herramientas solo deberían alcanzar una lista blanca explícita de destinos. Aplique una denegación por defecto del tráfico saliente y bloquee a nivel de red los rangos privados (RFC 1918), las direcciones link-local y el punto de acceso a metadatos (169.254.169.254).
• Proteja los metadatos de instancia. Imponga tokens ligados a una sesión de tipo IMDSv2 (o el equivalente reforzado de su nube) para que una simple SSRF no pueda extraer credenciales de identidad.
• Reduzca las identidades gestionadas al mínimo privilegio. Otorgue a cada carga de trabajo de IA el rol y el alcance de recursos más estrechos que necesite; una identidad robada solo es tan peligrosa como sus permisos.
• Valide y vuelva a resolver las URL. Rechace los esquemas que no sean HTTP, canonicalice y vuelva a resolver los nombres de host tras la validación para frustrar el DNS-rebinding, y nunca siga redirecciones hacia el espacio interno.
• Aislamiento de inquilinos y monitoreo. Segmente las rutas de red por inquilino y registre las solicitudes salientes del servicio; un destino interno anómalo es un indicador SSRF de alta señal.

Aplicar estos controles hace que una SSRF en su propia pila falle de forma cerrada en lugar de convertirse en un punto de pivote hacia su plano de control en la nube.

Estado

Elemento	Detalle
Producto afectado	Azure OpenAI (servicio gestionado en la nube)
Clase de debilidad	Server-side request forgery (CWE-918)
Severidad	Puntuación base CVSS 3.1: 9.9 (Crítica) — vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Divulgación	2 de julio de 2026 (aviso de Microsoft / NVD)
Corrección	Mitigada por completo en la infraestructura de Microsoft; no se requiere acción del cliente
Exploit público	Ninguno conocido hasta la fecha
Referencia	CVE-2026-45499