Incidente de compromiso de los paquetes de PyPI de LiteLLM 1.82.7 y 1.82.8

• En dos versiones del paquete de PyPI de LiteLLM, una biblioteca de integración de LLM ampliamente usada (1.82.7 y 1.82.8), se insertó una carga maliciosa y se distribuyó, provocando un ataque que roba credenciales del sistema al instalarse
• La causa del ataque se originó en un compromiso de la cadena de suministro de Trivy, una herramienta de escaneo de seguridad para CI/CD; se filtraron credenciales de CircleCI y con ello se robaron el token de publicación de PyPI y el GitHub PAT
• Los usuarios de la imagen oficial de LiteLLM Proxy Docker no se vieron afectados porque la versión estaba fijada en requirements.txt, pero los entornos que hicieron pip install directamente desde PyPI necesitan revisión inmediata
• Cientos de comentarios spam de bots inundaron el hilo del issue en GitHub e interfirieron con la discusión real; se confirmó que el atacante lo hizo deliberadamente para entorpecer la comunicación de respuesta
• También hubo impacto en muchos proyectos que usan LiteLLM como dependencia, como DSPy y CrewAI, lo que volvió a poner en evidencia la vulnerabilidad fundamental de la seguridad de la cadena de suministro de software

---

Resumen del incidente y cómo se descubrió

• Mientras se configuraba un proyecto nuevo, el sistema comenzó a comportarse de forma anormal, agotando la RAM y ejecutando procesos con forma de fork bomb
• La investigación encontró que en proxy_server.py se había agregado un blob malicioso codificado en base64, que se decodificaba para crear un archivo aparte y luego ejecutarlo
• La versión 1.82.7 incluía la carga en litellm/proxy/proxy_server.py y se ejecutaba al hacer import litellm.proxy
• La versión 1.82.8 además incluía el archivo litellm_init.pth, de modo que con solo instalar el paquete, el malware se ejecutaba automáticamente al iniciar Python
  • Los archivos .pth usan un mecanismo que el módulo site de Python ejecuta automáticamente al iniciar, y permiten ejecutar código arbitrario después de la palabra clave import
  • Este mecanismo existe desde Python 2.1 y se introdujo sin un PEP aparte
• El equipo de FutureSearch reportó la primera afectación: uvx instaló automáticamente la versión más reciente de litellm (sin fijar versión), y luego Cursor cargó automáticamente un servidor MCP local, provocando la infección

Ruta del ataque y relación con TeamPCP

• Se confirmó que el ataque fue realizado por el mismo actor que comprometió recientemente Trivy: el grupo TeamPCP
• Ruta del compromiso: hackeo de Trivy → filtración completa de credenciales de CircleCI → robo del token de publicación de PyPI + GitHub PAT → distribución del paquete malicioso
• Las cuentas de GitHub del CEO/CTO de LiteLLM también fueron totalmente comprometidas; las descripciones de todos sus repositorios personales se cambiaron a "teampcp owns BerriAI" y también se cerraron issues, entre otras acciones
• El token PYPI_PUBLISH estaba guardado como variable de entorno en el proyecto de GitHub, y eso se filtró a través de Trivy
  • La cuenta tenía 2FA habilitado, pero el robo del token permitió evadirlo
• Los atacantes publicaron repetidamente la misma frase en los issues de GitHub usando cientos de cuentas bot, bloqueando la discusión real
  • En el repositorio de Trivy también se confirmaron más de 700 comentarios spam con el mismo patrón
  • Algunas de esas cuentas de spam pertenecían a usuarios reales de GitHub con historial de contribuciones; se confirmó que desde febrero habían insertado ladrones de credenciales en workflows de CI con commits titulados "Update workflow configuration"
• El compromiso de Trivy ocurrió al menos 5 días antes y, como el aviso más reciente del ataque se publicó apenas el día anterior, es posible que el mantenimiento no estuviera enterado cuando ocurrió el daño
• Los atacantes también usaron canisters de Internet Computer Protocol (ICP) para entregar la carga, por lo que bloquear DNS por sí solo no basta como defensa

Cómo funcionaba la carga maliciosa

