Volver al Blog
Ciberseguridad 25 de abril de 2026 5 min read

CVE-2026-33626: SSRF en LMDeploy Explotado 13 Horas Después de su Divulgación — Actualiza a 0.12.3 Ya

Una vulnerabilidad SSRF de alta severidad en el módulo vision-language de LMDeploy fue explotada en producción apenas 12,5 horas después de publicarse el advisory de GitHub. CVSS 7.5, afecta todas las versiones anteriores a 0.12.3. La infraestructura de inferencia IA está siendo atacada tan rápido como las vulnerabilidades web tradicionales.

CVE-2026-33626: SSRF en LMDeploy Explotado 13 Horas Después de su Divulgación — Actualiza a 0.12.3 Ya

CVE-2026-33626 — CVSS 7.5, Severidad Alta. Afecta todas las versiones de LMDeploy anteriores a 0.12.3. Solución: actualizar de inmediato.

El fallo reside en lmdeploy/vl/utils.py, concretamente en la función load_image() del módulo de lenguaje visual de LMDeploy. La función recupera URLs arbitrarias sin validarlas contra rangos de IP internas o privadas. Esto la convierte en un vector SSRF directo: envía una URL de imagen manipulada y el servidor realizará una petición saliente hacia cualquier destino en la red interna — AWS IMDS, Redis, MySQL, interfaces de administración internas, lo que sea accesible desde el host de inferencia.

El advisory de GitHub GHSA-6w67-hwm5-92mq se publicó el 21 de abril. Sysdig detectó el primer intento de explotación contra su honeypot a las 03:35 AM UTC del 22 de abril — 12 horas y 31 minutos después.

El atacante ejecutó una campaña metódica en tres fases. Rotó entre dos VLMs (internlm-xcomposer2 y OpenGVLab/InternVL2-8B) para mezclarse con el tráfico normal de la API y evadir la detección. Después sondeó el endpoint del AWS Instance Metadata Service, seguido de Redis, MySQL y una interfaz de administración HTTP interna. Finalmente, utilizó exfiltración DNS fuera de banda para confirmar la extracción de datos sin generar registros HTTP salientes obvios.

Diez peticiones distintas. Sistemático. Profesional.

Esto importa más allá de LMDeploy. La infraestructura de inferencia IA se ha tratado históricamente como un servicio interno de bajo riesgo — algo que ejecutas dentro de una VPC y asumes que está protegido. Esa suposición es errónea. LMDeploy, vLLM, Triton Inference Server y herramientas similares están cada vez más expuestas en el perímetro o en clusters Kubernetes compartidos donde los límites de red no son tan limpios como aparecen en los diagramas de arquitectura.

La superficie de ataque SSRF en los sistemas de servicio IA es amplia. Los modelos de visión-lenguaje que aceptan URLs de imagen como entrada son especialmente peligrosos: el objetivo de la función es precisamente hacer que el servidor descargue contenido externo, que es exactamente lo que necesita un atacante SSRF. Sin controles estrictos — listas de IP permitidas, bloqueo de endpoints de metadatos, políticas de red de salida — cualquier endpoint VLM que acepte URLs proporcionadas por el usuario es un posible punto de pivote hacia la red interna.

Qué parchear:

  • Actualiza a LMDeploy 0.12.3 o superior (pip install lmdeploy --upgrade)
  • Bloquea peticiones salientes a 169.254.169.254 (AWS IMDS) a nivel de red independientemente de la versión del software
  • Si ejecutas LMDeploy en Kubernetes, aplica NetworkPolicies de egreso para restringir a qué subredes puede acceder el pod de inferencia
  • Audita los logs en busca de peticiones a load_image() con rangos de IP internos o nombres DNS sospechosos

La lección más amplia: trata los endpoints de inferencia IA con el mismo nivel de paranoia que aplicarías a cualquier servicio web expuesto públicamente. Las ventanas de parche para CVEs específicos de IA se están acortando rápidamente — 12 horas no son suficientes para responder de forma manual.

ciberseguridad CVE SSRF LMDeploy infraestructura-IA