Cuando el cargador de imágenes se vuelve un SSRF: robo de metadatos cloud en nodos vision-LLM

¿Qué es esto?

El 21 de abril de 2026, los mantenedores de LMDeploy —una herramienta open source muy utilizada para comprimir, desplegar y servir grandes modelos de lenguaje y modelos de visión-lenguaje— publicaron un aviso de seguridad sobre una falla de server-side request forgery (SSRF) en su módulo de visión-lenguaje. El fallo fue reportado por Igor Stepansky, investigador de Orca Security. En 12 horas y 31 minutos, el equipo de investigación de amenazas de Sysdig registró el primer intento de explotación contra sus honeypots, y al día siguiente la falla ya se explotaba en entornos reales. Este artículo se basa en el aviso público de los mantenedores y en el análisis posterior al incidente; no se reproduce aquí ningún exploit funcional.

La lección va mucho más allá de una sola herramienta: cuando un servidor de modelos recupera una URL por usted, esa recuperación es una superficie de ataque, y en un nodo de inferencia con GPU puede ser una especialmente valiosa.

Cómo funciona

Los endpoints multimodales aceptan imágenes. En lugar de obligar a cada cliente a subir bytes en bruto, la mayoría de las pilas de servicio permiten pasar una URL de imagen, que el servidor recupera obedientemente. En el código afectado, la función de carga de imágenes recuperaba URL arbitrarias sin comprobar a dónde apuntaban: sin verificación de resolución de nombre de host, sin lista de bloqueo de redes privadas, sin protección para direcciones link-local.

Eso convierte el endpoint de visión en una primitiva de petición HTTP de propósito general, controlada por cualquiera que pueda llamar a la API. En lugar de una imagen, el atacante suministra una URL dirigida a la infraestructura que está detrás del servidor:

POST /v1/chat/completions            (una petición de visión normal)
  image_url: http://169.254.169.254/latest/meta-data/iam/security-credentials/
        |
  el servidor recupera la URL del lado del servidor, sin validar el destino
        |
  la respuesta (o el tiempo/error) revela recursos internos:
  metadatos cloud (IMDS), Redis, MySQL, interfaces de admin, puertos loopback

En la intrusión observada, el atacante no se detuvo al confirmar el fallo. En una única sesión de ocho minutos, usó el cargador de imágenes para sondear la red interna: el servicio de metadatos cloud, una instancia de Redis, MySQL, una interfaz HTTP de administración secundaria y una devolución de llamada DNS fuera de banda para confirmar el acceso saliente. También alternaba entre distintos modelos de visión en el mismo servidor para mezclarse con el tráfico legítimo.

Por qué importa

Un SSRF de manual ya es grave; un SSRF en un nodo de servicio de IA lo es más, por lo que esos nodos contienen. Los workers de visión-LLM suelen ejecutarse en instancias GPU con roles cloud amplios: acceso a buckets de artefactos de modelos, conjuntos de datos de entrenamiento y, a menudo, permisos de assume-role entre cuentas. Una sola recuperación exitosa del servicio de metadatos de instancia puede entregar al atacante credenciales IAM temporales, y a partir de ahí el radio de impacto pasa a ser toda la cuenta cloud, no solo un contenedor.

La cronología es el otro punto incómodo. Esta falla fue armada en bastante menos de un día, antes de que la mayoría de los operadores pudieran parchear, y sin prueba de concepto pública en ese momento. Encaja con un patrón que los respondedores señalaron directamente: un aviso detallado —archivo afectado, nombre del parámetro, explicación de la causa raíz, código de ejemplo— equivale a un prompt listo para que un modelo redacte un exploit. La infraestructura de IA se escanea y se ataca en las horas siguientes a cualquier divulgación, sin importar cuán nicho sea el proyecto.

Defensas

Valide cada destino de recuperación del lado del servidor. Resuelva primero el nombre de host, y luego rechace los rangos privados, loopback y link-local (incluida la dirección de metadatos) así como los esquemas no HTTP. Vuelva a comprobar tras la resolución para frustrar el DNS rebinding, y prefiera una lista de permitidos de hosts de imágenes esperados en vez de una lista de bloqueo.

Blinde el servicio de metadatos. Exija IMDSv2 (token de sesión) y fije el límite de saltos de la respuesta en 1, de modo que un SSRF reenviado no pueda alcanzarlo. Este único control neutraliza el paso de mayor impacto del ataque observado.

Aplique el mínimo privilegio a los nodos de inferencia. Un servidor de modelos rara vez necesita roles S3 o entre cuentas amplios adjuntos a la instancia. Acote el rol a exactamente lo que el servicio requiere, y mantenga los permisos sobre datos de entrenamiento y artefactos en identidades separadas.

Contenga la salida y la accesibilidad interna. Deniegue por defecto el tráfico saliente de los workers de inferencia, sepárelos de Redis, bases de datos e interfaces de administración, y alerte si un host de modelo empieza de repente a abrir conexiones DNS o TCP hacia rangos internos.

Parchee al recibir el aviso, no cuando le convenga. Como las fallas de infraestructura de IA se explotan en horas, trate los avisos de las pilas de servicio como cambios de emergencia: actualice pronto a la versión corregida y vigile los indicadores publicados con el aviso.

Estado

Elemento	Detalle
Referencia	Aviso de GitHub GHSA-6w67-hwm5-92mq (CVE-2026-33626), CVSS 7.5
Divulgación	21 de abril de 2026; primer intento real en ~12,5 horas
Afectado	Módulo de visión-lenguaje de LMDeploy, todas las versiones con soporte de visión hasta la versión corregida (0.12.x y anteriores según el aviso)
Causa raíz	load_image() recuperaba URL arbitrarias sin validar destinos internos/privados/link-local
Impacto	Escaneo de red interna, acceso a Redis/MySQL/interfaces de admin, robo de metadatos cloud y credenciales IAM
Corrección	Actualizar a la versión corregida; aplicar la validación de destino descrita en el aviso