> ## Content Index > Fetch the complete content index at: https://www.digitalbrain.news/llms.txt > Use this file to discover other available public pages before exploring further. # LiteLLM 1.107.0 robó credenciales: cómo saber si te afecta - URL: https://www.digitalbrain.news/noticias/litellm-1-107-0-malware-credenciales-pypi/ - Published: 2026-10-22T14:44:08.000Z - Updated: 2026-10-22T14:49:11.000Z - Description: La versión 1.107.0 de LiteLLM, la librería de código abierto que usan miles de equipos para conectar sus aplicaciones con OpenAI, Anthropic, Google… - Author: Ramón Pérez Coronado - Tags: #noticias, ciberseguridad, claude-code La versión 1.107.0 de LiteLLM, la librería de [código abierto](https://www.digitalbrain.news/glosario/#open-source) que usan miles de equipos para conectar sus aplicaciones con [OpenAI](https://www.digitalbrain.news/glosario/#openai), [Anthropic](https://www.digitalbrain.news/guias/que-es-anthropic/), Google y cien proveedores más, salió con malware dentro. Robaba credenciales y dejaba una puerta trasera. Estuvo publicada en PyPI unas dos horas el 21 de octubre y en Docker algo más, según el [informe de incidente de la propia LiteLLM](https://docs.litellm.ai/blog/security-incident-oct-21-2026?ref=digitalbrain.news). Si tu equipo usa LiteLLM sin fijar versión, o arrancó la imagen \`latest\` de Docker esa mañana, tienes que revisar hoy. ## Puntos clave - **PyPI:** \`litellm==1.107.0\` estuvo disponible de 11:39 a 13:23 UTC del 21 de octubre (de 13:39 a 15:23 en horario peninsular). Las siete variantes del paquete estaban infectadas. - **Docker:** las etiquetas \`v1.107.0\`, \`latest\`, \`main-latest\` y \`main-stable\` apuntaron a imágenes comprometidas de 11:46 a 14:20 UTC en Docker Hub, y hasta las 13:51 en GHCR. - **Qué robaba:** claves SSH, credenciales de AWS, Azure y Google Cloud, secretos de CI/CD, contraseñas guardadas en el navegador, [tokens](https://www.digitalbrain.news/guias/que-es-un-token-en-ia/) de herramientas de IA ([Claude Code](https://www.digitalbrain.news/guias/que-es-claude-code/), [Cursor](https://www.digitalbrain.news/guias/que-es-cursor-ai/), [Codex](https://www.digitalbrain.news/glosario/#codex), [Gemini](https://www.digitalbrain.news/guias/que-es-gemini/) CLI y otras) y las claves de proveedores guardadas en la base de datos del proxy de LiteLLM. - **Versiones limpias:** la 1.106.2 y anteriores. Los clientes enterprise que usan el registro privado no se vieron afectados. ## Cómo entró el malware Lo interesante del caso es que el atacante no tocó el código público. La etiqueta oficial 1.107.0 en GitHub está limpia. Lo que se envenenó fue la cadena de publicación. Según LiteLLM, el atacante tenía las credenciales de la línea de comandos de GitHub de tres desarrolladores. Una era de uno de los dos propietarios de la organización. Con ella desactivó la protección de ramas, cambió el flujo de publicación privado para que construyera desde un repositorio clon con un nombre casi idéntico (\`Berri-AI/litellm\` en vez de \`BerriAI/litellm\`) y usó la credencial de un segundo desarrollador para pasar la aprobación de producción. El propio pipeline oficial construyó, firmó y publicó los paquetes. Después, con la tercera credencial, borró los registros de esas ejecuciones. La cronología del informe va al minuto: a las 10:08 UTC la protección de ramas rechazó el cambio y cinco segundos después una credencial privilegiada la saltó. A las 11:39 los paquetes ya estaban en PyPI. ¿De dónde salieron esos tokens? LiteLLM cree que de los logs de un despliegue interno suyo de LiteLLM expuesto a internet. En su investigación vieron que, en ciertos casos, Claude Code incrusta el token OAuth de GitHub CLI del usuario en el cuerpo de una respuesta, y si esas respuestas se registran, el token acaba en los logs. Todavía no han confirmado cómo entró el atacante a ese despliegue y sospechan de una vulnerabilidad parcheada hace poco. Es la segunda vez este año. Tras otro incidente en marzo, LiteLLM había endurecido su proceso: repositorio privado para publicar, editores de confianza de GitHub, etiquetas de Docker inmutables e imágenes firmadas. El lunes amplió temporalmente los permisos de publicación a dos ingenieros para sacar parches diarios a clientes, y por ahí se coló el ataque. ## Qué hace el código malicioso El análisis de [SafeDep](https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/?ref=digitalbrain.news) explica la mecánica. El paquete instala tres archivos en \`site-packages\`: \`cook.pth\`, \`cook.py\` y \`sitecustomize.py\`. Python ejecuta los dos primeros cada vez que arranca, así que el robo se ejecuta en cualquier proceso de Python de la máquina, aunque nunca importe LiteLLM. Incluido el propio \`pip\`. \`cook.py\` recoge todo lo que encuentra, lo cifra con AES-256 y RSA de 4.096 bits y lo envía a \`www.litellm\[.\]dev\`, un dominio que imita al legítimo. \`sitecustomize.py\` arranca un proceso en segundo plano que cada hora vuelve a robar y descarga código nuevo desde un servidor que el atacante podía cambiar editando un archivo en GitHub. Esa cuenta de GitHub desapareció a las 13:40 UTC, así que la puerta trasera ya no encuentra servidor. Las máquinas que la ejecutaron antes pudieron recibir una segunda fase, y SafeDep no ha podido recuperar qué contenía. ## ¿Me afecta el hackeo de LiteLLM? Te afecta si instalaste LiteLLM con pip sin fijar versión entre las 11:39 y las 13:23 UTC del 21 de octubre, o si arrancaste las imágenes de Docker \`v1.107.0\`, \`latest\`, \`main-latest\` o \`main-stable\` entre las 11:46 y las 14:20 UTC. Si usabas una versión fijada anterior, estás bien. Ojo con lo que no se ve: muchas herramientas de agentes y frameworks de IA llevan LiteLLM como dependencia. Que tú no lo hayas instalado a mano no significa que no esté en tu entorno. ## Cómo comprobar si tu entorno está comprometido Estos son los pasos que publica LiteLLM: 1\. Ejecuta \`pip show litellm\` en cada entorno. Si sale la 1.107.0, trátalo como comprometido. 2\. Si usas contenedores, comprueba si alguno ejecutó la imagen con digest \`sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e\`. 3\. Busca en el sistema de archivos \`litellm-1.107.0.dist-info\`, \`cook.pth\` y \`sitecustomize.py\`. Encontrar uno confirma la exposición; no encontrarlo no prueba que estés limpio. 4\. No arranques con \`pip install\`: cualquier arranque de Python vuelve a ejecutar el malware. Borra desde la shell \`cook.pth\`, \`cook.py\`, \`sitecustomize.py\` y sus \`.pyc\` en \`\_\_pycache\_\_\`. 5\. Mata el proceso en segundo plano (es el que tiene \`/tmp/remote\_code\_loader.lock\`). 6\. Reinstala fijando \`litellm==1.106.2\`. Mejor aún, reconstruye imágenes y entornos virtuales desde cero. 7\. Rota todo lo que esa máquina podía alcanzar: el rol IAM de la instancia, cada clave de proveedor guardada en la base de datos del proxy, las claves maestra y virtuales, la contraseña de \`DATABASE\_URL\` y cualquier secreto en variables de entorno. LiteLLM es clara en un punto: si la 1.107.0 se instaló en una máquina con salida a internet, da por hecho que el robo se completó. ## Por qué importa LiteLLM es la pieza que muchas empresas ponen en medio para no casarse con un proveedor de IA: una sola API para llamar a [GPT](https://www.digitalbrain.news/glosario/#gpt), [Claude](https://www.digitalbrain.news/guias/que-es-claude-ia/) o Gemini, con control de gasto y claves centralizadas. Eso la convierte en el sitio donde viven todas tus claves de API a la vez. Si alguien entra ahí, no se lleva una llave, se lleva el llavero. Si tienes un equipo técnico que monta cosas con IA, hay dos deberes para esta semana. El primero, revisar hoy con los pasos de arriba. El segundo, fijar versiones en todo lo que se instala en producción: un \`pip install litellm\` sin número de versión fue la puerta de entrada para cualquiera que desplegara esa mañana. Y una tercera más incómoda: mirar qué guardan vuestros logs, porque el token que abrió todo esto salió de ahí. Fuente original: [docs.litellm.ai](https://docs.litellm.ai/blog/security-incident-oct-21-2026?ref=digitalbrain.news) --- **Relacionado** [![Hackeo del robot Eiliko: 13 millones de conversaciones expuestas](https://storage.ghost.io/c/6d/e3/6de31f63-d0a8-45df-9c6a-481016520347/content/images/size/w300/format/webp/2026/10/eiliko-robot-ia-hackeo-conversaciones.jpg)Hackeo del robot Eiliko: 13 millones de conversaciones expuestas](https://www.digitalbrain.news/noticias/eiliko-robot-ia-hackeo-conversaciones/)[![Microsoft trata a Claude Code y Codex como amenaza interna](https://storage.ghost.io/c/6d/e3/6de31f63-d0a8-45df-9c6a-481016520347/content/images/size/w300/format/webp/2026/10/microsoft-agentes-ia-amenaza-interna-guardian-agents.png)Microsoft trata a Claude Code y Codex como amenaza interna](https://www.digitalbrain.news/noticias/microsoft-agentes-ia-amenaza-interna-guardian-agents/)