Ataque a la cadena de suministro de LiteLLM roba credenciales mediante tokens filtrados de GitHub

El 21 de octubre de 2026, actores de amenazas comprometieron el pipeline de lanzamiento de LiteLLM, una biblioteca de gateway de IA de código abierto, para distribuir una versión maliciosa de su software. Los atacantes aprovecharon tokens OAuth filtrados de GitHub CLI, probablemente extraídos de los registros de aplicaciones, para eludir los controles de seguridad y enviar artefactos contaminados a los principales registros de paquetes.

Qué ocurrió

El incidente comenzó alrededor de las 4:00 a.m. (hora del Pacífico) cuando los atacantes publicaron la versión 1.107.0 de LiteLLM en el Python Package Index (PyPI), Docker Hub y GitHub Container Registry (GHCR). Esta versión comprometida contenía un ladrón de credenciales y una puerta trasera diseñada para cosechar secretos de los sistemas afectados. Los usuarios que descargaron versiones sin fijar (unpinned) mediante pip entre las 11:39 a.m. y la 1:23 p.m. UTC, o que extrajeron etiquetas específicas de Docker entre las 11:46 a.m. y las 2:20 p.m. UTC, quedaron expuestos al malware.

El código malicioso empleó un enfoque de doble técnica para garantizar la persistencia y la ejecución. Utilizó un archivo de ruta de Python llamado "cook.pth" para importar un script denominado "cook.py", que se desofuscaba a sí mismo para ejecutar una rutina llamada "privcollect". Esta rutina recopilaba secretos del sistema, del navegador, de la nube y de herramientas de IA, exfiltrándolos hacia un dominio controlado por el atacante. Además, en máquinas Linux y macOS, el malware ejecutaba "sitecustomize.py" para obtener instrucciones adicionales desde un repositorio de GitHub, estableciendo un troyano de acceso remoto que consultaba nuevos comandos cada hora.

Los mantenedores de LiteLLM rastrearon la brecha hasta una combinación de cambios operativos y exposición de registros. Aunque el proyecto había endurecido recientemente su pipeline de lanzamiento firmando imágenes y utilizando repositorios privados, los permisos se expandieron temporalmente para permitir que dos ingenieros publicaran correcciones de errores diarias. Los atacantes accedieron a tres conjuntos de credenciales de GitHub CLI de desarrolladores, sospechando que estos tokens estaban incrustados en cuerpos de respuesta registrados por un despliegue interno de LiteLLM expuesto a Internet. Un token perteneciente a un propietario de organización permitió al atacante deshabilitar las protecciones de ramas y forzar cambios maliciosos en un repositorio similar (lookalike), engañando al flujo de trabajo CI/CD para firmar y publicar los artefactos contaminados.

Detalles clave

• Versiones comprometidas: LiteLLM v1.107.0 en PyPI; v1.107.0, latest, main-latest y main-stable en Docker y GHCR.
• Ventana de impacto: Usuarios de PyPI entre las 11:39 a.m. y la 1:23 p.m. UTC; usuarios de Docker entre las 11:46 a.m. y las 2:20 p.m. UTC el 21 de octubre de 2026.
• Comportamiento del malware: Cosecha credenciales mediante "privcollect" y establece una baliza horaria hacia un servidor de comando y control usando GitHub como buzón muerto (dead drop).
• Vector de ataque: Tokens OAuth de GitHub CLI filtrados encontrados en los registros de LiteLLM fueron utilizados para autenticarse y manipular el flujo de trabajo de lanzamiento.
• Post-explotación: Las credenciales robadas de AWS fueron validadas dentro de las 4,5 horas siguientes, con los atacantes realizando actividades de LLMjacking como listar modelos fundacionales.
• Estado de mitigación: GitHub eliminó el repositorio malicioso alrededor de la 1:30 p.m. UTC; LiteLLM ha revocado desde entonces los permisos y rotado las credenciales.

Contexto