• Creaba un proceso de Python en segundo plano y decodificaba etapas incrustadas para ejecutarlas
• Se ejecutaba un recolector de credenciales que, si lograba reunir datos, cifraba la clave AES con la clave pública RSA del atacante y enviaba la información robada a un host remoto
• URLs encontradas en el malware: checkmarx.zone/raw y models.litellm.cloud
• Principalmente intentaba robar claves SSH de ~/.git-credentials e información de wallets cripto
• Como realizaba trabajo intensivo de CPU, sobrecargaba el sistema y eso facilitó su detección; incluso hubo reportes de personas que notaron algo raro por el ruido de los ventiladores
• Durante instalaciones de Harbor también se observó el mismo síntoma: procesos grep -r rpcuser\rpcpassword corriendo con patrón de fork bomb para buscar wallets cripto

Respuesta del equipo de LiteLLM

• Las versiones afectadas (v1.82.7 y v1.82.8) ya fueron eliminadas de PyPI
• Se cambiaron las contraseñas de todas las cuentas de mantenimiento y se borraron y reemplazaron todas las claves de GitHub/Docker/CircleCI/pip
• Las nuevas cuentas de mantenimiento fueron reemplazadas por @krrish-berri-2 y @ishaan-berri
• Todo el paquete fue puesto temporalmente en cuarentena en PyPI y luego se liberó tras eliminar las versiones infectadas
• Se suspendieron todos los nuevos releases y se congeló la distribución hasta completar una revisión de toda la cadena de suministro
• Se está trabajando con el equipo de seguridad de Google Mandiant en la investigación y recuperación
• Trivy quedó fijado en la última versión segura, v0.35.0 (cambiado desde la fijación inicial en v0.69.3 tras comentarios de la comunidad)
• A futuro se evalúan mejoras de seguridad como migrar a Trusted Publishing (OIDC con token JWT) y usar una cuenta separada de PyPI
• La hora inicial de publicación de la versión maliciosa fue aproximadamente UTC 8:30 y la cuarentena de PyPI ocurrió cerca de UTC 11:25

Alcance del impacto y proyectos downstream

• LiteLLM es la única biblioteca de llamadas a proveedores LLM en DSPy, y CrewAI también la usa como fallback
• Airflow, Dagster, Unsloth.ai, Polar y nanobot, entre otros, también dependen de LiteLLM
• Según búsquedas en GitHub, se encontraron más de 628 proyectos que incluyen LiteLLM en requirements.txt sin fijar versión
• Los usuarios de la ruta oficial de despliegue con Proxy Docker no se vieron afectados porque requirements.txt tenía la versión fijada
• En despliegues con Docker, el acceso al filesystem del host y a las variables de entorno está más restringido y por eso son relativamente más seguros, pero las credenciales montadas siguen en riesgo
  • El objetivo principal del atacante eran las claves SSH personales; el acceso a claves de LLM era secundario
• También hubo reportes de daño indirecto en usuarios de herramientas como Harbor y browser-use, que instalan LiteLLM automáticamente como dependencia
• CrewAI fijó litellm en 1.82.6 (la última versión segura), aunque el mensaje del commit no menciona el compromiso
• DSPy abrió un issue públicamente para responder al incidente
• LangChain tiene su propia capa para llamadas a proveedores LLM, por lo que no se vio afectado directamente por este compromiso de la cadena de suministro (salvo si se usa el paquete opcional langchain-litellm)

Debate de la comunidad: seguridad de la cadena de suministro y sandboxing

• Ya no se puede confiar en dependencias ni en entornos de desarrollo; se necesita defensa en profundidad, con aislamiento por VM + primitivas de contenedores + allowlists + filtros de salida + seccomp + gVisor
• Se ve como un retorno de 50 años de comodidad por encima de la seguridad, y se plantea rediseñar todo el modelo de seguridad
• También se propuso sandboxing a nivel de lenguaje de programación para cada módulo
  • Java tenía esta capacidad desde la versión 1.2 en los años 90, pero se abandonó por problemas de usabilidad
  • Algunos opinan que es el momento adecuado para desarrollar lenguajes basados en capabilities
  • Se mencionó el runtime workerd de Cloudflare como una solución existente capaz de aislar módulos
