El 22 de abril de 2026 a las 03:35 UTC, Sysdig observó el primer intento de explotación real contra CVE-2026-33626 en un honeypot, 12 horas y 31 minutos después de la publicación del advisory de GitHub. La trayectoria del ataque en una instalación de Vision-Language-Model de LMDeploy pasó en menos de ocho minutos a través del servicio de metadatos de instancia de AWS, una instancia local de Redis y un puerto backend de MySQL. Para los arquitectos de cloud, el caso es menos un problema de LMDeploy que una cuestión arquitectónica: ¿Por qué están los servidores de inferencia en el mismo segmento de VPC que los backends con estado; quién asume la responsabilidad operativa de esta segmentación en el stack de IA 2026?

¿Cómo se genera técnicamente CVE-2026-33626?

¿Qué es la falsificación de solicitudes del lado del servidor (SSRF)? SSRF designa una clase de vulnerabilidades en las que un atacante induce al servidor a enviar solicitudes HTTP a destinos que no son directamente accesibles para el atacante. Tradicionalmente, los atacantes utilizan esto para acceder a servicios internos (puntos de metadatos, bases de datos, interfaces de administración) que deberían estar aislados de Internet público. En los stacks de inferencia, SSRF es especialmente peligroso porque los servidores de visión LLM están arquitectónicamente diseñados para cargar imágenes desde cualquier URL, y precisamente este caso estándar es la vía de ataque.

En LMDeploy, la vulnerabilidad se encuentra en la función load_image() del módulo lmdeploy/vl/utils.py. La función acepta una URL y carga la imagen para la pipeline de visión posterior. En la versión afectada, falta una validación de IP privada. Un atacante envía una solicitud de visión normal con una URL como http://169.254.169.254/latest/meta-data/iam/security-credentials/ y recibe, siempre que el servidor de inferencia tenga credenciales AWS-IAM, los metadatos de respuesta correspondientes. El LLM de visión se convierte en un mensajero que publica su propio almacén de credenciales en la nube.

La cadena de ataque observada por Sysdig es metódica y controlada por herramientas. Fase uno: Llamada al AWS-IMDS para la exfiltración de credenciales. Fase dos: Sondeos contra Redis en localhost (puerto 6379) para enumerar cachés de pares clave-valor mal configurados. Fase tres: Escaneos de puerto MySQL-3306 en direcciones internas, acompañados de devoluciones de llamada DNS fuera de banda a través de requestrepo.com para confirmar rutas de SSRF ciegas. Todo el proceso, según Sysdig, se completa en menos de ocho minutos y es más difícil de detectar que un ataque clásico de script kiddie debido a las rotaciones del modelo.

Por qué los stacks de inferencia son sistemáticamente vulnerables

Los servidores de modelos de visión y lenguaje tienen una característica que rara vez se presenta tan fuertemente en el mundo clásico de backend: su función es cargar y procesar contenidos externos. Esto es un vector SSRF innato. Al mismo tiempo, estos servidores en muchos stacks de inferencia DACH (Alemania, Austria y Suiza) operan en los mismos segmentos VPC que las bases de datos vectoriales, los almacenes de características y las cachés de aplicaciones, porque se debe optimizar la latencia y la arquitectura parece «lógica» en el tablero. Precisamente esta co-localización ya no es aceptable en 2026.

Tres métricas del Advisory de Sysdig

La diferencia entre «seguridad por diseño» y «seguridad por incidente» es aproximadamente una semana de sueño. Para los Inference-Stacks, la diferencia se ha reducido a las 12,5 horas entre el Advisory y el primer exploit.

Las tres tareas pendientes para los arquitectos de cloud

Tarea 1: Servidores de inferencia en segmentos VPC propios

La primera y más importante medida: los servidores de modelos de visión y lenguaje deben pertenecer a segmentos VPC dedicados sin rutas directas a backends con estado como Redis, MySQL, Postgres, MongoDB o interfaces de administración internas. Esto no es una teoría, sino una consecuencia de la propiedad funcional del servidor de modelos (carga de URLs arbitrarias). En configuraciones de Terraform, esto significa concretamente: subredes propias, grupos de seguridad propios con reglas de salida explícitas, sin rutas de peering a subredes de bases de datos. Quienes no tengan esta segmentación no pueden evitar finalmente el exploit de LMDeploy, sin importar qué rápido se aplique el parche.

Un paso intermedio pragmático: introducir una «zona de IA» como tercer área de seguridad junto a la DMZ y la red interna. En la zona de IA funcionan servidores de modelos, pasarelas de modelos y réplicas de bases de datos vectoriales. Los backends con estado permanecen en la red interna. El tráfico entre zonas se ejecuta exclusivamente a través de cuentas de servicio con políticas restrictivas. Vemos en nuestros clientes que esta topología se puede implementar en cuatro a seis semanas, incluso en entornos brownfield con infraestructura existente.

Tarea 2: Forzar IMDSv2, no permitir restos de v1

