Ataque a la cadena de suministro de LiteLLM rastreado hasta una clave maestra no revocada y exfiltración vía webhooks

LiteLLM reveló el 24 de octubre de 2026 una grave vulnerabilidad en su cadena de suministro, originada por una fuga de clave maestra ocurrida en mayo. Un atacante utilizó este acceso para inyectar código malicioso en la versión 1.107.0 del popular paquete Python, con el objetivo de comprometer las credenciales de desarrolladores y los entornos del sistema.

Qué ocurrió

El incidente comenzó el 27 de mayo de 2026, cuando un archivo de configuración que contenía una clave maestra del Agent Platform de LiteLLM se subió accidentalmente a un repositorio público de GitHub. Aunque el equipo realizó rápidamente un force-push para sobrescribir el commit e identificó la necesidad de revocar la clave, esta nunca llegó a ser invalidada. El 10 de octubre de 2026, un atacante que operaba desde la dirección IP 69.48.229.143 usó esta clave, aún válida, para acceder al Agent Platform. Desde allí, extrajo un token OAuth de GitHub CLI que no tenía permisos restringidos y estaba asociado a la cuenta del propietario de la organización.

Con acceso de nivel propietario, el atacante ejecutó una serie de operaciones sigilosas. El 10 de octubre, creó ramas de vida corta en repositorios internos para ejecutar workflows diseñados para cosechar credenciales adicionales. Estas ramas fueron eliminadas en cuestión de minutos, dejando pocas huellas en el historial estándar. Para el 21 de octubre, el atacante había anulado las protecciones de ramas y alterado el pipeline de publicación para apuntar a un repositorio falso (lookalike). Utilizó tokens robados de ingenieros para activar y aprobar el lanzamiento de LiteLLM versión 1.107.0 en PyPI, Docker Hub y GHCR antes de eliminar registros de producción para borrar sus rastros.

El paquete malicioso fue puesto en cuarentena por PyPI y retirado de los registros de contenedores ese mismo día, tras ser reportado por investigadores de seguridad. LiteLLM confirmó que el atacante podría haber relajado aún más las restricciones de publicación, pero probablemente evitó hacerlo para no levantar sospechas. La empresa está trabajando ahora para revocar todos los tokens asociados con sus sistemas internos y plataformas de proveedores.

Cómo funciona

El método principal del atacante para robar credenciales consistió en inyectar workflows maliciosos de GitHub Actions en ramas desechables. Estos workflows, denominados cache.yml, estaban configurados para ejecutarse en cada push. Recolectaban secretos como claves API de Anthropic, OpenAI, AWS Bedrock y GitGuardian, así como credenciales de bases de datos y estados de sesión de navegadores. Los datos robados se exfiltraron hacia endpoints controlados por el atacante en webhook.site, un servicio que permite a los usuarios inspeccionar solicitudes HTTP entrantes.

Una vez publicado, la versión comprometida de LiteLLM 1.107.0 contenía malware que se ejecutaba automáticamente al iniciar Python, incluso si la biblioteca no era importada. El malware incluía un módulo de cosecha de credenciales que escaneaba material de autenticación en herramientas de desarrollo, entornos cloud y navegadores. También instalaba una puerta trasera orientada a Unix que descargaba y ejecutaba código arbitrario desde el servidor del atacante cada hora. Esto significaba que simplemente iniciar Python en un entorno afectado podía activar el código malicioso, extendiendo el riesgo más allá de los despliegues activos de LiteLLM.

Detalles clave

• El vector inicial de la brecha fue una clave maestra filtrada el 27 de mayo de 2026, que nunca fue revocada a pesar de haberse identificado como expuesta.
• Los atacantes utilizaron endpoints de webhook.site para exfiltrar credenciales robadas, incluyendo claves API y contraseñas de bases de datos.
• Los workflows maliciosos se subieron a ramas de vida corta y se eliminaron en minutos para evitar detección en el historial del repositorio.
• La versión comprometida del paquete 1.107.0 fue publicada en PyPI y registros de contenedores el 21 de octubre de 2026.
• El malware se ejecuta al iniciar Python e incluye una puerta trasera que se comunica con litellm.dev cada hora.
• Las credenciales robadas incluían acceso a Linear, Together AI y plataformas de escaneo de secretos como GitGuardian.

Por qué es importante

Este incidente destaca los graves riesgos de una gestión inadecuada de claves y pipelines CI/CD excesivamente permisivos. La falta de revocación de una clave comprometida conocida meses después de su exposición permitió al atacante mantener un acceso persistente. Para los equipos de ingeniería, esto subraya la importancia de tratar la rotación de claves como un control de seguridad crítico y no como una tarea de mantenimiento opcional. También demuestra cómo controles de publicación relajados, incluso por conveniencia temporal, pueden crear vulnerabilidades que los atacantes explotan para eludir procesos de aprobación multi-persona.

El uso de exfiltración basada en webhooks muestra cómo los atacantes aprovechan herramientas legítimas de depuración para robar datos sin activar alertas de seguridad tradicionales. Dado que los datos se enviaban a endpoints de webhooks externos, se evitaba la monitorización de red interna. Los desarrolladores e ingenieros de seguridad deben reconocer que cualquier servicio capaz de recibir solicitudes HTTP puede utilizarse como canal de exfiltración de datos. Comprender cómo están estructuradas estas solicitudes y qué contienen es esencial para detectar y prevenir tales ataques.

Qué puedes hacer

• Audita todos los pipelines CI/CD en busca de permisos demasiado amplios y asegúrate de que los tokens estén limitados al mínimo acceso necesario.
• Implementa protocolos automatizados de rotación de claves y revocación inmediata para cualquier credencial expuesta en repositorios públicos.
• Monitoriza ejecuciones de workflows inusuales, especialmente aquellas que involucran ramas de vida corta o eliminaciones rápidas.
• Inspecciona las solicitudes HTTP salientes desde tus entornos de compilación para detectar exfiltración no autorizada de datos hacia servicios externos.
• Verifica la integridad de paquetes de terceros comprobando hashes y utilizando lock files para evitar actualizaciones inesperadas.
• Revisa y restringe el acceso a los pipelines de publicación, asegurando que las relajaciones temporales de los controles de seguridad sean estrictamente limitadas en el tiempo y monitorizadas.