Los ataques a la cadena de suministro apuntan a las dependencias y procesos de compilación del software, en lugar de directamente a las aplicaciones de usuario final. En este caso, los atacantes no necesitaron explotar una vulnerabilidad en el propio código de LiteLLM, sino que comprometieron el mecanismo utilizado para distribuirlo. Al inyectar código malicioso en el paquete oficial, confiado por miles de desarrolladores, aseguraron una distribución generalizada sin levantar sospechas inmediatas.

El uso de tokens OAuth de GitHub CLI destaca un riesgo común en los flujos de trabajo de desarrollo modernos. Estos tokens otorgan acceso programático a recursos de GitHub y pueden tener privilegios elevados. Cuando dichos tokens se registran inadvertidamente en texto plano —a menudo por asistentes de codificación de IA o registros de aplicación verbosos— se convierten en objetivos fáciles para atacantes que escanean credenciales accesibles. Una vez obtenidos, estos tokens pueden eludir la autenticación multifactor si la sesión sigue activa, permitiendo a los atacantes actuar como desarrolladores legítimos.

Por qué es importante

Para los equipos que ejecutan su propio software, este incidente subraya la fragilidad de la confianza en las dependencias de código abierto. Incluso proyectos con prácticas de seguridad robustas, como artefactos firmados y etiquetas inmutables, pueden verse comprometidos si los flujos de trabajo operados por humanos se debilitan. La expansión temporal de los permisos de lanzamiento, destinada a mejorar la velocidad de desarrollo, creó una superficie de ataque que los adversarios explotaron. Esto sirve como recordatorio de que las funciones de conveniencia en los pipelines CI/CD deben estar cuidadosamente delimitadas y monitorizadas.

Además, la exposición de credenciales a través del registro de logs es un problema persistente de higiene de seguridad. Muchas aplicaciones autoalojadas y gateways de IA registran cuerpos de solicitud y respuesta con fines de depuración. Si estos registros contienen tokens o claves sensibles, cualquier brecha en la infraestructura de registro —o incluso la exposición accidental pública de un endpoint de depuración— puede conducir a una compromiso catastrófico. Los equipos deben asumir que los registros son potenciales almacenes de secretos y tratarlos con el mismo rigor de seguridad que los contenidos de bases de datos.

La rapidez con la que los atacantes utilizaron las credenciales robadas demuestra la urgencia de la respuesta a incidentes. Dentro de las horas posteriores a la exfiltración, los adversarios estaban enumerando activamente recursos en la nube y validando el acceso. Para los líderes de IT y DevOps, esto significa que los mecanismos de detección y rotación deben ser automatizados e inmediatos. Esperar a una investigación manual antes de rotar las claves permite a los atacantes tiempo suficiente para establecer persistencia y moverse lateralmente dentro de los entornos de nube.

Qué puedes hacer

• Verificar versiones instaladas: Verifica inmediatamente si LiteLLM v1.107.0 o alguna de las etiquetas afectadas de Docker están presentes en tu entorno y elimínalas si las encuentras.
• Rotar todas las credenciales: Asume que cualquier secreto almacenado en sistemas que ejecutaron la versión comprometida está expuesto. Rota las claves API, credenciales de nube y tokens de GitHub inmediatamente.
• Auditar registros en busca de tokens: Revisa los registros de tus aplicaciones y gateways de IA para asegurar que ningún token OAuth o secreto esté siendo registrado en texto plano. Implementa filtros de sanitización de logs.
• Restringir permisos de lanzamiento: Evita expansiones temporales de los privilegios de lanzamiento. Si es necesario, utiliza tokens de corta duración y alcance limitado, y requiere pasos adicionales de aprobación para publicar en registros públicos.
• Fijar versiones de dependencias: Fija siempre versiones específicas de bibliotecas de terceros en tus archivos de requisitos para evitar la instalación automática de actualizaciones potencialmente comprometidas.
• Monitorizar actividad sospechosa: Revisa los registros de auditoría de la nube en busca de llamadas API inusuales, como listados inesperados de modelos o enumeración de IAM, lo cual puede indicar intentos de LLMjacking.