Anatomía de un ataque a la cadena de suministro en GitHub: LiteLLM, paso a paso
El compromiso de la identidad de GitHub de LiteLLM paso a paso, y el único control que rompe cada eslabón de la cadena.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Un recorrido paso a paso por el compromiso de la cadena de suministro a través de una identidad de GitHub que sufrió LiteLLM en octubre de 2026, según se informó públicamente: de una clave maestra filtrada a un token OAuth de gh CLI de un propietario de la organización, la exfiltración de secretos de CI, una versión publicada a partir de un fork, el borrado de las ejecuciones y un force-push para encubrirlo. Cada paso nombra el único control que habría roto la cadena en ese punto: rotación, tokens con mínimo privilegio, ramas protegidas, publicación de confianza (trusted publishing) y alertas sobre el registro de auditoría. Los incidentes de cadena de suministro más dañinos de 2026 no dependieron de zero-days, sino de identidades robadas o mal gestionadas: una credencial con demasiado poder, que vivía demasiado tiempo y en el lugar equivocado. Es una cronología educativa, no una receta de exploit: aquí no hay nada que ayude a un atacante, solo la lección defensiva de cada salto. Funciona íntegramente en tu navegador, sin introducir datos ni hacer llamadas de red. PlayCISO no está afiliado a LiteLLM ni a GitHub, y nada se atribuye más allá de lo que se ha informado públicamente. Es una herramienta Pro: con una cuenta gratuita tienes 3 usos de herramientas Pro en total y después necesitas Pro.
- Sigue la cronología del incidente paso a paso, desde la clave maestra filtrada.
- En cada salto, lee qué capacidad normal de GitHub se usó con la identidad robada.
- Identifica el control que habría roto la cadena en ese punto.
- Contrasta esos controles con la configuración de tu propia organización.
Preguntas frecuentes
¿Qué pasó en el compromiso de GitHub de LiteLLM?
Según se informó públicamente en octubre de 2026, una clave maestra de larga duración se subió a un repositorio público y nunca se rotó. Un atacante la usó para llegar a un token OAuth de gh CLI de un propietario de la organización, y después ejecutó workflows de CI desechables que exfiltraron secretos de los mantenedores, publicó una versión construida a partir de un fork, borró los registros de las ejecuciones de los workflows e hizo un force-push para ocultar el cambio. Ningún paso fue un exploit novedoso: cada uno fue una capacidad normal de GitHub alcanzada con una identidad robada.
¿Fue una vulnerabilidad de GitHub?
No. Cada acción de la cadena (emitir un token, ejecutar un workflow, publicar una versión, borrar una ejecución, hacer force-push) es una función legítima de GitHub. El fallo fue de identidad y de configuración: una credencial que nunca debió estar en un repositorio, que nunca se rotó y que tenía poder de propietario de la organización sin nada que volviera a pedir verificación. Por eso las soluciones son controles (rotación, mínimo privilegio, protección de ramas, publicación de confianza, alertas de auditoría), no un parche.
¿Qué control lo habría detenido antes?
No subir la clave, o rotarla de forma periódica, habría acabado con la cadena antes de empezar: el escaneo de secretos con protección en el push bloquea la subida, y las credenciales de corta duración reducen la ventana si se filtra una. Después, los tokens de mínimo privilegio (un PAT de grano fino o una GitHub App en lugar de un token OAuth amplio de gh CLI en una cuenta de propietario) habrían contenido el radio de impacto incluso con una credencial robada.
¿Es segura esta herramienta? ¿Ataca algo?
Sí, es segura. Es una explicación estática en el navegador de un incidente informado públicamente. No realiza ningún ataque, no se conecta a nada y no recibe ninguna entrada. Su único propósito es enseñar el control defensivo que rompe cada eslabón de la cadena.
¿Es gratis?
No, es una herramienta Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.