Intrusiones en la infraestructura de IA: robo de claves y minería en pasarelas LLM

¿Qué es esto?

El 26 de agosto de 2026, Microsoft Security Research publicó el análisis de intrusiones contra tres cargas de trabajo de IA distintas: una pasarela LiteLLM, un despliegue de RAGFlow y un entorno de flujos de trabajo Kestra. El documento está firmado por Yash Gund y Sumith Maniath y se apoya en telemetría de Microsoft Defender recogida en los hosts comprometidos.

Lo interesante de la publicación no es la sofisticación —hay poca—. Las vías de entrada difieren según el producto, pero los objetivos son idénticos en los tres casos, y del todo convencionales: recolectar credenciales, establecer persistencia y monetizar el host con un minero de criptomonedas. No se nombra a ningún actor ni se ofrece atribución estatal. Es delincuencia común encontrando una nueva clase de objetivo expuesto.

Ese objetivo es lo que Microsoft denomina un punto de control: pasarelas, plataformas de recuperación y servicios de orquestación se sitúan ahora entre los usuarios, las aplicaciones, los datos y los modelos, y al hacerlo concentran claves de proveedores de modelos, cadenas de conexión a bases de datos, configuración de inquilinos y privilegios de ejecución en un único runtime.

Cómo funciona

La pasarela (LiteLLM). El acceso inicial se evalúa con alta confianza como explotación de la superficie expuesta de la pasarela: un fallo de ejecución de comandos autenticada en los endpoints de prueba MCP stdio, que la investigación pública de Horizon3.ai encadena con una elusión de la validación de cabecera Host en Starlette para alcanzar ejecución de código no autenticada en despliegues vulnerables. Lo que sigue es lo instructivo. La pasarela corre como PID 1 en su contenedor, así que la carga útil leyó /proc/1/environ y lo filtró por palabras clave como master, API key, token y password. Una línea de Python autocontenida extrajo después DATABASE_URL de ese mismo entorno, se conectó a la instancia PostgreSQL subyacente y volcó las tablas de modelos y de claves virtuales. La salida se codificó en base64 y se exfiltró en fragmentos pequeños hacia endpoints de retorno fuera de banda. La persistencia llegó vía modificación de claves SSH autorizadas, nombres de servicio suplantados y atributos de fichero inmutables; una reescritura de crontab eliminaba de paso a los mineros competidores antes de instalar el propio.

La plataforma de recuperación (RAGFlow). Microsoft indica explícitamente que tiene baja confianza sobre qué fallo concreto permitió la ejecución de código: las rutas de código implicadas se ejecutan dentro del proceso Flask de RAGFlow y la telemetría de endpoint no pudo aislar el punto de ejecución. Existen varios candidatos documentados públicamente, entre ellos inyecciones de plantillas en el generador de prompts y en el componente de flujo de trabajo de agente, un salto de directorio en un parser y una elusión de sandbox. Lo relevante es el comportamiento posterior: el atacante colocó un hook de Python oculto bajo el árbol de la aplicación, modificó la ruta de importación para que se cargara con el servicio y envolvió el flujo de configuración del LLM del inquilino. El hook no robaba las claves almacenadas: capturaba las credenciales de proveedor en el momento en que los administradores las introducían después, para configuraciones de OpenAI, Azure, Anthropic y Gemini, suprimiendo los errores para que la configuración pareciera correcta. En este caso no hubo minero: el objetivo era puramente la interceptación de credenciales.

El orquestador (Kestra). El acceso inicial se evalúa con alta confianza como una elusión de autenticación. La causa raíz es un fallo de aplicación web de manual, sin nada de IA: el filtro de autenticación incluía en lista blanca el endpoint público de configuración mediante una comparación de sufijo (endsWith("/configs")) en lugar de una comparación exacta de ruta. Como Kestra direcciona sus recursos mediante segmentos de ruta elegidos por quien llama —espacio de nombres, identificador de flujo—, cualquier ruta terminada en ese segmento esquivaba por completo la autenticación básica. Suficiente para crear y ejecutar un flujo de trabajo, y Kestra incluye plugins de ejecución de scripts por defecto. Siguieron ejecución de shell desde el linaje del worker, acceso al socket de Docker para enumerar los arrays de entorno de otros contenedores alcanzables a través de ese socket montado, y después XMRig contra un pool de Monero.

Microsoft señala además que varias cargas útiles mostraban características que suelen asociarse a código asistido o generado: importaciones ordenadas, gestión explícita de tiempos de espera, alternativas de dependencias, manejo defensivo de excepciones y comentarios explicativos. Lo presenta con cautela como una observación sobre el utillaje, no como elemento de atribución, y se abstiene de concluir nada sobre la autoría del código. Lo recogemos en los mismos términos.

Por qué importa

El radio de impacto de una pasarela de IA es más amplio de lo que refleja la mayoría de inventarios. Un solo proxy comprometido entrega la clave maestra, todas las claves virtuales por inquilino que haya emitido y una cadena de conexión que lleva a otro sitio. La factura del proveedor de modelos es lo de menos: esas claves suelen dar acceso a todo aquello a lo que la organización haya conectado el modelo.

