LiteLLM — Compromiso de la Cadena de Suministro mediante Ganchos de Inicio de Python en la Versión 1.107.0

Fecha de publicación: 23 de octubre de 2026
Categoría: Supply Chain Attacks / Incident Response

Introducción

El 21 de octubre de 2026, los mantenedores de dependencias y analistas de seguridad identificaron un compromiso severo en la cadena de suministro de software que afectó al paquete LiteLLM 1.107.0. Esta versión maliciosa fue publicada en el índice oficial de Python Package Index (PyPI) y distribuida a través de imágenes de contenedores oficiales. Investigaciones realizadas por Microsoft Security revelaron que actores maliciosos lograron vulnerar las credenciales de un desarrollador para desviar el flujo de entrega hacia un repositorio réplica (Berri-AI/litellm), utilizando posteriormente otra cuenta para aprobar el despliegue a producción. A diferencia de ataques tradicionales en bibliotecas de terceros, el paquete comprometido no requería que la aplicación importara explícitamente LiteLLM: la simple inicialización del intérprete de Python en un entorno afectado bastaba para activar la carga maliciosa y comprometer información crítica de autenticación.

¿Qué es el Componente Afectado y el Incidente? (Análisis General)

LiteLLM es una pasarela ampliamente utilizada que actúa como intermediario entre aplicaciones y múltiples proveedores de modelos de lenguaje grande (LLM). Debido a su rol arquitectónico, almacena o gestiona claves de API de proveedores de modelos, cadenas de conexión a bases de datos, identidades de carga de trabajo, configuraciones de enrutamiento y políticas de inquilinos. Su adopción no se limita a servidores de pasarela, sino que abarca estaciones de trabajo de desarrolladores, agentes de integración continua (CI/CD), sistemas de pruebas y entornos contenerizados, ampliando significativamente la superficie de exposición.

Dado que este incidente no cuenta con un identificador CVE asignado oficialmente en la base de datos NVD al momento de la redacción, se evalúa el riesgo bajo una estimación razonada de severidad Crítica (CVSS v3.1: 9.8 / Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), clasificado conceptualmente bajo la categoría CWE-506 (Embedded Malicious Code) y CWE-434 (Unrestricted Upload of File with Dangerous Type) adaptado a manipulación de canal de despliegue.

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

El análisis forense de las ruedas (wheels) comprometidas permitió identificar múltiples rutas de ejecución automatizada durante el arranque del entorno de Python, separadas en dos mecanismos principales diseñados para la recolección de datos y la persistencia remota.

  • Flujo inicial de infección y ejecución automática: El paquete malicioso empaquetaba tres componentes críticos ubicados fuera del directorio de la aplicación: cook.pth, cook.py y sitecustomize.py en la ruta litellm-1.107.0.data/purelib/. Durante la instalación, estos archivos se trasladaron al directorio de la biblioteca del entorno Python. El archivo cook.pth contenía una única línea ejecutable (import cook), la cual cargaba de inmediato a cook.py. Este script utilizaba decodificación Base64 y descompresión zlib para extraer y ejecutar en memoria un programa malicioso autodenominado PRIVCOLLECT, el cual operaba en un hilo en segundo plano (daemon thread).

  • Mecanismos de control de duplicados y recolección de credenciales: Antes de iniciar la recolección, el hilo verificaba la variable de entorno PRIVCOLLECT_ACTIVE. Si no estaba presente, establecía el indicador para evitar duplicados en procesos descendentes y procedía a ejecutar módulos secuenciales de extracción. Los objetivos abarcaban herramientas de desarrollo y asistentes de IA (archivos de configuración de IDEs y extensiones de VS Code), repositorios de código fuente, credenciales de nube (AWS, Azure CLI, Google Cloud, archivos de cuentas de servicio de Kubernetes y metadatos de instancias), historiales de navegadores web (Chromium y Firefox), variables de entorno adicionales mediante procfs en Linux, claves privadas (SSH, GPG, TLS) y tablas específicas del proxy de LiteLLM a través de consultas Prisma con un límite estricto de filas.

  • Cifrado, exfiltración y cargador secundario en sistemas Unix: Los datos recolectados se serializaban en formato JSON, se cifraban utilizando una clave AES-256-CBC generada aleatoriamente (con su respectivo vector de inicialización) y se encapsulaban mediante una llave pública RSA de 4,096 bits utilizando criptografía OAEP. La carga empaquetaba estos elementos en un archivo tar comprimido en gzip y realizaba una solicitud HTTP POST al punto de control hxxp://www[.]litellm[.]dev/healthcheck. En sistemas basados en Unix, el archivo sitecustomize.py implementaba además un cargador secundario protegido por exclusión mutua (/tmp/remote_code_loader.lock) que consultaba periódicamente un puntero en GitHub (domain.txt) para recuperar y ejecutar código Python adicional de forma remota desde /codepy, operando como un mecanismo de ejecución rearmable.

