LiteLLM 1.107.0 distribuyó un ladrón de credenciales (octubre de 2026): versión afectada en PyPI e imágenes de Docker, y qué deben hacer los usuarios

La empresa enumera los siguientes artefactos afectados. Todas las horas son del 21 de octubre de 2026.

La empresa dice que está afectado si instaló LiteLLM con pip sin fijar una versión durante la ventana, o si inició un contenedor desde una de estas etiquetas durante la ventana. Si su CI ejecuta pip install litellm en cada compilación, o su Dockerfile se construye FROM la etiqueta latest, la versión afectada pudo instalarse sin que nadie hiciera nada.

• Si un entorno puede estar afectado, no inicie Python ni pip para comprobar su versión. Aíslelo primero y luego revise los registros de despliegue o los digests de las imágenes desde otra máquina limpia. Si no puede descartar la exposición, trátelo como afectado y pase a la reconstrucción y la rotación de credenciales que se indican más abajo (nota de este sitio). El comando de comprobación de versión de la empresa también inicia Python, así que no lo ejecute antes de limpiar
• La empresa ha publicado los nombres de archivo que hay que buscar y los digests de las imágenes. Encontrarlos confirma la exposición, pero no encontrarlos no demuestra que el entorno esté limpio
• Si había fijado explícitamente 1.106.2 o anterior, o 1.107.0rc1 o rc2, no está afectado (la empresa dice que las versiones anteriores quedan fuera de esta vulneración)
• Los clientes que descargan desde el registro privado empresarial no se vieron afectados (la empresa)

Según el análisis del investigador citado en el aviso de la empresa, el malware se instala como archivos que Python carga automáticamente cada vez que se inicia. Se ejecuta de nuevo en cualquier proceso de Python, incluidos los que nunca importan litellm y el propio pip.

El orden de limpieza que da la empresa es el siguiente (los nombres de archivo y las ubicaciones están en su página del aviso):

• Sin iniciar Python, elimine desde la shell los archivos maliciosos que nombra la empresa (y sus archivos de caché) de todos los directorios site-packages afectados
• Detenga el proceso de Python que quedó ejecutándose en segundo plano
• Solo entonces reinstale fijando litellm==1.106.2. La empresa dice que es mejor reconstruir desde cero las imágenes y los entornos virtuales

Si lo ejecutó en contenedores, lo más rápido suele ser detener los contenedores creados a partir de la imagen afectada y volver a crearlos desde una imagen fijada a una versión limpia (nota de este sitio).

En su primera publicación, la empresa pidió fijar 1.106.2 o cualquier versión explícita publicada antes de este incidente. El 24 de octubre (UTC) publicó después 1.103.8, 1.104.6, 1.105.4 y 1.106.3. La última versión en PyPI es 1.106.3, y 1.107.0 sigue retirada. Según las notas de la versión, estas versiones eliminan la autoridad de certificación raíz de eMudhra de todos los paquetes de certificados en los que confían el SDK, el proxy y las imágenes de Docker. El tema de eMudhra se trata en qué deben hacer los usuarios de Python con las claves de la CA intermedia de eMudhra.

En Docker, haga referencia a las imágenes por una etiqueta de versión, o mejor por digest (un valor calculado a partir del contenido de la imagen), en lugar de etiquetas como latest o main-stable, cuyo contenido cambia. Así, un cambio en lo que apunta una etiqueta no le llega.

Según las notas de la versión, desde las versiones del 24 de octubre las imágenes de Docker y los charts de Helm se firman con una nueva clave de cosign (cosign es una herramienta para firmar y verificar imágenes de contenedores), y la verificación con la clave anterior falla. Si fija el antiguo cosign.pub en scripts de cosign verify, comprobaciones de CI o políticas de Kubernetes que verifican firmas (como Kyverno), sustitúyalo por la nueva clave del commit indicado en las notas de la versión. Las notas también indican el SHA-256 de la nueva clave, así que compare con él la clave que descargue antes de cambiar (nota de este sitio).

La empresa dice que, si 1.107.0 llegó a instalarse en un host con acceso saliente a internet, debe asumir que los datos robados se enviaron con éxito. Nombra en particular estos:

• El rol en la nube asociado al servidor o contenedor (como un rol IAM de instancia o tarea de AWS)
• Todas las claves de proveedores de LLM guardadas en la base de datos del proxy de LiteLLM
• La clave maestra del proxy y todas las claves virtuales que emitió
• La contraseña de la cadena de conexión a la base de datos (DATABASE_URL)
• Todos los secretos que estaban en el entorno de cualquier proceso que se ejecutaba en el host