• Ya existen herramientas de aislamiento a nivel de sistema operativo, como pledge/unveil de OpenBSD, chroot/namespace/cgroup en Linux y Capsicum en FreeBSD
• Guix puede crear contenedores aislados en segundos para instalar dependencias sin acceso a $HOME
• Se destacó la necesidad de usar activamente herramientas de aislamiento en espacio de usuario como Firejail y bwrap
• En móviles ya existe un modelo de sandboxing + permisos (Intents), pero en escritorio suele haber más resistencia a limitar operaciones generales
  • Frente a eso, se argumentó que la seguridad por sandboxing y el carácter cerrado de las app stores de Apple/Meta son temas distintos, y que es posible construir herramientas que den control al usuario sin sacrificar seguridad
• Se compartió una herramienta de canary/honeypot para macOS (github.com/dweinstein/canary): monta secretos falsos en WebDAV/NFS para detectar accesos anómalos
• También se propuso que debe existir una barrera entre la publicación de paquetes y los repositorios públicos: configurar un repositorio público directamente como Trusted Publisher amplía la superficie de ataque
  • Como contraargumento, se señaló que el propósito original de Trusted Publishing es ofrecer un vínculo auditable entre el código fuente y el artefacto publicado, por lo que pasar por un repositorio privado sería un retroceso

Recomendaciones prácticas de seguridad

• Es imprescindible fijar versiones de dependencias junto con checksums SHA256
• Operar un mirror interno de paquetes para evitar usar directamente la versión más reciente
• Usar artefactos de build y no depender de instalaciones al vuelo en despliegue con uv run u otros comandos
  • Eso también elimina el riesgo estructural de que el sistema se caiga si PyPI tiene una interrupción
  • Entre las ventajas de los artefactos desplegables están la auditabilidad, los rollbacks rápidos y la posibilidad de bloquear endpoints peligrosos de red saliente
• Con exclude-newer de uv es posible excluir paquetes nuevos dentro de un período determinado
  • Se puede configurar en pyproject.toml como [tool.uv] exclude-newer = "5 days"
• En CI/CD, la solución de fondo es migrar los tokens de publicación a workflows basados en OIDC, eliminando el token mismo
  • Tanto GitHub como PyPI soportan OIDC: si solo se concede acceso al endpoint OIDC para tareas de publicación, no existe un token que Trivy pueda robar
• Herramientas de escaneo como Trivy deben ejecutarse en workers separados sin permisos de publicación
• Se recomienda gestionar lockfiles y actualizar semanalmente para evitar adoptar de inmediato la versión más reciente
• Los archivos .pth de Python permiten ejecución automática de código; la opción -S puede impedir la importación de site, aunque con posibles problemas de compatibilidad
• Se recomienda hacer un escaneo de todas las dependencias del proyecto con herramientas como osv-scanner
• Comandos para verificar si hubo infección:
  • find / -name "litellm_init.pth" -type f 2>/dev/null
  • find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
• También se planteó la necesidad de una rotación masiva de credenciales en todo el ecosistema de gestores de paquetes

Problemas de auditoría SOC2 y confiabilidad

• Se señaló que la empresa que auditó el SOC2 de LiteLLM fue Delve, recientemente envuelta en controversia
• SOC2 solo verifica si una organización sigue realmente los procesos documentados, pero no garantiza el nivel de seguridad en sí
• Incluso con un SOC2 adecuado, no está claro si habría prevenido este ataque a la cadena de suministro

Proyectos alternativos a LiteLLM

