LiteLLM — Compromiso de la cadena de suministro en el pipeline de publicación expone credenciales y despliega troyano de acceso remoto

Fecha de publicación: 22 de octubre de 2026
Categoría: Cloud Security / Data Breach

Introducción

El 21 de octubre de 2026, el ecosistema de inteligencia artificial y seguridad en la nube experimentó un grave incidente en la cadena de suministro cuando el proyecto LiteLLM sufrió el compromiso de su infraestructura de despliegue. Actores maliciosos lograron vulnerar múltiples controles de seguridad independientes para publicar la versión v1.107.0 en el repositorio PyPI y en los registros de contenedores Docker Hub y GitHub Container Registry (GHCR). La carga útil maliciosa integrada en estos artefactos incluía un recopilador de credenciales (stealer) y capacidades de troyano de acceso remoto (RAT). El hallazgo fue investigado y reportado inicialmente por analistas de firmas como Aikido, Wiz, Socket y JFrog, evidenciando una vez más los vectores emergentes de ataque vinculados al desarrollo asistido por IA y la gestión de credenciales en entornos DevOps.

¿Qué es LiteLLM? (Análisis General)

LiteLLM es una pasarela de código abierto ampliamente utilizada para estandarizar y simplificar la gestión de llamadas a diferentes modelos de lenguaje (LLMs) mediante una interfaz de API unificada. Al actuar como un intermediario crítico en infraestructuras corporativas y entornos de desarrollo, gestiona credenciales sensibles, claves de API de proveedores de IA y tokens de acceso a servicios en la nube.

Dado que el software procesa y almacena credenciales de alto valor, un compromiso en sus dependencias o artefactos oficiales transforma instantáneamente a la pasarela en una cabeza de playa perfecta para ataques de LLMjacking y movimiento lateral.

  • Vector CVSS estimado: CVSS v3.1 9.8 (Crítico) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Clasificación CWE estimada: CWE-506 (Embedded Malicious Code) / CWE-434 (Unrestricted Upload of File with Dangerous Type)
  • Nota: Al no existir registros en NVD a la fecha de este análisis, el vector y la severidad representan una estimación razonada basada en la naturaleza de la ejecución remota de código y la exfiltración masiva de secretos.

¿Cómo funciona? (Análisis Técnico)

El ataque a la cadena de suministro de LiteLLM destacó por una ejecución extremadamente sofisticada y el uso simultáneo de técnicas de persistencia y carga de código poco ortodoxas en el ecosistema Python.

  • Flujo inicial de infección y el vector .pth: Los usuarios que descargaron versiones no pinneadas de LiteLLM a través de pip o utilizaron las imágenes de Docker comprometidas ejecutaron involuntariamente código modificado. El paquete incluía un archivo de ruta personalizado (cook.pth) configurado para importar un script de Python llamado cook.py. Este script se deobfusca en tiempo de ejecución y ejecuta una rutina denominada privcollect.
  • Recolección de secretos y exfiltración: La rutina privcollect barre el sistema en busca de credenciales almacenadas, tokens de desarrollo, configuraciones de navegadores, secretos de servicios cloud y tokens de herramientas de IA. Los datos recolectados son empaquetados y exfiltrados mediante una solicitud HTTP POST al dominio litellm[.]dev/healthcheck.
  • Persistencia en entornos Unix mediante sitecustomize.py: En sistemas operativos basados en Linux y macOS, el intérprete de Python procesa de forma nativa el archivo sitecustomize.py. Los atacantes lo configuraron para consultar un repositorio temporal en GitHub (github[.]com/letters9813) con el fin de recuperar un fichero de texto de control (domain.txt). Si la respuesta es válida, el intérprete descarga un script de segunda etapa desde <domain>/codepy.
  • Demonio en segundo plano y comando y control (C2): El script descargado genera un proceso demonio en segundo plano que adquiere un bloqueo exclusivo en /tmp/remote_code_loader.lock para evitar múltiples instancias concurrentes. Posteriormente, entra en un bucle infinito que consulta periódicamente una URL de GitHub (raw[.]githubusercontent.com/letters9813/pythonclient-test/main/domain[.]txt) para actualizar dinámicamente su dominio C2 y descargar nuevas cargas útiles de Python.
  • Explotación y LLMjacking posterior: Investigadores de Wiz documentaron que, aproximadamente 4.5 horas después de la exfiltración, los atacantes comenzaron a validar activamente las credenciales de roles de instancias AWS capturadas de ejecutores de CI y nodos de Kubernetes comprometidos. Utilizando comandos como sts:GetCallerIdentity seguidos de llamadas a Bedrock (bedrock:ListFoundationModels), los operadores ejecutaron operaciones de LLMjacking para consumir recursos computacionales ajenos.

