El paquete malicioso se ejecutaba al iniciar Python, sin que la aplicación usara LiteLLM, exponiendo credenciales de desarrolladores, claves de proveedores de IA y datos de infraestructura en cloud.
El 21 de octubre de 2026, una versión comprometida de LiteLLM 1.107.0 fue publicada en el Python Package Index (PyPI) y distribuida a través de imágenes de contenedores oficiales. El código malicioso se ejecutaba durante la inicialización normal del intérprete de Python, sin requerir que la aplicación importara LiteLLM. Según el análisis de Microsoft, bastaba con iniciar Python en un entorno afectado para activar el payload. LiteLLM se despliega comúnmente como puerta de enlace entre aplicaciones y proveedores de modelos, con acceso potencial a claves API de proveedores, cadenas de conexión de bases de datos, identidades de carga de trabajo y datos de política de inquilino.
Cómo credenciales robadas de GitHub permitieron alterar el flujo de lanzamiento
Según los mantenedores de LiteLLM, credenciales robadas de GitHub de un desarrollador fueron utilizadas para alterar el flujo de lanzamiento y redirigirlo al repositorio similar Berri-AI/litellm en lugar del repositorio legítimo BerriAI/litellm. Una credencial asociada a otra cuenta de desarrollador fue utilizada para satisfacer un paso de aprobación de producción. Microsoft no determinó de forma independiente cómo el atacante accedió inicialmente al entorno upstream ni obtuvo esas credenciales. El paquete comprometido usó mecanismos de inicio de Python para ejecutar código malicioso automáticamente, lo que significa que la exposición no se limitó a sistemas que ejecutaban activamente una puerta de enlace LiteLLM. Estaciones de trabajo de desarrolladores, agentes de integración continua, entornos de prueba, contenedores y otros sistemas que iniciaron Python con el paquete afectado instalado también pudieron ejecutar el payload.
Dos rutas de ejecución en los wheels afectados: extensión de ruta y configuración de sitio
Microsoft identificó dos rutas de ejecución en los wheels afectados. Un recolector de credenciales se lanzaba a través de extensión de ruta, y un cargador orientado a Unix se persistía a través de configuración específica del sitio. El wheel comprometido empaquetó cook.pth, cook.py y sitecustomize.py bajo litellm-1.107.0.data/purelib/. Durante la instalación, estos archivos se reubicaron en el directorio de biblioteca del entorno Python, fuera del directorio normal de la aplicación litellm. Esta ubicación permitió la ejecución a través de la inicialización normal del sitio de Python, que procesa declaraciones de importación ejecutables en archivos .pth y luego intenta importar el módulo sitecustomize. La primera ruta de ejecución comenzó con la línea ejecutable en cook.pth: «import cook». Esto cargó cook.py, cuyo wrapper decodificó en Base64 y descomprimió con zlib un programa Python embebido antes de ejecutar el código fuente recuperado. El programa se identificó como PRIVCOLLECT y realizó la recolección de credenciales en un hilo daemon.
Qué credenciales y datos sensibles apuntaba el recolector
El recolector de credenciales apuntaba a material de autenticación en herramientas de desarrollador, aplicaciones de IA, entornos en la nube, navegadores e infraestructura. Un módulo de base de datos separado intentaba leer registros de credenciales y configuración de modelos seleccionados del proxy LiteLLM. Se observaron comportamientos de descubrimiento, encriptación y conexión saliente en Windows y macOS. En un ejemplo de Windows, una invocación rutinaria de Python para instalar una dependencia no relacionada activó el recolector. Antes de iniciar el hilo, el recolector verificaba la variable de entorno heredada PRIVCOLLECT_ACTIVE. Un valor no vacío hacía que retornara; de lo contrario, establecía la bandera, limitando la recolección duplicada en procesos descendientes. Después de que una carga devolviera HTTP 200, intentaba escribir /tmp/.pc_once_72129118c59f5636c0bb. Estas compuertas de supresión de duplicados no eran controles de contención: el inicio solo no probaba que la recolección o carga se completara, porque un proceso de corta duración podía salir antes de que el hilo terminara, mientras que fallas de escritura o cambios de almacenamiento temporal podían dejar el marcador ausente.
Exposición en América Latina: dependencia de LiteLLM en infraestructura de IA y desarrollo
La exposición en América Latina está vinculada a la adopción de LiteLLM en infraestructura de IA y entornos de desarrollo. Empresas en Brasil, México, Argentina y Chile que despliegan puertas de enlace de modelos de lenguaje o que utilizan LiteLLM en pipelines de CI/CD pudieron haber instalado la versión comprometida. La distinción crítica es que no se requería uso activo de LiteLLM: cualquier sistema que iniciara Python con el paquete instalado ejecutaba el payload. Esto amplía la superficie de exposición a estaciones de trabajo de desarrolladores, agentes de build, contenedores de prueba y entornos de staging. La dependencia de PyPI como fuente única de paquetes, sin validación adicional de integridad en muchas organizaciones de la región, aumenta la probabilidad de que la versión maliciosa haya sido instalada automáticamente en actualizaciones de dependencias. No se reportaron datos específicos de LATAM en el análisis de Microsoft, pero la estructura de exposición es comparable a la de otras regiones con adopción de herramientas de IA en Python.
Nuestro análisis
Este compromiso revela un patrón de ataque a la cadena de suministro que combina credenciales robadas de desarrolladores con mecanismos de persistencia en el ecosistema Python. La redirección del flujo de lanzamiento a un repositorio similar (Berri-AI en lugar de BerriAI) muestra que el atacante comprendía la infraestructura de CI/CD de LiteLLM y pudo manipular pasos de aprobación de producción. La ejecución automática a través de archivos .pth y sitecustomize.py es una técnica documentada en ataques previos a paquetes Python, pero su aplicación a un paquete ampliamente desplegado en infraestructura de IA amplifica el impacto potencial. La recolección de credenciales no se limitó a claves de API de modelos: apuntó a material de autenticación en navegadores, herramientas de desarrollador, entornos cloud y SSH, lo que sugiere un objetivo de movimiento lateral más allá del contexto inmediato de LiteLLM.
La distinción entre exposición y exfiltración confirmada es crítica para la respuesta. Microsoft observó comportamientos de descubrimiento, encriptación y conexión saliente en Windows y macOS, pero no confirmó la ejecución del código adicional soportado en sistemas Unix. Las compuertas de supresión de duplicados (variable de entorno PRIVCOLLECT_ACTIVE y marcador en /tmp/) no garantizan que la recolección se haya completado, porque procesos de corta duración pudieron salir antes de que el hilo daemon terminara. Esto significa que la ausencia del marcador no descarta exposición, y la presencia del paquete instalado no confirma exfiltración exitosa. La recomendación de Microsoft de no iniciar Python o pip dentro de un entorno sospechoso para determinar si el paquete malicioso está presente subraya que la investigación forense debe realizarse desde un entorno limpio, porque el inicio del intérprete activa el payload. ¿Qué pasaría si el patrón de credenciales robadas de desarrolladores para alterar flujos de CI/CD se repitiera en otros paquetes críticos del ecosistema Python?