LMDeploy bajo amenaza SSRF explotada en horas expone recursos internos

Menos de 13 horas después de hacerse pública, una vulnerabilidad de alta gravedad en LMDeploy —el conjunto de herramientas de código abierto para comprimir, desplegar y servir modelos de lenguaje y visión— ya estaba siendo explotada en entornos reales. La falla, registrada como CVE-2026-33626 con puntuación CVSS 7.5, es una variante de Server‑Side Request Forgery (SSRF) en el módulo visión‑lenguaje: una función que descarga imágenes desde URLs no valida si esas direcciones pertenecen a redes internas o servicios de metadatos en la nube, abriendo la puerta a accesos no autorizados a recursos sensibles.

El vector es sencillo y peligroso: el loader de imágenes acepta URLs arbitrarias. Un atacante que controle la entrada puede forzar al servidor a solicitar recursos internos como el servicio de metadatos de la instancia en AWS (IMDS), bases de datos locales, interfaces administrativas en loopback o endpoints internos que normalmente no están accesibles desde Internet. En el caso reportado, los atacantes combinaron escaneo de puertos internos y exfiltración por DNS OOB para confirmar y explotar la capacidad de la SSRF como «primitiva HTTP».

Que la explotación haya ocurrido en cuestión de horas no es casualidad. En la práctica, las divulgaciones técnicas que incluyen el fragmento de código vulnerable, el nombre del parámetro y ejemplos funcionales actúan como instrucciones precisas para actores maliciosos —y hoy también como prompts para modelos comerciales— acelerando la traducción de un problema detectado a un exploit operativo. Esto muestra una dinámica preocupante en el ecosistema de infraestructuras de IA: tiempo de respuesta extremadamente corto entre publicación y ataque.

Las consecuencias potenciales son materiales y multifacéticas. Robo de credenciales cloud mediante IMDS, reconocimiento y movimiento lateral hacia servicios internos, compromiso de bases de datos o colas, y la posibilidad de persistencia si el servidor afectado tiene permisos ampliados son escenarios plausibles. Para entornos industriales o que ejecutan controladores y PLCs expuestos, la combinación de probes masivos y escaneos selectivos es una receta para interrupciones y manipulación.

Desde el punto de vista operativo, la primera prioridad inmediata debe ser contener la exposición. Si su organización usa LMDeploy con soporte visión‑lenguaje, aplique la corrección oficial si ya está disponible o deshabilite temporalmente las funcionalidades de carga remota de imágenes. Como medida de contención adicional, bloquee o restrinja el tráfico saliente desde los servidores de inferencia, implemente reglas de egress que permitan únicamente dominios y rangos explícitamente necesarios y asegure que no exista acceso directo a 169.254.169.254 (IMDS) ni a interfaces loopback desde procesos que aceptan URLs de clientes.

Hay mitigaciones específicas en la nube que reducen el impacto de este tipo de SSRF. Para instancias AWS, habilitar IMDSv2 y fijar el hop limit o desactivar el acceso a metadatos cuando no sea necesario limita la capacidad de un atacante para robar credenciales. También es recomendable aplicar segmentación de red estricta, aplicar listas blancas de dominios para fetches salientes y emplear proxies inversos o validadores que comprueben whitelist/blacklist de IPs y rangos RFC1918 antes de permitir una solicitud externa. En términos generales, validar y normalizar entradas que contengan URLs es obligatorio; eludir esta validación fue la raíz del incidente.

En detección y respuesta, busque indicadores claros: peticiones del servidor hacia 169.254.169.254, conexiones al loopback 127.0.0.1 desde procesos que normalmente no las realizan, cadenas de consulta que contienen URLs proporcionadas por terceros, y consultas DNS atípicas hacia dominios OOB (out‑of‑band). Revise logs del servicio de modelos para patrones de requests que cambien entre distintos modelos o que muestren intentos de escaneo de puertos internos. Si sospecha compromiso, aísle la instancia, recolecte evidencias y rote credenciales expuestas.

Este incidente debe servir como recordatorio de que la seguridad en infraestructuras de modelos no es solo hardening tradicional: implica considerar cómo funciones diseñadas para flexibilidad (como cargar una imagen remota) pueden convertirse en vectores de acceso a la red interna. Los responsables de producto y los equipos de seguridad deben incorporar revisiones de diseño orientadas a la exposición de red, pruebas de SSRF y controles de salida por defecto en cualquier componente que procese URLs externas.

Para profundizar en prevención y patrones de mitigación de SSRF, consulte la guía de la OWASP sobre el tema y la documentación de AWS respecto al servicio de metadatos, que describen controles concretos aplicables en producción: OWASP SSRF Prevention Cheat Sheet y AWS Instance Metadata Service (IMDS) documentation. Además, la propia publicación del hallazgo y la corrección pueden hallarse en la asesoría pública del proyecto: GitHub Advisory GHSA-6w67-hwm5-92mq.

En definitiva, las organizaciones que desplegan modelos y gateways de inferencia deben asumir que los exploits llegarán con extrema rapidez tras una divulgación y preparar tanto parches como medidas compensatorias y capacidades de detección. Actualizar, segmentar, monitorear y validar entradas son los pilares para reducir el riesgo inmediato; la mejora sostenida exige integrar estas prácticas en el ciclo de desarrollo y despliegue de infraestructuras de IA.