El proceso de publicación de LiteLLM se vio comprometido el 21 de octubre de 2026, lo que permitió a un atacante publicar una versión maliciosa del software de pasarela de IA a través de PyPI, Docker Hub y GitHub Container Registry.
La versión afectada, LiteLLM v1.107.0, recopiló credenciales y otros secretos de los sistemas donde se ejecutaba, según los hallazgos de Aikido y Wiz difundidos por The Hacker News. Posteriormente, Wiz observó intentos de validar credenciales de AWS robadas desde runners de CI y nodos de Kubernetes comprometidos.
LiteLLM dio a conocer el incidente en un aviso publicado el miércoles. La compañía situó la intrusión alrededor de las 4:00 a. m. PST del 21 de octubre de 2026.
Qué paquetes y etiquetas de contenedor se vieron afectados
Los artefactos comprometidos incluyeron:
- Paquete de PyPI LiteLLM v1.107.0
- Etiqueta de Docker/GHCR v1.107.0
- Etiqueta de Docker/GHCR latest
- Etiqueta de Docker/GHCR main-latest
- Etiqueta de Docker/GHCR main-stable
En el caso de PyPI, la ventana de exposición notificada abarca a los usuarios que instalaron con pip un paquete de LiteLLM sin versión fijada entre las 11:39 a. m. y la 1:23 p. m. UTC.
La ventana de exposición de los contenedores fue de 11:46 a. m. a 2:20 p. m. UTC para los usuarios que descargaron o usaron de otro modo las etiquetas de imagen indicadas. Como intervinieron varias etiquetas mutables, comprobar solo la etiqueta configurada en un despliegue puede no bastar para determinar qué imagen se ejecutó realmente; los equipos de defensa deberían verificar el artefacto o la imagen exacta que utilizaron.
Los tokens de GitHub robados permitieron una versión envenenada
Según la cuenta de LiteLLM, el atacante tuvo acceso a tres conjuntos de credenciales de la CLI de GitHub de desarrolladores. Uno de ellos podía activar flujos de trabajo de GitHub, mientras que un token perteneciente a un propietario de la organización se usó para desactivar las protecciones de ramas y hacer push forzado de cambios maliciosos.
El flujo de trabajo comprometido fue redirigido desde el repositorio legítimo BerriAI/litellm a uno de nombre parecido, Berri-AI/litellm. Esa sustitución hizo que los paquetes e imágenes maliciosos resultantes pasaran por el proceso de firma y publicación del proyecto.
Dos días antes, el 19 de octubre de 2026, LiteLLM había ampliado temporalmente los permisos de publicación para dos ingenieros internos encargados de emitir backports diarios de corrección de errores para clientes.
La compañía sospecha que los tokens de GitHub podrían haber quedado expuestos a través de registros de un despliegue interno accesible desde internet, donde encontró una cuenta inesperada de nombre inofensivo. LiteLLM dijo que Claude Code puede colocar el token OAuth de la CLI de GitHub de un usuario dentro del cuerpo de una respuesta; si esos cuerpos se registran, el token puede, en consecuencia, aparecer en los registros de LiteLLM. La compañía presentó esto como una vía sospechada y no como un punto de entrada inicial confirmado.
LiteLLM afirmó que había introducido protecciones adicionales en la publicación tras un incidente separado en marzo de 2026, entre ellas trasladar las publicaciones a un repositorio privado, hacer inmutables las etiquetas de versión de Docker y firmar las imágenes de contenedor. Aun así, en el compromiso de octubre el atacante logró manipular el flujo de trabajo responsable de generar y publicar los artefactos firmados.
El malware recopiló secretos y mantuvo una puerta trasera cada hora
Aikido y Wiz describieron dos mecanismos de ejecución de Python incrustados en la versión comprometida.
El primero usaba cook.pth, que importaba un módulo de Python llamado cook. Su script correspondiente, cook.py, se desofuscaba a sí mismo y lanzaba una rutina de robo de credenciales llamada privcollect.
El robador tenía como objetivo secretos asociados con:
- Sistemas operativos
- Navegadores web
- Herramientas de desarrollo
- Entornos de nube
- Herramientas de IA
La información recopilada se enviaba mediante una solicitud HTTP POST a:
litellm[.]dev/healthcheck
En Linux y macOS, un segundo componente llamado sitecustomize.py intentaba obtener domain.txt desde un dead drop de GitHub asociado a github[.]com/letters9813. Una respuesta válida proporcionaba la dirección desde la que el malware podía descargar y ejecutar un script de Python de segunda etapa en <domain>/codepy.
El componente también bifurcó un proceso en segundo plano, creó el archivo de bloqueo /tmp/remote_code_loader.lock y entró en un bucle que consultaba el dead drop cada hora antes de intentar ejecutar de nuevo la carga remota. Aikido caracterizó este mecanismo como un troyano de acceso remoto.
Wiz indicó que GitHub eliminó el archivo de texto del dead drop alrededor de la 1:30 p. m. UTC. Antes de su eliminación, según se informa, el archivo contenía solo valores de prueba iniciales.
Las credenciales de AWS se probaron horas después de la exfiltración
Wiz informó de que el abuso comenzó aproximadamente 4,5 horas después de la exfiltración de credenciales. Entre las 4:20 p. m. y las 5:01 p. m. UTC del 21 de octubre de 2026, el atacante probó credenciales de rol de instancia de AWS obtenidas de runners de CI y nodos de Kubernetes.
Cada credencial se comprobó con:
sts:GetCallerIdentitybedrock:ListFoundationModels- Una llamada a
ListModels
Wiz consideró que esa actividad era coherente con LLMjacking, práctica en la que se prueban credenciales de nube robadas para comprobar el acceso a servicios de IA alojados. En un número reducido de entornos, el atacante también realizó tareas de descubrimiento de IAM e infraestructura mediante operaciones como ListRoles, ListUsers, ListAccessKeys, ListAccounts y DescribeTrails.
El tráfico de validación de credenciales estaba asociado con:
168.100.8[.]57
165.227.201[.]8
Aunque el uso de un archivo .pth recuerda al ataque de marzo de 2026 que la cobertura atribuye a TeamPCP, Socket no encontró pruebas públicas que establezcan que ambos incidentes compartieran operador. Socket señaló diferencias en las claves públicas RSA incrustadas, en el código de exfiltración y en el comportamiento de la puerta trasera. También indicó que las pruebas disponibles no permiten establecer si las credenciales robadas en marzo contribuyeron al compromiso de octubre.
Qué deben hacer ahora los usuarios de LiteLLM
Las organizaciones que instalaron o ejecutaron LiteLLM 1.107.0, incluidas las que lo hicieron a través de las etiquetas de contenedor afectadas, deben tratar como potencialmente comprometidos el host y las credenciales accesibles para ese proceso.
Entre las acciones recomendadas se incluyen:
- Eliminar LiteLLM 1.107.0 de las máquinas y los entornos de despliegue.
- Aislar los hosts afectados mientras se investiga a qué accedió el paquete.
- Buscar:
cook.pthcook.pysitecustomize.py/tmp/remote_code_loader.lock
- Bloquear e investigar las conexiones a:
litellm[.]dev/healthcheckgithub[.]com/letters9813raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt
- Investigar cualquier ejecución intentada o exitosa de
/codepy. - Revisar los registros de AWS en busca de actividad relacionada con las direcciones IP señaladas y con las llamadas a la API indicadas.
- Rotar todas las credenciales accesibles desde un entorno afectado, incluidos los secretos de nube, desarrollo, navegador y servicios de IA.
- Reconstruir los sistemas afectados a partir de artefactos confiables, en lugar de confiar solo en la eliminación de los archivos maliciosos.
El investigador de JFrog Guy Korolevski también recomendó a las organizaciones confirmar el archivo wheel exacto instalado y validar las versiones de los paquetes antes de incorporarlas a los sistemas de compilación. Cuando 1.107.0 se ejecutó, la recomendación de JFrog es rotar todas las credenciales a las que pudo acceder y reconstruir el entorno afectado.
