LiteLLM 1.107.0 con puerta trasera: así funcionaba el ladrón .pth

El 21 de octubre de 2026, uno de los gateways de LLM de código abierto más desplegados se convirtió durante unas dos horas en un ladrón de credenciales. Se publicaron artefactos maliciosos de LiteLLM 1.107.0 en PyPI, Docker Hub y GHCR, y la carga útil hacía algo que merece la atención de todo equipo de seguridad: se ejecutaba al arrancar Python, antes de que LiteLLM llegara a importarse, y enviaba tus claves de nube, de IA, SSH y GPG a un dominio parecido al oficial. Es el segundo golpe a la cadena de suministro de LiteLLM en 2026, y el mecanismo es un caso didáctico limpio.

Análisis independiente, basado en la documentación, para responsables de seguridad e ingeniería, a partir del aviso oficial de LiteLLM y su incidencia en GitHub, más investigaciones que lo corroboran (Socket, Wiz, Endor Labs, Upwind, The Hacker News). PlayCISO no está afiliado a LiteLLM/BerriAI. No señalamos a ninguna persona como atacante: el proyecto es víctima de un compromiso de su pipeline; la investigación sobre el vector de entrada sigue abierta.

La parte ingeniosa y dañina: ejecución sin importación

La mayoría razona sobre el riesgo de las dependencias como «el código se ejecuta cuando lo llamo». El mecanismo .pth rompe esa suposición. Python procesa los archivos .pth de site-packages al arrancar el intérprete, y cualquier línea que empiece por import se ejecuta de inmediato. Al dejar un cook.pth, el atacante se aseguró de que el ladrón se disparara en el instante en que arrancara cualquier proceso de Python en ese entorno (una tarea cron, una comprobación de estado, un script sin ninguna relación), tanto si algo importaba litellm o arrancaba el proxy como si no. Por eso, «lo instalamos pero nunca lo usamos» no es una posición segura en este incidente. Es la misma lección que la de los scripts postinstall maliciosos de npm: la propia instalación es ejecución de código.

Por qué el pipeline y no el código

El código fuente público de la v1.107.0 estaba bien. Los artefactos, no. Esa diferencia (etiqueta de Git de confianza, wheel publicado envenenado) es la firma de un compromiso del pipeline de releases, y es justo por lo que importan la firma y la procedencia: si tu compilación emite artefactos firmados con una procedencia verificable (quién lo compiló, desde qué commit y en qué runner), un wheel compilado desde un repositorio controlado por el atacante falla la verificación antes de llegar a un desarrollador o a un contenedor. Las compilaciones reproducibles y las dependencias fijadas y verificadas por hash cierran la misma brecha desde el lado del consumidor.

Qué debería hacer ahora un equipo de seguridad

• Fija la v1.106.2, la última release anterior a la comprometida, y fíjala por hash.
• Localiza la exposición. Cualquier pip install litellm==1.107.0 o descarga de las etiquetas de imagen afectadas dentro de la ventana (aproximadamente de 04:40 a 06:40 PDT / de 11:40 a 13:40 UTC del 21 de octubre; las etiquetas flotantes de Docker tardaron en reflejar la retirada, así que trata como sospechosas también las descargas algo posteriores) está dentro del alcance.
• Reconstruye; no te limites a desinstalar. El .pth puede haberse ejecutado ya, así que una desinstalación en el sitio no devuelve la confianza: reconstruye el host o el contenedor desde fuentes limpias y verificadas.
• Rota todo lo que el entorno pudiera leer: claves de proveedores de nube, claves de API de proveedores de IA, claves SSH y GPG y cualquier clave maestra del proxy de LiteLLM. Trátalas como expuestas, no como «posiblemente expuestas».
• Busca los IOC: los investigadores citan los archivos /tmp/.pc_once_* y /tmp/remote_code_loader.lock, y las conexiones salientes a www.litellm.dev. La monitorización de la salida de red habría señalado ese dominio de exfiltración: un recordatorio de que denegar por defecto la salida en los hosts de compilación y de inferencia es un control real, no un lujo.

La lección permanente para los equipos de plataformas de IA

Las herramientas de IA se han vuelto parte del camino crítico y llevan el mismo riesgo de cadena de suministro que cualquier otra dependencia; podría decirse que más, porque los gateways y los proxies están encima de tus secretos más sensibles (cada clave de modelo, cada credencial de nube): el mismo riesgo de acumulación de credenciales que vació las claves de los desarrolladores en la brecha de la consola de OpenCode. Las defensas duraderas son poco vistosas y funcionan: descarga desde un registro privado verificado (los despliegues empresariales que lo hacían no se vieron afectados), fija y verifica por hash las versiones, exige firma de artefactos y procedencia, mantén un inventario de lo que ejecutas de verdad y pon controles de salida alrededor de los hosts de compilación y de inferencia para que un ladrón no pueda llamar a casa. Fue el segundo incidente de cadena de suministro de LiteLLM del año; los equipos que trataron el primero como un sistema que arreglar, y no como un hecho aislado, tuvieron mucho menos que hacer esta mañana.

Ponlo en práctica

Creamos herramientas justo en torno a estos controles:

• Release Pipeline Integrity Scorecard: puntúa tu pipeline de compilación y de releases frente a las debilidades que explotó este incidente (procedencia, firma, reproducibilidad, confianza en el registro).
• Generador de AIBOM: una lista de materiales de IA para saber de verdad qué servicios ejecutan qué componentes de IA y en qué versiones cuando llegue el próximo aviso.
• Contexto del golpe anterior: el ataque TeamPCP a LiteLLM, y el ángulo de la integridad del pipeline en el compromiso del CLI de OVHcloud.

Sigue el aviso oficial de LiteLLM y la incidencia de GitHub #47826 para los pasos de remediación oficiales, actualizados de forma continua, y la investigación de causa raíz en curso.