Si su empresa tiene una aplicación de IA, un chatbot o una herramienta interna que se conecta a modelos como GPT, Claude o Gemini, hágale hoy una sola pregunta a su equipo técnico: ¿algún servidor, portátil o pipeline de compilación instaló LiteLLM en la versión 1.107.0 el 21 de octubre de 2026? Esa versión la publicaron atacantes y estuvo en PyPI unas dos horas, entre las 14:39 y las 16:23 hora de Riad, con cerca de 49.000 descargas. Roba claves de la nube, claves de proveedores de IA, contraseñas de bases de datos y claves SSH. Si la respuesta es sí, desinstalarla no basta: reconstruya la máquina desde una imagen limpia y rote todas las claves a las que podía acceder. La versión segura es la 1.106.2.

¿Qué pasó exactamente?

LiteLLM es una biblioteca y pasarela de código abierto que permite a una sola aplicación hablar con decenas de modelos de IA a través de una única interfaz, y por eso muchas empresas la colocan en el centro de sus productos de IA. Según Chainguard, superó los 100 millones de descargas en PyPI en el último mes, y más de 2.000 paquetes dependen de ella, de modo que muchos equipos la instalan sin saberlo.

Según el informe oficial del incidente de LiteLLM, los atacantes obtuvieron tokens de acceso de GitHub que se habían filtrado en los registros del proyecto. A las 10:08 UTC del 21 de octubre usaron una credencial privilegiada de desarrollador para saltarse la protección de rama y cambiar el flujo de publicación para que compilara desde un repositorio de nombre parecido, «Berri-AI/litellm» en lugar de «BerriAI/litellm». A las 11:39 UTC los archivos maliciosos llegaron a PyPI, y a las 11:46 UTC salieron imágenes Docker envenenadas con las etiquetas v1.107.0, latest, main-latest y main-stable. PyPI retiró la versión antes de las 13:23 UTC, y las etiquetas Docker se limpiaron a las 14:20 UTC, es decir, las 17:20 en Riad.

Es el segundo ataque contra el mismo proyecto este año. Chainguard señala que en marzo de 2026 un grupo usó un token de PyPI robado para publicar las versiones 1.82.7 y 1.82.8.

¿Qué roba la versión maliciosa?

Lo peligroso es que no espera a que su aplicación use LiteLLM. La versión añadió archivos de arranque de Python que se ejecutan cada vez que Python se inicia en esa máquina, incluso para un comando sin relación. Según el análisis de Wiz, el ladrón recopilaba:

  • Claves de nube de AWS, Google Cloud y Azure, desde archivos de configuración, variables de entorno y metadatos del servidor.
  • Claves API de OpenAI, Anthropic, Cohere y otros proveedores de IA, es decir, su factura y sus datos.
  • Claves SSH privadas, historial de la terminal y contraseñas y cookies guardadas en los navegadores.
  • Hasta 500 credenciales de proveedores almacenadas en la base de datos de LiteLLM Proxy.

Los atacantes no se quedaron quietos con lo robado. Wiz vio credenciales de AWS robadas probándose unas 4,5 horas después de su robo, desde servidores de compilación y nodos de Kubernetes. El malware también instaló una segunda etapa que descarga código remoto cada hora, así que la máquina sigue abierta incluso después de eliminar el paquete.

¿Está afectada mi empresa?

Probablemente no lo esté si su equipo fija versiones exactas y no actualizó nada entre las 14:39 y las 17:20 hora de Riad del 21 de octubre. Puede estarlo si se cumple alguno de estos casos:

  • Un servidor o contenedor ejecuta «pip install litellm» sin versión fija, o descarga la etiqueta Docker «latest».
  • Un pipeline de CI/CD se recompiló esa tarde.
  • Un desarrollador probó LiteLLM en su portátil ese día.
  • Su sistema usa otro paquete que depende de LiteLLM.

LiteLLM afirma que los clientes de su versión Enterprise privada no se vieron afectados.

Cinco pasos para hoy

  • Buscar: la versión 1.107.0 en archivos de bloqueo, registros de compilación e imágenes de contenedores, y los archivos cook.pth y sitecustomize.py en la carpeta de paquetes de Python.
  • Reconstruir: si la encuentra, no se conforme con desinstalar. El informe oficial advierte que ejecutar pip dentro de un entorno infectado puede volver a activar el malware. Reconstruya la máquina o el contenedor desde una imagen limpia.
  • Rotar todas las claves: claves y roles de la nube, claves de proveedores de IA, contraseñas de bases de datos y claves SSH a las que podía llegar la máquina. Asuma que ya están en manos de los atacantes.
  • Revisar los registros: compruebe la actividad en la nube desde el 21 de octubre en busca de llamadas inusuales como GetCallerIdentity, y vigile la factura de su proveedor de IA por si hay gastos que no reconoce.
  • Fijar versiones: instale litellm==1.106.2 o una corrección oficial posterior, y fije cada biblioteca con un archivo de bloqueo en lugar de descargar «latest» automáticamente.

Si leyó nuestro artículo anterior sobre claves olvidadas en el código de agentes de IA, la lección es la misma desde otro ángulo: las claves de IA son ya de los secretos más valiosos de su empresa, y el lugar donde se concentran se convierte en un objetivo.

La opinión de Origami

Aquí nadie hackeó el código de LiteLLM en sí. Los atacantes cambiaron la forma en que se compila y se publica, así que revisar solo el código fuente no lo habría detectado. Por eso proteger productos de IA no depende tanto de elegir la biblioteca como de cómo se opera: versiones fijas, una clave distinta para cada entorno con solo los permisos que necesita, límites de gasto en cada proveedor de IA y un registro claro de quién accede a qué. Cuando en Origami construimos sistemas de IA para empresas, tratamos la pasarela de modelos como la parte más sensible del sistema, porque guarda las claves de todo. Si quiere que revisemos su aplicación de IA frente a este incidente, o reorganizar sus claves y permisos, contáctenos.

Fuentes