• Bifrost (github.com/maximhq/bifrost): alternativa basada en Rust, con configuración de claves virtuales incluso en instancias open source gratuitas
• Portkey (portkey.ai): servicio proxy, con plan gratuito, considerado por algunos más rápido que LiteLLM
• pydantic-ai: alternativa basada en Python
• any-llm (github.com/mozilla-ai/any-llm): proyecto de Mozilla
• LLM Gateway (llmgateway.io): ofrece una guía de migración desde LiteLLM
• InferXgate (github.com/jasmedia/InferXgate): proyecto nuevo, con soporte limitado de proveedores
• Algunos desarrolladores sostienen que las APIs de proveedores LLM en la práctica se reducen a OpenAI y Anthropic, por lo que llamar directamente con requests.post() sería más seguro
  • Como contraargumento, se señaló que la API compatible con OpenAI de Anthropic no se recomienda como solución de largo plazo o para producción, y que las APIs nativas de cada proveedor tienen funciones propias que no se pueden mapear al API de OpenAI

[GN⁺]

Opiniones en Hacker News

• Soy el maintainer de LiteLLM. La situación todavía está bajo investigación, pero hasta ahora esto es lo que sabemos

  1. El problema parece haberse originado en trivy usado en CI/CD (búsqueda relacionada, análisis)
  2. Si usas proxy docker, no te afecta. Eso es porque la versión estaba fijada en requirements.txt
  3. El paquete fue puesto en cuarentena en PyPI, así que se bloqueó su descarga
     Actualmente estamos revisando la causa raíz y las medidas para reforzar la seguridad, y lamentamos los inconvenientes
  • Eliminamos de PyPI las versiones afectadas (v1.82.7, v1.82.8). También rotamos todas las cuentas y claves de maintainers (GitHub, Docker, CircleCI, pip). Seguimos escaneando todo el proyecto y agradecemos la ayuda de expertos en seguridad (contacto: [e-mail])
  • Alguien dijo que parece que mi cuenta personal de GitHub también fue comprometida. En los resultados de búsqueda se ven rastros relacionados
  • Gracias por decir que mi “lo siento” sonó humano. Me anima saber que responder con sinceridad, en vez de un comunicado de disculpa formal, fue mejor recibido
  • Hubo una pregunta sobre por qué la rotación de credenciales no se hizo de inmediato. Parece que tendré que explicar por qué no se detectó en tan poco tiempo
  • Alguien compartió un script sencillo para encontrar la versión de litellm instalada en su sistema (enlace al script). No es perfecto, pero dice que puede escanear rápido entornos conda, .venv, uv y el sistema

• Seguimos sin poder confiar en las dependencias y los entornos de desarrollo. Los dev containers tienen poco aislamiento y además son incómodos de usar. Ahora hay que pasar a entornos de desarrollo basados en sandbox. Se necesitan entornos con aislamiento a nivel de VM, filtros de egress y capas defensivas como seccomp y gVisor. En un entorno así, incluso si ocurre una intrusión, el contenedor se termina de inmediato y el problema se puede identificar fácilmente

  • Parece que los atajos de seguridad de los últimos 50 años por fin regresaron como búmeran. La cultura de desarrollo basada en la confianza está llegando a su fin. Ya no basta con un simple sandboxing: hace falta rediseñar el modelo de seguridad en sí
  • Ya no sirve decir “como antes”. La seguridad verificable criptográficamente es obligatoria. Hay que ir hacia políticas como DISA STIG de Red Hat, que prohíben usar repositorios externos
  • Pide opiniones sobre su proyecto para aislar credenciales del contenedor (tightbeam, airlock)
  • Estoy desarrollando un proyecto open source llamado smolvm (enlace). Combina aislamiento a nivel de VM con soporte para contenedores, y apunta a un despliegue completo por máquina virtual. Estoy buscando gente para colaborar
  • Surgió la pregunta de si en ataques recientes a la cadena de suministro realmente ha habido escapes de dev containers

• Presenta una herramienta canary para macOS (enlace). Es un binario simple en Go que detecta archivos a los que un paquete no debería acceder. Expone secretos falsos por WebDAV o NFS y envía alertas cuando alguien intenta acceder. Con este enfoque tipo honeypot se pueden detectar comportamientos anómalos

• Esto está relacionado con la actividad de TeamPCP de las últimas semanas. Creo que la línea de tiempo que armé puede ser útil

  • Recibió comentarios diciendo que era un gran resumen. También hubo la broma de que la “playlist” fue lo más memorable
  • Alguien comentó que ya había visto el nombre TeamPCP en varios lugares, pero que era la primera vez que lo veía organizado así de claro
  • Hubo una pregunta sobre cómo logra mantener las actualizaciones tan al día