Sistemas / Entornos Afectados

El incidente afectó específicamente a las siguientes versiones y canales de distribución publicados el 21 de octubre de 2026 entre las 11:39 a.m. y las 2:20 p.m. UTC:

  • PyPI: Paquete litellm versión v1.107.0.
  • Docker Hub y GHCR: Etiquetas v1.107.0, latest, main-latest y main-stable.
  • Perfiles de riesgo: Organizaciones que utilizaron dependencias no acotadas (unpinned) en sus pipelines de despliegue automatizado o que desplegaron contenedores actualizados automáticamente durante la ventana de tiempo afectada.

Mitigación y Detección

Remediación

  1. Purga de artefactos: Eliminar inmediatamente la versión 1.107.0 de LiteLLM de todos los entornos de desarrollo, pruebas y producción.
  2. Aislamiento de hosts: Aislar temporalmente cualquier servidor o nodo de CI/CD donde se haya ejecutado la versión comprometida durante la ventana del incidente.
  3. Rotación masiva de credenciales: Asumir compromiso total y rotar inmediatamente todas las claves API, tokens de AWS, credenciales de proveedores de IA, tokens de GitHub y secretos de infraestructura accesibles desde los entornos afectados.
  4. Hardening del pipeline: Mantener los repositorios de lanzamiento en modo privado, hacer que las etiquetas de Docker sean inmutables y exigir firmas criptográficas en las imágenes de contenedores.

Detección

Los equipos de respuesta a incidentes (Blue Team) deben realizar búsquedas activas de los siguientes Indicadores de Compromiso (IoCs) y artefactos en sus sistemas:

  • Presencia de los archivos cook.pth, cook.py o sitecustomize.py con lógica de descarga externa en los directorios de Python.
  • Existencia del archivo de bloqueo /tmp/remote_code_loader.lock.
  • Solicitudes HTTP salientes hacia litellm[.]dev/healthcheck o dominios dinámicos obtenidos desde raw.githubusercontent.com/letters9813/.
  • Actividad inusual en registros de auditoría de AWS con llamadas repetidas a sts:GetCallerIdentity y bedrock:ListFoundationModels.

“Un solo despliegue comprometido puede otorgar a un atacante la capacidad de propagar código malicioso a lo largo de toda la cadena downstream. La lección fundamental es que un repositorio de código fuente limpio no garantiza la integridad del artefacto instalado.”

Recapitulando

El incidente de LiteLLM pone de relieve la vulnerabilidad crítica inherente a las cadenas de suministro de software moderno y el riesgo derivado de la gestión inadecuada de credenciales en entornos de desarrollo asistidos por IA. La exposición accidental de tokens de GitHub CLI a través de logs de despliegues internos permitió a los actores de amenaza secuestrar flujos de trabajo legítimos y distribuir un troyano sofisticado capaz de realizar LLMjacking. Las organizaciones deben adoptar prácticas estrictas de validación de dependencias (wheel vetting), inmutabilidad de registros y rotación automatizada de secretos para mitigar amenazas similares.

Referencias