LiteLLM hackeado: qué hacer si usas su gateway de IA en tu negocio
La versión 1.107.0 de LiteLLM estuvo infectada con malware que robaba llaves de OpenAI y Anthropic. Esto es lo que se sabe y cómo proteger tu negocio.
El gateway que usan miles de negocios para conectar con OpenAI y Anthropic quedó comprometido
Su actualización del 21 de octubre venía con malware que robaba llaves de OpenAI y Anthropic. Esto es lo que cambia para quien usa IA en su empresa.
El 21 de octubre de 2026, LiteLLM —el gateway de inteligencia artificial que conecta a miles de negocios con OpenAI y Anthropic— confirmó que su propia línea de publicación había sido saboteada. La versión 1.107.0, subida a PyPI y a Docker esa madrugada, venía con malware capaz de robar llaves de API, credenciales de nube y contraseñas guardadas en el navegador, además de dejar una puerta trasera para volver a entrar después.
En resumen
LiteLLM confirmó que su versión 1.107.0, publicada el 21 de octubre de 2026, estuvo infectada con malware que robaba llaves de OpenAI y Anthropic durante casi dos horas en PyPI y casi tres en Docker. El incidente está contenido, pero la investigación sigue abierta. La salida inmediata: fijar la versión 1.106.2, nunca usar la etiqueta "latest", y rotar toda llave que haya podido quedar expuesta.
- La 1.107.0 estuvo infectada en PyPI de 11:39 a 13:23 UTC del 21 de octubre.
- En Docker, las etiquetas latest, main-latest y main-stable también se infectaron.
- La versión 1.106.2 nunca estuvo comprometida.
- Los clientes del registro privado empresarial de LiteLLM no fueron afectados.
Qué pasó el 21 de octubre
La propia LiteLLM reportó que, en la madrugada del 21 de octubre de 2026, su línea de publicación (release pipeline) fue comprometida y usada para subir la versión 1.107.0 tanto a PyPI como a Docker Hub y GHCR. Esa versión contenía malware compilado que robaba credenciales y cargaba herramientas de ejecución remota de código. LiteLLM aclara que todas las versiones anteriores están limpias y que los artefactos afectados ya fueron retirados.
El paquete litellm==1.107.0 estuvo disponible en PyPI de las 11:39 a las 13:23 UTC, casi dos horas. En Docker Hub, las etiquetas v1.107.0, latest, main-latest y main-stable apuntaron a una imagen contaminada de las 11:46 a las 14:20 UTC. En GHCR, las mismas etiquetas quedaron comprometidas desde las 11:46 UTC hasta que se retiraron, antes de las 13:51 UTC. Según la actualización pública de LiteLLM a las 20:30 UTC del mismo día, el incidente está contenido, pero la investigación sigue en curso: todavía no hay un cierre final del caso.
| Artefacto | Ventana comprometida (21 oct, UTC) | Estado actual |
|---|---|---|
| PyPI · litellm==1.107.0 | 11:39 – 13:23 | Retirado de PyPI |
| Docker Hub · v1.107.0, latest, main-latest, main-stable | 11:46 – 14:20 | Retirado o repuntado a fuente limpia |
| GHCR · ghcr.io/berriai/litellm y variantes | 11:46 – antes de 13:51 | Ya no disponible |
| litellm==1.106.2 y versiones previas | No afectadas | Seguras para usar |
Cómo entraron los atacantes
Según Datadog Security Labs, los atacantes operaron con tokens de GitHub CLI robados de tres cuentas de ingenieros de LiteLLM. LiteLLM explica en su reporte que esos tokens salieron de un despliegue interno de LiteLLM que, por error, quedó expuesto a internet público; sus registros guardaron tokens de OAuth de GitHub CLI, y de ahí los tomó el atacante.
Con uno de esos tokens —que pertenecía a uno de los dos propietarios de la organización en GitHub— el atacante desactivó las protecciones de rama y forzó un cambio en el flujo de publicación para que apuntara a un repositorio señuelo: Berri-AI/litellm, muy parecido al oficial BerriAI/litellm. Desde ahí corrieron el flujo de trabajo modificado, que firmó y publicó los paquetes envenenados como si fueran legítimos.
Qué robaba el malware y qué dejaba atrás
No era solo un robo de contraseñas
El malware de la versión 1.107.0 copiaba llaves de API de OpenAI y Anthropic, credenciales de nube (incluido el rol de identidad de la instancia), la contraseña de la base de datos del proxy de LiteLLM y contraseñas guardadas en el navegador. Además instalaba un proceso en segundo plano, con un archivo de bloqueo en /tmp/remote_code_loader.lock, que funcionaba como puerta trasera para volver a entrar más adelante. LiteLLM reporta que su gateway se usa alrededor de 23 millones de veces por semana, casi siempre conectado directo a los proveedores de IA, así que una llave guardada ahí durante la ventana comprometida ya no debe considerarse segura.
Qué hacer si usaste LiteLLM estos días
No reinstales con pip install a secas
En un entorno afectado, cualquier arranque de Python —incluido el propio pip— vuelve a ejecutar los archivos maliciosos cook.pth y sitecustomize.py.
Borra los archivos maliciosos a mano
Elimina cook.pth, cook.py, sitecustomize.py y los .pyc correspondientes de cada site-packages afectado.
Mata el proceso en segundo plano
Busca y termina el daemon de Python que mantiene el archivo de bloqueo /tmp/remote_code_loader.lock.
Reinstala fijando la versión exacta
Usa litellm==1.106.2, nunca una etiqueta flotante. Lo más seguro es reconstruir contenedores y entornos virtuales desde cero.
Rota todas las credenciales alcanzables
Cambia el rol de identidad de la instancia, las llaves de proveedores guardadas en la base de datos del proxy, las llaves maestra y virtuales de LiteLLM, y la contraseña de DATABASE_URL.
Revisa tus registros de acceso
Busca llamadas GetCallerIdentity desde el rol de la instancia alrededor de la hora de instalación, y uso de esas credenciales desde fuera de tu infraestructura.
La regla que evita que esto vuelva a pasar
Nunca uses la etiqueta "latest" ni ninguna etiqueta flotante (main-latest, main-stable) en producción. Fue justo lo que quedó contaminado en este ataque. Fija siempre la versión exacta del software que corre tu negocio —en este caso, litellm==1.106.2— y actualiza de forma consciente, no automática.
Qué significa para negocios en México y Latinoamérica
LiteLLM se usa como puente entre un negocio y los modelos de IA de OpenAI o Anthropic: agencias que atienden a varios clientes desde un solo panel, SaaS que ofrecen chat con IA, equipos de soporte que automatizan respuestas, y tiendas en línea que generan descripciones o atienden pedidos por WhatsApp Business API. Si cualquiera de ellos corrió la actualización infectada sin fijar versión, las llaves de OpenAI o Anthropic que tenían guardadas ahí —y con ellas el saldo y los límites de esa cuenta— ya no son confiables.
Así se ve el riesgo en una agencia mexicana típica
Una agencia que atiende a varios clientes desde un mismo servidor LiteLLM concentra en un solo lugar las llaves de todos ellos. Si ese servidor corrió la versión 1.107.0 en la ventana comprometida, el riesgo no es solo propio: son las cuentas de IA de cada cliente conectado.
- Revisa en cada entorno qué versión de LiteLLM está corriendo con pip show litellm.
- Si encuentras la 1.107.0 o un contenedor con la imagen comprometida, trátalo como expuesto.
- Fija siempre versiones exactas en tus dependencias de IA, no etiquetas flotantes.
- Rota llaves de OpenAI y Anthropic de forma periódica, no solo cuando hay un incidente.
- Si no tienes equipo de seguridad propio, pide una revisión externa antes de seguir operando con esas llaves.
¿Qué es LiteLLM y por qué me afecta si uso OpenAI o Anthropic?
LiteLLM es un gateway que conecta aplicaciones de negocio con modelos de IA como los de OpenAI y Anthropic, y LiteLLM reporta que se ejecuta alrededor de 23 millones de veces por semana. Si tu negocio lo usa para conectar su chatbot, su CRM o su WhatsApp Business API con un modelo de IA, este hackeo te afecta directamente.
¿Mi negocio está afectado por este hackeo?
Lo estás si instalaste litellm==1.107.0 por PyPI entre las 11:39 y las 13:23 UTC del 21 de octubre, o si corriste las imágenes de Docker v1.107.0, latest, main-latest o main-stable entre las 11:46 y las 14:20 UTC de ese mismo día, según el reporte de LiteLLM. Los clientes del registro privado empresarial de LiteLLM no fueron afectados.
¿Cómo sé si mi instalación de LiteLLM quedó comprometida?
Revisa con pip show litellm si tu entorno corrió la versión 1.107.0, y busca en el sistema de archivos los nombres litellm-1.107.0.dist-info, cook.pth y sitecustomize.py. LiteLLM advierte que encontrar uno de esos archivos confirma la exposición, pero no encontrarlo no prueba que el entorno esté limpio.
¿Qué debo hacer si ya instalé la versión infectada?
No reinstales con pip install directo: eso vuelve a ejecutar el malware. Borra a mano los archivos cook.pth y sitecustomize.py, mata el proceso en segundo plano, reinstala fijando litellm==1.106.2, y rota de inmediato las llaves de OpenAI, Anthropic y cualquier credencial de nube que ese entorno pudiera alcanzar.
¿Ya se resolvió el problema o sigue activo?
Según la última actualización pública de LiteLLM, del 21 de octubre a las 20:30 UTC, el incidente está contenido —los paquetes infectados ya se retiraron de PyPI, Docker Hub y GHCR— pero la investigación sobre cómo ocurrió exactamente sigue en curso.
¿Por qué no debo usar la etiqueta "latest"?
Porque fue justo lo que quedó comprometido en este ataque: las etiquetas flotantes latest, main-latest y main-stable apuntaron a la imagen infectada durante horas. Fijar una versión exacta, como litellm==1.106.2, evita que una actualización maliciosa entre sola a tu sistema.
Fuentes
¿Tu negocio depende de llaves de IA que no has revisado?
En Zadrig Technology auditamos cómo están configuradas tus herramientas de inteligencia artificial —versiones, llaves y accesos— antes de que un incidente como este te cueste caro. Agenda una demostración con nuestro equipo.
Escríbenos por WhatsApp
