LiteLLM atribuye el acceso inicial a una clave maestra expuesta y no revocada
LiteLLM atribuye la intrusión que terminó en la publicación maliciosa de v1.107.0 a una clave maestra de Agent Platform comprometida tras quedar en un repositorio público desde mayo. El proveedor detalla cómo esa credencial permitió obtener un token de propietario y alterar el proceso de publicación.
La investigación publicada por LiteLLM el 23 de octubre sitúa el acceso inicial varios meses antes de la publicación maliciosa de litellm==1.107.0: una clave maestra de Agent Platform quedó dentro de un archivo de configuración enviado a un repositorio público en mayo y no fue revocada. Según el análisis del propio proveedor, el atacante usó esa credencial el 10 de octubre para entrar en la plataforma y extraer un token OAuth de GitHub CLI asociado a una cuenta propietaria de la organización. Microsoft analizó después el artefacto malicioso; la cadena inicial sigue siendo la reconstrucción atribuida a LiteLLM, no una conclusión independiente de Microsoft.
-SecureCrew dice: borrar un secreto del commit no lo revoca; Git conserva la historia y el atacante no necesita pedir permiso para leerla.-
De una clave a la cuenta propietaria
El archivo expuesto estaba en LiteLLM-Labs/lite-harness, un repositorio público. LiteLLM afirma que el commit se retiró rápidamente y que el equipo identificó otras claves como necesitadas de revocación, pero la clave maestra concreta siguió activa. Esa diferencia convierte una filtración breve en una credencial persistente: quitar el texto del árbol actual no invalida el valor que ya pudo copiarse.
El 10 de octubre, el atacante usó la clave contra LiteLLM Agent Platform, un servicio experimental que podía abrir solicitudes de cambio en repositorios. La API devolvió la configuración de agentes gestionados, incluido un token GitHub CLI asociado a una persona con privilegios de propietario. LiteLLM dice que ese token daba acceso de propietario a sus repositorios; aunque los tokens de GitHub CLI se emiten tras autenticación de dos factores, el proveedor señala que determinadas acciones sensibles no vuelven a pedir esa reautenticación.
-SecureCrew dice: el segundo factor protegió el inicio de sesión; no convirtió en inocuo un token de propietario que ya estaba emitido.-
Con ese acceso, el atacante lanzó flujos de trabajo desde ramas temporales para extraer secretos disponibles en CI/CD (integración continua y entrega). Según la cronología de LiteLLM, así obtuvo credenciales de otros dos mantenedores: una se usó para aprobar el paso de producción y otra para borrar registros de los flujos. La reconstrucción del proveedor también indica que el actor modificó el proceso de publicación para tomar código de un repositorio señuelo llamado Berri-AI/litellm, parecido al nombre legítimo.
El impacto en las publicaciones
El 21 de octubre, siete wheels de litellm==1.107.0 llegaron a PyPI y se publicaron imágenes Docker y GHCR construidas desde la fuente controlada por el atacante. La versión de código fuente oficial no contenía esos archivos maliciosos: el problema estaba en los artefactos publicados. La investigación de Microsoft describe mecanismos que podían robar credenciales y cargar herramientas de ejecución remota; también explica por qué iniciar Python en un entorno afectado podía activar el código sin importar LiteLLM en una aplicación.
LiteLLM delimitó ventanas concretas: los paquetes de PyPI estuvieron disponibles aproximadamente desde las 11:39 hasta las 13:23 UTC del 21 de octubre; las etiquetas Docker v1.107.0, latest, main-latest y main-stable apuntaron a imágenes comprometidas hasta las 14:20 UTC. El proveedor retiró los artefactos y afirma que su registro privado de Enterprise no estuvo afectado. Esas ventanas importan para cruzar inventario y registros de despliegue; una etiqueta que hoy resuelve a una imagen limpia no demuestra qué digest descargó un host ayer.
-SecureCrew dice: un tag saneado describe el presente del registro; no reescribe lo que ya arrancó en producción.-
Si un equipo instaló el wheel afectado o arrancó un contenedor durante la ventana indicada, LiteLLM pide tratar ese entorno como comprometido. La respuesta debe partir de una imagen o entorno limpio, no de volver a iniciar Python dentro del mismo virtualenv, y debe incluir la rotación de secretos que el proceso podía leer. La propia empresa advierte que no encontrar un archivo marcador no demuestra que el sistema esté limpio. Para quienes no usaron esos artefactos, el caso sigue siendo una lección concreta sobre revocación de secretos y alcance mínimo de tokens, no una prueba de que todas las instalaciones de LiteLLM estén comprometidas.
La cadena descrita muestra cómo se conectaron secreto expuesto, token privilegiado y publicación de software. La protección de ramas rechazó inicialmente un cambio, pero un token con privilegios de propietario pudo desactivar esa barrera; después, otra credencial aprobó el despliegue. La firma de un artefacto y la aprobación de un pipeline solo dan garantías si la identidad que las autoriza sigue bajo control.
Diccionario de la Crew
Clave maestra — Secreto de alto privilegio que permite controlar una instancia o servicio; su exposición exige revocarlo, aunque el archivo que lo contenía desaparezca.
Token OAuth de GitHub CLI — Credencial que permite a una herramienta autenticarse en GitHub con los permisos de una cuenta.
CI/CD — Integración y entrega continuas: automatización que prueba, construye y publica software.
