Una investigación reciente alerta sobre Malicious LiteLLM: en marzo se publicaron en PyPI dos releases que contenían código diseñado para robar credenciales. Aunque el tiempo de exposición fue corto, los efectos pueden persistir si las claves y tokens no se rotan o revocan.
La cadena de ataque se enmarca en un incidente mayor vinculado a la campaña de suministro asociada a Trivy/TeamPCP. Según los análisis disponibles, el software comprometido podía capturar información sensible de sistemas donde se instaló, incluyendo claves de nube, SSH, tokens de Kubernetes y contraseñas de bases de datos.
Qué fue Malicious LiteLLM y por qué importa
LiteLLM es una pasarela de IA de código abierto que permite conectar aplicaciones con múltiples proveedores de modelos. El proyecto identificó como comprometidas las versiones 1.82.7 y 1.82.8. Estas versiones estuvieron disponibles en PyPI durante aproximadamente 40 minutos el 24 de marzo, antes de que la plataforma las pusiera en cuarentena.
Lo crítico es el tipo de comportamiento observado. Los paquetes maliciosos no solo intentaban recopilar información: estaban pensados para extraer secretos y enviarlos a un dominio controlado por el atacante. Ese objetivo es precisamente lo que vuelve el problema más que un simple “incidente de malware”: si el entorno conserva credenciales válidas, el daño puede continuar.
Qué credenciales podía intentar robar
El código malicioso descrito en el reporte buscaba capturar datos de entorno y activos típicos en entornos de desarrollo y despliegue. Entre los elementos mencionados se incluyen:
- Variables de entorno con claves de API de modelos (por ejemplo, OPENAI_API_KEY y ANTHROPIC_API_KEY).
- Claves SSH.
- Credenciales de nube.
- Tokens de Kubernetes.
- Contraseñas de bases de datos.
Además, una de las versiones comprometidas incluía un archivo llamado litellm_init.pth. Ese tipo de fichero se ejecuta en el inicio del intérprete de Python, por lo que el comportamiento podía ocurrir al arrancar cualquier proceso de Python en ese entorno, incluso si no se importaba específicamente LiteLLM.
Cómo se determinó el alcance (y por qué no es un “número de víctimas”)
El análisis de inteligencia publicado por CloudSEK sugiere un volumen grande de materiales capturados. El conjunto de datos se construyó a partir de alrededor de 434.000 archivos asociados a la campaña, y se mapea a potenciales exposiciones que afectarían a 2.500+ organizaciones (según el informe).
Sin embargo, la propia fuente remarca que esas cifras no deben interpretarse como recuento de víctimas. Parte de ese material corresponde a “botín” y registros vinculados a la campaña que fueron evaluados como pertenecientes a la actividad, y el dataset publicado funciona como una herramienta de consulta.
De forma operativa, CloudSEK publicó un repositorio de búsqueda. Cada fila incluye el nombre y dominio de la organización, contadores de secretos expuestos y recuentos de ejecuciones, además de una etiqueta de confianza (High o Medium).
Alta vs. media confianza
La etiqueta de alta confianza depende de señales de identidad del entorno de CI (por ejemplo, identidad del host y dominios de committer legítimos) y exige que el dominio de la organización aparezca antes de asignar el nivel superior. En cambio, el namespace del repositorio solo habilita el veredicto de confianza media.
En este contexto, incluso cuando una organización aparece en los resultados, no se concluye automáticamente que las credenciales robadas se hayan usado. Por esa razón, el consejo general se centra en rotar secretos, en lugar de esperar evidencia adicional.
Qué dijeron las versiones y el estado en PyPI
Según las verificaciones reportadas, PyPI no muestra que las versiones 1.82.7 y 1.82.8 aparezcan en el historial de releases del paquete. En cambio, las versiones 1.82.6 y 1.83.0 sí permanecían disponibles.
El proyecto advierte a los usuarios que traten como sospechosas cualquier instalación ocurrida entre 10:39 UTC y 16:00 UTC del mismo día en que se detectó la actividad (marcando el marco del incidente de marzo).
En otras palabras: incluso si una instalación parece “poco probable” por la corta ventana, es precisamente esa brevedad lo que hace necesario revisar fechas y rotar credenciales potencialmente accesibles.
La conexión Trivy/TeamPCP y el contexto de supply chain
Este caso no se entiende por completo sin la referencia a la campaña más amplia. El incidente se integra en TeamPCP, descrita como una campaña de supply chain asociada a la investigación vinculada a Aqua Security y al escáner Trivy.
Los registros públicos mencionan que se forzaron commits maliciosos en múltiples etiquetas de una acción relacionada (76 de 77 tags de una variante, más siete tags de setup) y se publicó una release maliciosa de un componente (Trivy 0.69.4). Además, la campaña se sigue bajo identificación UNC6780.
En catálogos públicos, el ecosistema afectado está ligado a CVE-2026-33634, incorporada al registro de vulnerabilidades explotadas conocidas de CISA el 26 de marzo. También se indica que la entrada de CVE terminó listando las versiones afectadas de LiteLLM junto con los componentes relacionados con Trivy.
FBI: rotar credenciales y tokens, no “solo esperar pruebas”
La orientación incluida en el advisory del FBI advierte que actores vinculados podrían aprovechar credenciales exfiltradas durante la ventana temporal del compromiso, incluso mucho después del acceso inicial.
Por ello, las recomendaciones se centran en el ciclo de vida del secreto. Un token o clave copiada durante esa ventana sigue siendo utilizable hasta que sea rotada o revocada. La recomendación, por tanto, apunta a proteger credenciales de CI/CD, tokens publicados y credenciales de nube accesibles en el periodo.
Además, se insiste en reducir el uso de tokens de larga duración y migrar hacia mecanismos temporales, siguiendo prácticas de seguridad que limitan el impacto del exfiltrado.
Indicadores adicionales: repositorios y artefactos
El análisis menciona indicadores operativos adicionales que podrían pasar desapercibidos si se buscan únicamente términos “visibles”. En particular, el FBI lista como señales de campaña repositorios con nombres tpcp-docs o docs-tpcp.
Para aumentar la probabilidad de detección, también se señala que el malware puede haber creado repositorios con prefijos como tpcp-docs- y subir datos como activos de release con el patrón data-<timestamp>. Esto implica que una búsqueda exacta por nombre puede no bastar.
Qué hacer si usaste LiteLLM (pasos concretos)
Para organizaciones que necesiten evaluar impacto, se recomiendan tres acciones principales:
- Revisar instalaciones de LiteLLM 1.82.7 o 1.82.8 durante la ventana del 24 de marzo (entre 10:39 UTC y 16:00 UTC).
- Rotar cualquier secreto y credencial que los sistemas comprometidos pudieran haber accedido.
- Buscar actividad en organizaciones de GitHub por repositorios denominados tpcp-docs o docs-tpcp, y considerar variaciones con prefijos y artefactos etiquetados con el patrón indicado.
La idea es clara: incluso si no hay confirmación perfecta de uso malicioso posterior, el riesgo práctico de credenciales válidas justifica actuar con prioridad.
Por qué puede que el “cómo” no coincida del todo
En los reportes públicos también aparece una discrepancia sobre la vía exacta mediante la cual se alcanzó PyPI. CloudSEK sostiene una interpretación, mientras que el informe del proyecto apunta a un upload directo que habría evitado su flujo de CI/CD oficial, y Unit 42 describe un enfoque relacionado con el robo de tokens de publicación tras la brecha de Trivy.
CloudSEK, al responder, indica que serían etapas diferentes de una misma cadena. En otras palabras, aunque la atribución del flujo exacto puede variar entre informes, el resultado operativo para defensas sigue siendo el mismo: los paquetes maliciosos estuvieron disponibles y el código buscaba extraer secretos.
Conclusión: trata Malicious LiteLLM como un incidente de credenciales
Malicious LiteLLM demuestra cómo, en una cadena de suministro, un componente comprometido puede convertirse en una puerta para robar credenciales y persistir en el tiempo si los secretos no se rotan. La ventana fue corta, pero la acción defensiva debe ser inmediata y enfocada en credenciales, tokens y llaves con acceso a sistemas de CI/CD y nube.
Si operaste LiteLLM en la fecha y rango mencionados, revisa el historial de despliegues, rota todo lo que hubiera podido ser alcanzado y verifica señales relacionadas en GitHub. Es la forma más efectiva de reducir el riesgo, incluso cuando el alcance exacto no se pueda expresar como un número de víctimas.
Fuente: https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
