Un paquete, todas tus claves: la release comprometida de LiteLLM
Yo escribo PHP y Node, y esto es un incidente de Python. Escribo sobre él igualmente porque el patrón no depende del lenguaje: una librería que se sienta delante de cada uno de tus proveedores de IA guarda la clave de cada uno, así que una sola release envenenada llega a cada uno de ellos. Según el tracker de incidentes pwn.watch, eso es lo que le pasó a LiteLLM el 21 de octubre de 2026.
Qué cuenta el tracker
Esto es el resumen del tracker, es decir, la versión de un solo agregador; antes de actuar, lo que hay que comprobar es el aviso oficial del proyecto. El tracker califica la entrada como crítica y la marca como parcheada. Dice que unos atacantes comprometieron el pipeline de releases de LiteLLM y publicaron en PyPI un litellm==1.107.0 malicioso, que estuvo disponible unas dos horas, además de tags comprometidos en Docker Hub y GHCR: v1.107.0, latest, main-latest y main-stable. Según el tracker, las wheels dejan cook.pth, cook.py y sitecustomize.py, que roban credenciales de la nube, de desarrollo y de herramientas de IA en cada arranque de Python y abren un cargador de código remoto. El tracker lo describe como el segundo compromiso de LiteLLM en 2026.
El tag latest merece una segunda mirada. Un contenedor que descarga latest al reiniciarse no necesitó que nadie actualizara nada para recibir esto.
Puede que tampoco sea un caso aislado. Railway, en su propia divulgación del mismo día, dice que cree que su incidente forma parte de una serie de ataques contra empresas de plataformas con el objetivo de comprometer a proveedores de inferencia de IA.
Por qué el objetivo es una pasarela de IA
Conocimiento general: una librería de pasarela o proxy existe para que tu aplicación hable con muchos proveedores de modelos a través de una sola interfaz. Eso significa que el proceso que la ejecuta tiene a la vez todas las claves de los proveedores en su entorno. Una dependencia comprometida normal se lleva las claves de un servicio. Esta se lleva las de cada proveedor, y las claves de IA son gasto que otra persona puede disparar.
Los ficheros de arranque lo empeoran. También es conocimiento general y comportamiento documentado de Python: los ficheros .pth de site-packages se procesan al arrancar el intérprete, y sus líneas que empiezan por import se ejecutan; sitecustomize también se ejecuta al arrancar. Así que una wheel maliciosa de este tipo no espera a que tu código importe la librería. Cualquier proceso de Python en ese entorno la ejecuta, incluido un script puntual o una ejecución de tests.
Para quien lee desde PHP o Node, la misma forma se aplica a cualquier cosa que guarde muchas credenciales: un wrapper sobre Stripe, Twilio o varios SDK de IA, o una CLI de despliegue con acceso a cada entorno.
Contención que limita el daño
Nada de esto impide que se comprometa un pipeline. Limita hasta dónde llega una release mala.
Fija por versión y por hash. Un número de versión por sí solo no frena un fichero republicado o sustituido; un hash sí. Con pip, un fichero de requirements que lista los hashes junto con --require-hashes rechaza cualquier otra cosa; los lock files de uv y pip-tools hacen lo mismo. Fija las imágenes de contenedor por digest en lugar de por un tag móvil como latest, y espera unos días antes de adoptar una release recién salida. Aísla. Instala y ejecuta la pasarela en su propio entorno o contenedor, que guarde solo las claves que necesita, y no instales nunca paquetes nuevos en una máquina con secretos de producción cargados. Acota las claves. Da a cada proveedor una clave separada, de vida corta y con límite de gasto, para que una robada salga barata y se sustituya rápido.
pip install --require-hashes -r requirements.txt
pip show litellm
Si se instaló o se descargó la 1.107.0
Orden general: saca el entorno o el contenedor de servicio, comprueba qué versión y qué tag de imagen se ejecutaron de verdad, reconstruye desde una release sana y fijada, y rota cada clave que ese entorno pudiera leer, desde una máquina limpia. Por los ficheros de arranque, cuenta cualquier proceso de Python de ese entorno, no solo la pasarela. Confirma las versiones y tags afectados en el aviso oficial de LiteLLM.
Fuente: el tracker de incidentes pwn.watch, entrada «LiteLLM 1.107.0 PyPI/Docker supply-chain compromise».
Notas de los lectores