El exploit de LMDeploy obtuvo credenciales de IAM a través de la ruta IMDSv1 (HTTP GET simple en 169.254.169.254). AWS ha definido IMDSv2 como estándar desde 2023, pero muchos despliegues heredados todavía funcionan con v1. En Azure y GCP existen servicios de metadatos análogos con mecanismos de protección similares. La consecuencia operativa: forzar IMDSv2 en todas las plantillas de lanzamiento de EC2 (HttpTokens = «required»), asegurar el servicio de metadatos de instancia de Azure con requisitos de encabezado y proteger los metadatos de GCP con verificación de encabezado de sabor de metadatos. Para equipos de DACH con múltiples cuentas de AWS, recomendamos una política SCP a nivel de organización que prohíba globalmente IMDSv1. Esto también captura las cargas de trabajo heredadas que se escapan a través de las rendijas en configuraciones de cuenta individual.

Tarea 3: Monitoreo de salida específico para LLM

El SIEM clásico a menudo no detecta un ataque SSRF a un Vision-LLM, porque las solicitudes parecen cargas de imágenes normales. La detección funciona mejor a nivel de salida: ¿qué objetivos ha realmente abordado el servidor de inferencia? Si un Vision-LLM ha realizado 15 solicitudes a 169.254.169.254 en la última hora, eso es una señal. Si el mismo servidor envía solicitudes a requestrepo.com, oast.pro o burpcollaborator.net, eso es otra cosa. La implementación concreta: un proxy de salida con enrutamiento basado en lista blanca y alertas sobre anomalías en el tráfico saliente. Quienes no tengan esto ven el ataque primero en los informes de facturación, cuando las credenciales ya han sido exfiltradas.

La mirada a la cadena de suministro de componentes de inferencia

Otro aspecto que en el caso actual permanece oculto es la dimensión de la cadena de suministro. LMDeploy es un componente de código abierto que se utiliza en muchas pilas de producción de DACH, a menudo como dependencia transitiva en tuberías de inferencia construidas internamente o como parte de despliegues de Kubernetes desde gráficos de Helm de terceros. Quienes no tengan un SBOM claro (Lista de Materiales de Software) para su propia infraestructura de IA, en caso de emergencia no saben dónde LMDeploy está activo en todas partes. Esto hace que el parcheo sea un juego del tesoro y retrasa drásticamente el tiempo de reacción.

El contrapaso pragmático: un SBOM para toda la pila de IA, idealmente automatizado a través de generación CycloneDX o SPDX en la canal de CI. Para equipos de medianas empresas en el primer año basta con una instantánea semanal de SBOM con informe delta, que refleje CVEs críticos contra su propia lista de componentes. El conjunto de herramientas para esto está disponible (Trivy, Syft, Dependency-Track), la organización solo tiene que introducirlo. Quienes lo hagan ahora estarán mucho mejor preparados para el próximo CVE en tres semanas que las organizaciones que tuvieron que buscar LMDeploy manualmente.

Qué significa para el propio proceso de parches

La observación de explotación rápida en LMDeploy no es un caso aislado. CVE-2026-33626 se suma a una serie de vulnerabilidades en la pila de inferencia que en 2026 fueron explotadas en horas en lugar de semanas. Esto tiene consecuencias para el proceso de parches. Un SLA clásico de parches de 30 días ya no es apropiado para las pilas de inferencia. La nueva expectativa: parches críticos en componentes de servidores de IA dentro de 24 a 72 horas, idealmente automatizados a través de actualizaciones de Helm-Chart con implementaciones con control de políticas.

Para las organizaciones del DACH, esto significa una inversión en la pipeline de parches: monitoreo continuo de CVE para todo el inventario de la pila de IA (LMDeploy, vLLM, TGI, Ray Serve, Triton, Ollama, LiteLLM), claras responsabilidades por componente e implementaciones automáticas con estrategia Canary. Quién no tenga esta pipeline, está estructuralmente fuera del tiempo de respuesta de 24 horas que se necesita en 2026.

La parte organizativa es a menudo más exigente que la técnica. Muchos equipos del DACH tienen el proceso de parches para servidores de aplicaciones y bases de datos bien controlado, porque las responsabilidades allí son claras. Las pilas de IA están organizacionalmente entre Ingeniería de Plataforma, Ciencia de Datos y Seguridad, y cada lado cree que el otro es responsable. La consecuencia para los líderes en este entorno: designar por escrito un propietario de parches por componente de IA, con SLAs de escalada y responsabilidad en el panel de operaciones. Quién gestione este tema como un asunto secundario, no habrá solucionado el siguiente CVE más rápido, sino más tarde. La pregunta de la propiedad es la que decidirá la capacidad de parches de la propia organización en los próximos tres trimestres. Quién la deja sin resolver, retrasará cada caso de explotación adicional exactamente el tiempo que dure la coordinación entre los tres equipos.

Qué papel juega el Model-Gateway en la nueva topología