El caso de RAGFlow es el que conviene interiorizar. La rotación de credenciales es la respuesta estándar ante una sospecha de fuga de claves; sin embargo, frente a un hook instalado en el flujo de configuración, la rotación alimenta activamente al atacante. Cada clave recién emitida se captura en el instante en que se introduce. Cualquier respuesta a incidentes sobre una plataforma de recuperación o una pasarela debe establecer que el árbol de la aplicación está limpio antes de que un secreto nuevo se acerque a él.

Por último, el fallo de Kestra recuerda que la pila de IA está absorbiendo infraestructura de propósito general más rápido de lo que esa infraestructura se vuelve a auditar. Una comprobación de autorización por sufijo es un error que la comunidad de seguridad web entiende desde hace dos décadas. Aquí se vuelve crítico porque ese componente se sitúa ahora delante de credenciales de modelos y de runtimes de contenedores.

Defensas

Inventaríe y cierre las superficies de administración expuestas. Las interfaces administrativas de pasarelas, plataformas RAG y orquestadores no deben ser accesibles desde Internet. Es el control único que habría evitado las tres intrusiones.

Parchee los componentes citados. La elusión de autenticación de Kestra está corregida en 1.0.45 y 1.3.21; considere vulnerable a RCE no autenticada cualquier versión anterior. Aplique versiones actuales de LiteLLM y RAGFlow, así como los parches de los frameworks aguas arriba.

Saque las claves de proveedor del entorno del proceso. La lectura de /proc/1/environ solo compensa si las claves están ahí. Inyecte los secretos desde un gestor administrado en el momento de la llamada, emita claves virtuales por equipo con límites de gasto en lugar de compartir una clave maestra, y rote todo lo que haya residido en una instancia expuesta —después de la verificación de integridad indicada más abajo—.

Aplique mínimo privilegio entre pasarela y base de datos. Ejecute el proxy bajo una cuenta de servicio dedicada, limite sus permisos a los objetos estrictamente necesarios y coloque la base de datos tras un endpoint privado con reglas de cortafuegos restrictivas. Volcar una tabla de claves virtuales no debería estar entre lo que puede hacer el rol de la pasarela.

Ponga el egress en deny-by-default. Autorice solo los endpoints de proveedores de modelos y servicios necesarios; bloquee conexiones directas a direcciones IP en crudo y puertos no estándar; encamine el tráfico permitido por un proxy con filtrado por FQDN. Registre y filtre el DNS: las balizas codificadas en subdominios y las llamadas fuera de banda son visibles ahí antes que en ningún otro sitio.

Endurezca el runtime del host. Monte los directorios temporales como no ejecutables cuando sea operativamente viable, alerte sobre ejecuciones desde rutas escribibles por todos y vigile cambios en entradas de cron, ficheros authorized_keys y atributos de inmutabilidad.

Verifique la integridad de la aplicación antes de rotar credenciales. Compare el árbol desplegado y las rutas de importación con una imagen de referencia conocida, y trate cualquier hook inesperado en un flujo de configuración de credenciales como un bloqueo de la rotación.

Detecte por correlación, no por evento aislado. Ninguno de estos pasos resulta alarmante por separado. La señal es la cadena: un shell o intérprete originado en la aplicación, seguido de acceso a secretos, seguido de depósito de carga útil en un directorio temporal, seguido de una llamada saliente. La recomendación propia de Microsoft es vigilar las cargas de trabajo de IA según su papel de plano de control y no como aplicaciones aisladas, y tratar cualquier sondeo de tipo SSRF sobre una plataforma de recuperación como un precursor, ya que en el caso de RAGFlow la ejecución de código llegó varios días después.

Status

Elemento	Referencia	Fecha	Notas
Publicación de investigación de Microsoft	Microsoft Security Research	2026-08-26	Tres cargas de trabajo: pasarela LiteLLM, RAGFlow, Kestra. Sin atribución de actor
Ejecución de comandos MCP stdio en LiteLLM	CVE-2026-42271 / GHSA-v4p8-mg3p-g94g	—	Ejecución autenticada; acceso inicial con alta confianza en el caso de la pasarela
Elusión de validación de cabecera Host en Starlette	CVE-2026-48710	—	Encadenada por la investigación pública de Horizon3.ai hasta RCE no autenticada
Fallos candidatos en RAGFlow	CVE-2026-45312, CVE-2026-28797, CVE-2026-24770, CVE-2025-68700, CVE-2025-69286	—	Inyección de plantillas, salto de directorio, elusión de sandbox, acceso a cuentas. Baja confianza: ninguno confirmado
Elusión de autenticación en Kestra	CVE-2026-49869	—	CVSS 10. Filtro por sufijo sobre el endpoint público de configuración; corregido en 1.0.45 y 1.3.21
Marcos de referencia	OWASP LLM Top 10 (cadena de suministro / agencia excesiva), MITRE ATT&CK T1190, T1552.001, T1496	2026	Explotación de aplicación expuesta → credenciales en ficheros → secuestro de recursos

Fecha de publicación de la fuente principal: 26 de agosto de 2026. Los niveles de confianza de Microsoft varían según el caso y se reproducen arriba tal como fueron publicados: alta confianza en los accesos iniciales de LiteLLM y Kestra, baja confianza en el punto de ejecución de RAGFlow.