• Señalaron que el sistema de detección de spam de GitHub es demasiado débil. Dicen que al issue de litellm le llegaron más de 170 comentarios spam

  • Lo mismo pasó hace unos días en el repositorio de trivy. Cuando cerraron la discusión sobre el hackeo, aparecieron más de 700 comentarios spam. Algunas cuentas tenían historial de actividad real. Parece que los ataques de robo de credenciales se han extendido bastante. En varias cuentas se encontraron rastros de un commit de febrero, “Update workflow configuration”, que metía un credential stealer en CI
  • También hubo quejas de que reportar spam en GitHub requiere demasiados pasos y es ineficiente
  • Algunos mencionaron que también podrían ser simples cuentas bot

• Esperaba que algo así pasara tarde o temprano. Se intentó defender con fijación de versiones de dependencias, pero ni eso es perfecto. Por la complejidad de la cadena de suministro en open source, es imposible verificar todo el código. Gracias a los LLM, el riesgo de que el malware se propague en masa es 100 veces mayor

  • Hubo quien opinó que en el ecosistema de Rust el árbol de dependencias es tan profundo que resulta difícil verificarlo. Rust, Node y Python sufren problemas parecidos. En cambio, C/C++ usa gestores de paquetes del sistema, así que el costo de agregar dependencias es mayor y por eso es relativamente más seguro

• Si el código escrito por IA logra infiltrarse en LLVM o Linux, entonces sí estaríamos frente al verdadero problema de “trusting trust”

  • El problema de “Trusting Trust” ya tiene una propuesta de solución con Diverse Double-Compiling. Aun así, los ataques a la cadena de suministro siguen siendo un desafío difícil. La IA solo es una herramienta para escalar los ataques
  • Ahora todo genera desconfianza. Puede que solo un entorno airgap sea realmente seguro. Pero la mayoría de los datos están en la nube, y ni siquiera controlamos sus respaldos
  • Se está trabajando en crear software completamente verificable mediante cadenas de build determinísticas. El 93% de los paquetes de Debian ya tiene builds reproducibles. Pero aun así muchos desarrolladores siguen ejecutando curl | bash sin pensarlo. El caso del backdoor de XZ fue una señal de alarma sobre esta realidad
  • También hubo quien opinó que la única defensa es cambiar con frecuencia las APIs internas para que los LLM no puedan aprender el código del kernel
  • Si un ataque así se vuelve real, los servidores gubernamentales o la infraestructura cloud podrían sufrir daños masivos. Si además se combina con hacking a nivel estatal, el impacto podría llegar a billones de dólares. Aun así, creo que Linux es relativamente seguro

• Se mencionó que la firma auditora SOC2 de LiteLLM era Delve.

  • Pero también se dudó de que una certificación SOC2 pudiera haber evitado este ataque. Se compartieron experiencias de que en la práctica SOC2 no sirve como escudo total

• Al instalar Harbor, el CPU se disparó al 100% y el sistema se congeló. Parece que un proceso grep -r rpcuser\rpcpassword estaba buscando wallets de criptomonedas. Por suerte, no se instaló ningún backdoor

  • Otra persona dijo haber vivido lo mismo con browser-use. litellm se instaló como dependencia y el sistema se congeló. Invalidó sus tokens de GitHub y HuggingFace, pero preguntó si haría falta reinstalar el sistema operativo
  • También hubo una pregunta de “¿cómo viste tan rápido el proceso?”. Querían saber si siempre tiene abierto Activity Monitor
  • Incluso apareció la pregunta “¿qué es Harness?”

• Parece que este incidente fue obra del mismo grupo atacante, TeamPCP, que hackeó Trivy. Que el issue se llenara de comentarios bot sigue el mismo patrón. Es muy probable que haya sido un ataque automatizado con ayuda de LLM

  • Alguien preguntó por qué los atacantes llenan los issues de comentarios bot. Probablemente el objetivo sea generar confusión y retrasar la respuesta