Un tema que a menudo falta en la discusión actual sobre LMDeploy: el papel del Model-Gateway como capa de arquitectura. Un Model-Gateway (Kong AI-Gateway, LiteLLM, Portkey, Vercel AI Gateway) idealmente se sitúa antes del servidor de modelos real y se encarga de autenticación, limitación de velocidad, filtrado de PII y observabilidad. Para ataques SSRF, el gateway tiene una función adicional: puede validar las URL de imágenes antes de pasarlas al servidor de modelos, filtrar rangos de IP privadas y hacer cumplir reglas de egress. Quién integra un gateway en la topología, obtiene un segundo anillo de defensa que funciona independientemente del código del servidor de modelos real.

La integración de un Model-Gateway en un setup típico de PYMES cuesta entre 30.000 y 90.000 euros en el primer año (licencia, integración, formación en operaciones). La inversión se amortiza básicamente por dos efectos. Primero, la reducción del radio de blast en vulnerabilidades de servidores de modelos como CVE-2026-33626. Segundo, la observabilidad unificada a través de múltiples servidores de modelos, que en setups heterogéneos de otra manera tendría que construirse por proveedor. Quién en 2026 aún no tiene un Model-Gateway, debería introducirlo a más tardar en el Q3.

Qué dice el colega de seguridad del mundo del desarrollo de aplicaciones

Un breve reality check desde la práctica desde la perspectiva de Cloud-Ops: Quién creció en el mundo del desarrollo de aplicaciones, conoce SSRF desde hace años del OWASP Top 10. Las contramedidas clásicas (validación de URL, bloqueo de IP privadas, protección de rebinding de DNS) están disponibles a menudo en frameworks web como middleware. En las pilas de inferencia 2024 y 2025, esta capa a menudo se pasó por alto o se declaró como «específica de IA». El exploit de LMDeploy muestra: las lecciones del desarrollo de aplicaciones siguen siendo válidas para las pilas de IA, solo con pequeños ajustes. Quién le pide a su organización de seguridad que realice una revisión de SSRF en todos los componentes de IA, normalmente obtiene dentro de dos semanas un análisis de gaps sólido. Este es el ROI más rápido en la semana posterior a LMDeploy.

Preguntas frecuentes

¿Qué versiones de LMDeploy están afectadas?

El aviso de GitHub enumera todas las versiones anteriores a la versión de lanzamiento parchada. Las cadenas de versión específicas se encuentran en el aviso y en los rastreadores de seguridad GitLab y NIST. Quienes utilicen LMDeploy en producción deberían instalar de inmediata la versión actual y validar la ruta de carga de imágenes.

¿Otros stacks de inferencia son igualmente vulnerables?

Cada stack de inferencia con capacidades de visión o multimodal y función de carga de imágenes debería ser verificado en cuanto a riesgos SSRF. vLLM, Ray Serve y Text Generation Inference tienen patrones funcionales similares. Una auditoría interna de SSRF sobre todo el stack de IA es apropiada para 2026.

¿Ayuda un firewall de aplicaciones web (WAF)?

Limitadamente. Las reglas de WAF contra rangos de IP privadas en cuerpos HTTP capturan parte de los ataques, pero a menudo son insuficientes porque los atacantes combinan rangos IPv6 privados, DNS-rebinding y codificación URL. WAF es un complemento, no un reemplazo para una segmentación de red limpia y procesos de parcheo.

¿Cuál es la estrategia de detección mínima para esta clase de ataques?

Tres señales se han demostrado efectivas en la práctica: Destinatarios inusuales en el egress (169.254.*, 10.*, 172.16-31.*, 192.168.*), dominios de callback (requestrepo.com, oast.pro, burpcollaborator.net), y picos repentinos de latencia en los registros del servidor de modelo debido a llamadas HTTP a destinos desconocidos. Integrar estas tres señales en un sistema SIEM o de observabilidad es un tema prioritario.

¿Cómo se relaciona esto con las arquitecturas de confianza cero?

Las arquitecturas de confianza cero abordan el núcleo de este ataque de manera limpia: autenticar cada conexión, autorizar cada acceso, nunca asumir confianza a nivel de red. Quienes implementen Zero-Trust consistentemente han desactivado estructuralmente el exploit de LMDeploy, porque el servidor de inferencia, incluso con SSRF, no tendría derechos implícitos sobre backends stateful.

¿Debemos ajustar nuestros contratos con los proveedores de stacks de inferencia?

Para muchas empresas sí. El tiempo de 12,5 horas entre el aviso y el exploit significa que los SLA de proveedores con tiempos de parche de 30 días o más no son sostenibles. Una renegociación hacia parches de 72 horas para vulnerabilidades críticas en componentes de stack de IA es apropiada para 2026. Quienes no lo ajusten, asumen un riesgo estructural en la operación de producción.

Red: Siga leyendo en cloudmagazin

• Arquitectura sobre el Protocolo A2A 1.2 e integración de Service Mesh
• Perspectiva multi-cloud sobre Servicios de intermediación en la nube y informe FinOps 21.04.2026
• Antecedentes sobre el impulso de Commvault-Clumio en Cloud Next 2026

Fuente de la imagen de portada: Pexels / Christina Morillo (px:1181263)