Según el análisis del investigador, el malware también estaba diseñado para recopilar claves SSH, credenciales de Git y de publicación de paquetes, tokens de Kubernetes, contraseñas guardadas en navegadores y la configuración de asistentes de programación con IA. Si ejecutó 1.107.0 en el portátil de un desarrollador, también deben rotarse las credenciales de ese portátil.

Emita una clave nueva en el panel de cada servicio y revoque la anterior (nota de este sitio: configure primero la clave nueva y después revoque la anterior, para evitar una interrupción). El manejo de las claves de API se trata en qué hace riesgosos los archivos .env y las claves de API.

La empresa pide revisar el registro de auditoría de AWS (CloudTrail) en busca de una llamada de comprobación de identidad (GetCallerIdentity) hecha con el rol de la instancia en torno al momento de la instalación, y después cualquier uso de las credenciales de ese rol desde fuera de su propia infraestructura.

Como nota de este sitio, revise también los paneles de sus proveedores de LLM por si hubo un aumento inesperado del uso o de los cargos desde las 11:39 UTC del 21 de octubre (la tarde en Japón). Cuando se usa una clave de LLM robada, puede verse en el uso y la facturación. Lo que ocurre con las claves robadas se trata en cómo las claves de API robadas llevan a bloqueos de cuentas.

Los entornos afectados fueron los que instalaron con pip sin versión fija, o usaron etiquetas como latest, main-latest y main-stable, cuyo contenido cambia. Los entornos que fijaron 1.106.2 y referenciaron las imágenes de Docker por digest no se vieron afectados, aunque se reconstruyeran durante la ventana.

Como primer paso, fije las dependencias usadas en producción y CI con un archivo de bloqueo que incluya hashes (pip install --require-hashes, o archivos de bloqueo de uv o Poetry). Un ajuste que evita las versiones publicadas muy recientemente (como exclude-newer de uv, que ignora todo lo publicado después de un momento dado) también ayuda frente a versiones que se retiran en cuestión de horas. El enfoque se trata en auditar dependencias con OSV-Scanner.

La base de datos del proxy guarda las claves de todos los proveedores que conecta. Cuando hay que rotarlas, como ahora, no saber qué clave pertenece a qué entorno obliga a elegir entre olvidar alguna o apagarlo todo.

Usar claves de proveedor distintas para desarrollo, pruebas y producción, y fijar límites de gasto y alertas en el lado del proveedor, reduce el alcance de la rotación y ayuda a detectar antes un uso indebido. Qué hacer cuando se filtra una clave se trata en una clave de API filtrada desde código escrito por IA.

Según el análisis de causa raíz, el punto de partida fue una clave maestra subida por error a un repositorio público en mayo. La confirmación se sobrescribió rápidamente y se identificaron las claves expuestas que había que revocar, pero la clave maestra no se revocó y se usó unos cuatro meses y medio después. La empresa dice que el incidente ilustra con claridad el riesgo de no rotar una clave potencialmente expuesta.

Si sube un secreto a un repositorio público, revoque y sustituya la clave antes de preocuparse por el historial. Tras rotar, revise la lista de claves que reemplazó para asegurarse de que no falte ninguna (nota de este sitio). El problema se trata en credenciales filtradas que siguen siendo válidas.

Según el análisis, el primer token robado estaba configurado en la plataforma de agentes para que pudiera abrir pull requests. No estaba vinculado a una cuenta de servicio ni tenía alcance reducido: era el token personal de GitHub CLI de un propietario de la organización. La empresa señala que los tokens de GitHub CLI se emiten tras la autenticación en dos pasos y no están sujetos a la reautenticación que GitHub pide antes de acciones sensibles.

Dé a los agentes y bots un token dedicado con alcance limitado solo a su tarea (una GitHub App o un token de acceso detallado), y mantenga los derechos de propietario separados de las cuentas usadas en el trabajo diario (nota de este sitio). Hacer que los secretos de CI estén disponibles solo para los flujos de trabajo y entornos que los necesitan también limita hasta dónde puede llegar un token robado (nota de este sitio). La protección de una cuenta de GitHub se trata en configurar la autenticación en dos pasos de GitHub.

Esto resultó no ser la causa, pero la primera publicación de la empresa señalaba que, en situaciones concretas, un asistente de programación con IA puede incrustar el token de GitHub CLI de un usuario en el cuerpo de una respuesta, y donde se registran los cuerpos de las respuestas, esos tokens pueden aparecer en los registros de LiteLLM.

Para una pasarela que ejecuta usted mismo, compruebe tres cosas: que la interfaz de administración y la API no sean accesibles directamente desde internet, que se revisen los ajustes de registro que conservan los cuerpos de las respuestas y, si los conserva, que el periodo de retención sea corto. La protección de una cuenta de GitHub se trata en configurar la autenticación en dos pasos de GitHub.