La vulneración de LiteLLM 1.107.0 inyecta un ladrón de credenciales a través de la cadena de compilación
Una versión maliciosa de LiteLLM en PyPI instaló un ladrón de credenciales y una puerta trasera al modificar la configuración de compilación, afectando a todos los principales sistemas operativos.
Traducido automáticamente del original en inglés.
El 21 de octubre de 2026, investigadores de seguridad identificaron que la versión 1.107.0 de LiteLLM, publicada en el Python Package Index (PyPI), contenía un ladrón de credenciales y una puerta trasera para la ejecución remota de código. El paquete comprometido afectó a entornos Linux, macOS y Windows mediante la inyección directa de archivos maliciosos en el directorio site-packages de Python durante la instalación. PyPI ha retirado desde entonces dicha versión, pero el incidente pone de manifiesto riesgos significativos para la integridad de la cadena de suministro de software.
Qué ocurrió
El ataque se dirigió contra el proceso de compilación de LiteLLM, una biblioteca popular para integrar modelos de lenguaje grandes. Cuando los desarrolladores instalaron la versión 1.107.0 usando pip, tres archivos específicos fueron colocados en su carpeta site-packages: cook.pth, cook.py y sitecustomize.py. A diferencia del malware típico que requiere sentencias de importación explícitas para ejecutarse, estos archivos se ejecutaban automáticamente cada vez que cualquier proceso de Python iniciaba en la máquina anfitriona. Esto significaba que incluso aplicaciones que no usaban directamente LiteLLM podían activar el código malicioso si compartían el mismo entorno de Python.
El repositorio de código fuente upstream en GitHub no contenía estos archivos maliciosos. El análisis forense reveló que la distribución de código fuente (sdist) para la versión 1.107.0 incluía un archivo pyproject.toml modificado con una línea inyectada: data = "cook". Esta instrucción dirigía a la herramienta de compilación, maturin, para copiar una carpeta oculta cook/ dentro del paquete wheel final. La propia sdist omitía la carpeta cook/, haciendo que la inyección fuera visible solo en las wheels binarias compiladas distribuidas a través de PyPI. Se confirmó que las versiones 1.106.2, 1.107.0rc1 y 1.107.0rc2 estaban limpias, al igual que los paquetes complementarios litellm-proxy-extras y litellm-enterprise.
Cómo funciona
La carga útil maliciosa operaba a través de dos mecanismos principales desencadenados por el comportamiento de inicio de Python. Primero, el archivo cook.pth contenía el comando import cook. Python ejecuta automáticamente las sentencias de importación encontradas en los archivos .pth ubicados en site-packages al iniciar. Esto provocaba que cook.py se ejecutara en cada proceso de Python, incluyendo IDEs, pipelines de CI y servicios en segundo plano. El script recopilaba datos sensibles como claves SSH, credenciales de nube, secretos de CI/CD, contraseñas de navegador y tokens de proveedores de LLM. Luego cifraba estos datos y los exfiltraba hacia un dominio controlado por los atacantes, www.litellm[.]dev.
Segundo, el archivo sitecustomize.py establecía una puerta trasera persistente. Este script lanzaba un daemon en segundo plano que revisaba cada hora un archivo remoto en GitHub para obtener una dirección de servidor. Al recibir instrucciones, el daemon descargaba y ejecutaba código adicional desde ese servidor. Los atacantes ofuscaban el código dentro de cook.py utilizando codificación base64 y compresión zlib, envolviendo aproximadamente 61 KB de código Python en una sola línea de ejecución para evadir el análisis estático simple.
Las evidencias forenses sugieren que la vulneración ocurrió dentro del pipeline privado de lanzamiento del mantenedor, en lugar de a través de una ejecución pública de GitHub Actions. Las marcas de tiempo en las wheels compiladas indicaban builds nativos separados para macOS, Linux y Windows, consistentes con un entorno local o de CI privado. La ausencia de atestaciones de procedencia en PyPI y la discrepancia entre la etiqueta git y la distribución de código fuente respaldan aún más la teoría de que un atacante modificó el código fuente antes de que entrara en el sistema de compilación, posiblemente utilizando credenciales comprometidas o una rama privada.
Detalles clave
- Versión afectada: Solo LiteLLM 1.107.0 en PyPI fue comprometida; las versiones anteriores y las candidatas a lanzamiento son seguras.
- Método de inyección: Un archivo
pyproject.tomlmodificado instruía a la herramienta de compilación maturin para incluir un directorio maliciosocook/en la wheel. - Persistencia: El malware utilizaba
cook.pthysitecustomize.pypara ejecutarse automáticamente al iniciar cualquier proceso de Python. - Robo de datos: El ladrón apuntaba a claves SSH, credenciales de nube, tokens de IA y contraseñas de navegador, enviándolos a
www.litellm[.]dev. - Discrepancia de origen: La etiqueta git
v1.107.0apuntaba a un commit con la versión 1.108.0, mientras que la sdist coincidía con un commit posterior con ediciones manuales para revertir la versión y añadir la carga útil. - Impacto en plataformas: Las siete variantes de wheel (Linux, macOS, Windows) contenían los archivos maliciosos, asegurando la infección multiplataforma.
Por qué es importante
Este incidente demuestra que verificar el código fuente en repositorios públicos como GitHub es insuficiente para garantizar la seguridad de la cadena de suministro. Los atacantes pueden interceptar el proceso de compilación o modificar artefactos después de etiquetar el código fuente pero antes de la publicación. Para los equipos de ingeniería, esto significa que confiar en un paquete basándose únicamente en el historial de su repositorio es arriesgado. El uso de archivos .pth para lograr la ejecución de código sin importaciones explícitas evade muchas comprobaciones de seguridad estándar que buscan llamadas a funciones peligrosas en el código de aplicación.
Además, la falta de atestaciones de procedencia en PyPI dificultó la verificación inmediata del origen de las wheels compiladas. Sin pruebas criptográficas que vinculen el artefacto construido con un proceso de compilación específico y verificado, los defensores deben depender de análisis forenses reactivos. Este retraso permite que los paquetes maliciosos permanezcan en circulación durante más tiempo, aumentando la ventana de exposición para organizaciones que automatizan las actualizaciones de dependencias.
Qué puede hacer
- Desinstale inmediatamente LiteLLM versión 1.107.0 si está presente en cualquier entorno:
pip uninstall litellm==1.107.0. - Rote todas las credenciales, claves API y secretos almacenados en máquinas que puedan haber instalado la versión comprometida.
- Compruebe la presencia de
cook.pth,cook.pyysitecustomize.pyen su directoriosite-packagesde Python. - Fije las dependencias a versiones conocidas y seguras, como 1.106.2 o 1.107.0rc2, hasta que se publique un parche verificado.
- Habilite las comprobaciones de procedencia de dependencias donde estén disponibles y prefiera paquetes que proporcionen metadatos de atestación.
- Monitoree los registros de red para detectar conexiones salientes hacia
www.litellm[.]devo patrones inusuales de exfiltración de datos.