Sistemas / Entornos Afectados

El incidente afectó a todos los entornos donde se instaló la versión específica de la cadena de suministro o se utilizaron imágenes de contenedores derivadas de la misma.

Componente / Entorno Versión Afectada Tipo de Impacto
litellm (PyPI package) 1.107.0 Ejecución de ganchos de inicio maliciosos y robo de credenciales
Contenedores Oficiales Imágenes con v1.107.0 integrada Exposición automática de secretos de carga de trabajo y pasarela
Estaciones de Trabajo y CI/CD Entornos de desarrollo con la librería instalada Extracción de tokens de control de versiones, SSH y herramientas de IA

Mitigación y Detección

Remediación

Para lograr una recuperación efectiva, no basta con eliminar el paquete o la etiqueta de la versión afectada del entorno. Las organizaciones deben seguir un protocolo estricto:

  1. Aislamiento del entorno: Detener la ejecución de procesos de Python y prevenir reinicios automáticos mediante automatización. No ejecutar comandos como python o pip en entornos sospechosos para evitar activar la recolección.
  2. Limpieza profunda: Verificar y garantizar la eliminación completa de los archivos cook.pth, cook.py y sitecustomize.py de las rutas de bibliotecas del sistema. Se recomienda reconstruir los artefactos desde fuentes verificadas.
  3. Rotación integral de credenciales: Rotar de forma inmediata y desde una máquina limpia todas las claves de proveedores de modelos, credenciales de nube, secretos de CI/CD, tokens de control de archivos, claves SSH/GPG y sesiones de navegador accesibles por la identidad comprometida. Revocar explícitamente las sesiones activas en plataformas como Microsoft Entra ID.
  4. Endurecimiento de dependencias: Utilizar archivos de bloqueo con huellas hash (hash-pinned lock files), verificar la procedencia de imágenes mediante digests inmutables y restringir el acceso saliente de red no esencial en pasarelas y estaciones de desarrollo.

Detección

Los equipos de seguridad defensiva pueden apoyarse en reglas de detección para Microsoft Defender for Endpoint y consultas avanzadas de rastreo de amenazas (Advanced Hunting):

kusto 
// Consulta KQL para detectar conexiones al dominio de exfiltración asociado
DeviceNetworkEvents
| extend UrlForParsing = iff(RemoteUrl contains "://", RemoteUrl, strcat("http://", RemoteUrl))
| extend RemoteHost = trim_end(@"\.", tolower(tostring(parse_url(UrlForParsing).Host)))
| where RemoteHost in ("www.litellm.dev", "litellm.dev")
| project Timestamp, DeviceId, DeviceName, ActionType, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName

Nota de Inteligencia Defensiva: La presencia de los archivos de inicio (cook.pth, cook.py, sitecustomize.py) o la actividad de cifrado mediante OpenSSL utilizando rutas temporales de almacenamiento con el prefijo .pc_e_ en procesos de Python constituyen indicadores inequívocos de exposición que requieren una investigación forense inmediata.

Recapitulando

El compromiso de la cadena de suministro de LiteLLM 1.107.0 demuestra cómo los atacantes continúan diversificando sus vectores de ataque más allá de la simple inserción de código funcional en bibliotecas, aprovechando mecanismos nativos de inicialización de intérpretes como los ganchos de inicio de Python (.pth) para lograr ejecución de código sin la intervención explícita de la aplicación. La rápida detección por parte de los servicios de telemetría y la respuesta coordinada subrayan la importancia vital de implementar controles estrictos en la gestión de dependencias, auditorías rigurosas de flujos de integración continua (CI/CD) y una estricta segmentación de privilegios en entornos orientados a la inteligencia artificial.

Referencias

  • Microsoft Security. (2026). Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks. Microsoft Security Blog. Recuperado de https://www.microsoft.com/en-us/security/blog/?p=150238
  • LiteLLM. (2026). Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised.
  • Python Software Foundation. Site-specific configuration hook documentation.