Ataque a la cadena de suministro de LiteLLM, Zeabur, Gheist

Ataque a la cadena de suministro de LiteLLM, brecha de seguridad de Zeabur, Gheist: Credenciales no revocadas (ilustración de un bocadillo con el texto «Cybersecurity News Weekly» y un rayo amarillo)

En octubre, una clave subida en mayo a un repositorio público ayudó a envenenar una versión de un gateway de IA muy utilizado: el ataque a la cadena de suministro de LiteLLM. Con pocos días de diferencia, una plataforma de alojamiento admitió que unos tokens de administrador sin cambios desde enero de 2024 habían abierto sus sistemas de producción.

Estos incidentes comparten un mismo fallo: credenciales que siguieron siendo válidas mucho después de que debieran haberse revocado, restringido o rotado. A continuación se repasan cinco incidentes, lo que muestra cada uno y qué revisar primero.

LiteLLM: una clave maestra no revocada llevó al robo de un token de propietario de GitHub y a una versión maliciosa, según LiteLLM y Microsoft
Zeabur: unos tokens de administrador en texto en claro y sin caducidad expusieron 321 810 cuentas, según Zeabur
Gheist: con tokens de GitHub robados se implantan flujos de trabajo que imprimen los secretos del repositorio en los logs, informa Help Net Security
PingCAP: unas credenciales robadas dieron acceso a los atacantes durante un periodo notificado de 28 días, según PingCAP
Aokigahara: un infostealer (malware de robo de información) recopila credenciales de herramientas de programación con IA y claves de la nube, escribe Check Point Research

Ataque a la cadena de suministro de LiteLLM 1.107.0: Una clave maestra filtrada

Qué ocurrió: el 27 de mayo de 2026, una clave maestra de LiteLLM Agent Platform se subió a un repositorio público de GitHub. El análisis de la cadena de ataque publicado por LiteLLM indica que el commit se sobrescribió, pero The Hacker News informa de que la clave en sí nunca se revocó. El 10 de octubre, un atacante la utilizó para leer un token OAuth de GitHub CLI perteneciente a un propietario de la organización. Según LiteLLM, el alcance del token no estaba restringido, por lo que daba acceso a todos los repositorios de la organización.

A continuación, el atacante subió flujos de trabajo de corta duración que enviaban los secretos del repositorio a un endpoint externo. Socket contabiliza 20 nombres de secretos distintos en los flujos de trabajo recuperados del 10 y el 12 de octubre, desde tokens de GitHub hasta credenciales de Anthropic, OpenAI y bases de datos, y sitúa la ventana de compromiso en «al menos once días» antes de la publicación. La cronología de LiteLLM es más acotada: la primera ejecución del 10 de octubre envió seis secretos, entre ellos GH_TOKEN; la segunda envió RELEASE_PLEASE_TOKEN, y ejecuciones posteriores del 12 de octubre en repositorios privados enviaron más.

El 21 de octubre, el atacante dirigió el pipeline de publicación a un repositorio de nombre similar, Berri-AI en lugar de BerriAI. Según The Hacker News, poco antes se había relajado una regla de aprobación más estricta, de modo que dos ingenieros cualesquiera podían iniciar y aprobar una publicación. Los tokens robados hicieron el resto: el token del propietario inició la publicación, el token de un segundo mantenedor (almacenado como GH_TOKEN) aprobó el control de producción y el de un tercero (RELEASE_PLEASE_TOKEN) eliminó después los registros de la ejecución. Siete paquetes wheel maliciosos de LiteLLM 1.107.0 llegaron a PyPI hacia las 11:40 UTC, y el análisis de Microsoft muestra que la carga útil se ejecutaba al iniciarse Python, aunque LiteLLM nunca se importara. PyPI había puesto la versión en cuarentena a las 13:23 UTC, por lo que los paquetes estuvieron disponibles durante aproximadamente 1 hora y 43 minutos.

Por qué importa: el malware apunta a credenciales de la nube y de Kubernetes, tokens de Git y de registros de paquetes, claves SSH, archivos dotenv, credenciales del navegador y la configuración de herramientas de IA. Quien haya instalado la versión 1.107.0 en un host con acceso a internet debería dar por expuesto todo aquello a lo que ese host podía acceder. Microsoft afirma que eliminar el paquete o una etiqueta de versión no basta para recuperarse, porque los archivos de inicio están fuera del directorio de LiteLLM.

La lección defensiva: no empiece por pip install, porque cualquier inicio de Python vuelve a ejecutar la carga útil. Fije la versión 1.106.2, como recomienda LiteLLM. Busque cook.pth y sitecustomize.py en todos los entornos, además de cook.py, los archivos pycache correspondientes y el proceso cargador desvinculado que mantiene /tmp/remote_code_loader.lock, y reconstruya a partir de imágenes limpias en lugar de limpiar el sistema afectado. Rote todo aquello a lo que el host podía acceder desde un equipo limpio y revise en CloudTrail si el rol de la instancia se ha usado desde fuera de su infraestructura. Los hallazgos de Microsoft sobre material de sesión robado hacen que también sea sensato revocar las sesiones, no solo las claves. Después, plantéese la pregunta más difícil: si un secreto se filtra a un repositorio, ¿quién lo revoca y cómo se confirma que ya no funciona?

Fuentes: LiteLLM; Microsoft Security; Socket; The Hacker News; Publicación de LiteLLM sobre el incidente

Zeabur: Tokens de administrador sin rotar desde enero de 2024 exponen 321 810 cuentas

Qué ocurrió: el 14 y el 15 de octubre de 2026 (UTC), un atacante utilizó credenciales internas que, según Zeabur, estaban almacenadas en texto en claro en un repositorio de configuración privado, con las contraseñas root de GCP guardadas en la configuración de inicialización de los servidores. Los tokens de administrador de los clústeres compartidos no caducaban, la interfaz de administración era accesible desde internet y Zeabur no ha confirmado cómo los obtuvo inicialmente el atacante: considera una hipótesis el vínculo con su incidente de agosto. El atacante leyó variables de entorno de los clústeres compartidos, inició sesión como root en 101 servidores dedicados en GCP, lo que afectó a 92 usuarios, y leyó la base de datos de la plataforma: 3 218 965 registros de variables de entorno y 321 810 cuentas, según el informe de Zeabur.

BleepingComputer informa de que se trata de la segunda brecha de seguridad de Zeabur en menos de dos meses. El aviso de cierre de Zeabur indica que las renovaciones de servidores dedicados están desactivadas y que los clústeres compartidos quedan en pausa desde el 1 de diciembre; cada servidor dedicado caduca entre el 1 y el 31 de diciembre, y todo se detiene a más tardar el 31 de diciembre. Zeabur afirma que la rotación de agosto no cubrió las credenciales utilizadas esta vez. Las cifras anteriores muestran lo que estaba al alcance del atacante, no prueban que se descargara cada valor, y Zeabur reconoce que sus logs están incompletos en algunos puntos.

Por qué importa: el incidente de agosto fue la advertencia, y la rotación posterior fue incompleta. Zeabur también informa de más de 16 horas de actividad del atacante el 14 de octubre que no generaron ninguna alerta. Cada variable de entorno de la plataforma contenía secretos propios de un cliente, de modo que una sola brecha en la plataforma se convirtió en miles de filtraciones de credenciales en cadena.

La lección defensiva: los pasos siguientes son una recomendación de Passwork, no de Zeabur: elabore un inventario completo de tokens de administrador y claves de la nube antes de necesitar rotarlos. Ponga fecha de caducidad a cada token de larga duración, mantenga las interfaces de administración fuera de la internet pública y no guarde credenciales en repositorios ni en la configuración de inicialización de los servidores. Si utiliza una plataforma de alojamiento como esta, considere expuesta cada variable que haya almacenado en ella y sustitúyala.

Fuentes: Zeabur; BleepingComputer; Aviso de cierre de Zeabur

Gheist: Los tokens de GitHub robados convierten los flujos de trabajo de CI en recolectores de secretos

Qué ocurrió: Wiz Research recuperó más de 13 500 ramas implantadas en más de 850 cuentas de GitHub comprometidas y bautizó la campaña como Gheist por el user agent que utiliza. Wiz empezó a seguirla el 15 de septiembre y publicó sus hallazgos el 25 de octubre, según informa Help Net Security. La herramienta toma un token robado, localiza todos los repositorios a los que puede acceder y sube una rama llamada «ci-sync-» seguida de seis caracteres, con un flujo de trabajo llamado «sync-check». El flujo de trabajo imprime los secretos del repositorio en el log de la ejecución codificados en Base32, un formato que el enmascaramiento de logs de GitHub no detecta. La herramienta descarga el log a través de la API y elimina la ejecución segundos después, por lo que Wiz no encontró ningún dominio del atacante ni conexión saliente que bloquear. GitHub solo enmascara los secretos cuando aparecen literalmente, y por eso los valores codificados se imprimen completos.

Desde el 28 de julio, GitHub retiene para su aprobación ciertas ejecuciones de flujos de trabajo potencialmente maliciosas, pero solo en repositorios públicos de github.com. Según Wiz, esta retención no cubre los repositorios privados ni GitHub Enterprise Server, y Wiz observó explotación en ellos. En organizaciones empresariales, Wiz vio cómo la herramienta recorría en pocos minutos los tokens de varios usuarios y cuentas de automatización, y horas después se utilizaron credenciales de la nube de la misma organización para enumerar AWS Secrets Manager. Wiz no nombra a las organizaciones ni indica cuántas se vieron afectadas.

Por qué importa: un solo token personal robado puede exponer todos los secretos de todos los repositorios a los que llega su propietario, incluidas las credenciales de producción con ámbito de entorno. Eliminar la ejecución no revierte la exposición.

La lección defensiva: revise el registro de auditoría de GitHub en busca del user agent «gheist» y los logs de la nube en busca de asunciones de roles mediante OIDC vinculadas a ramas «ci-sync-». Wiz recomienda rotar todos los secretos de repositorio, organización y entorno a los que pudiera llegar un token comprometido, y revocar los propios tokens. La señal de la rama solo funciona si el subject de OIDC incluye la rama. Limite qué tokens pueden subir flujos de trabajo y configure alertas ante nuevos archivos de flujo de trabajo en ramas nuevas.

Fuentes: Help Net Security; Wiz; Registro de cambios de GitHub

PingCAP: Credenciales robadas y 28 días de acceso notificado

Qué ocurrió: PingCAP informa de que, entre el 9 de septiembre y el 7 de octubre de 2026, un tercero no autorizado utilizó credenciales robadas de una cuenta de servicio para acceder a sistemas internos, copiar datos y obtener código fuente. La empresa tuvo conocimiento de ello el 7 de octubre y empezó a desactivar las credenciales ese mismo día. Entre los datos expuestos figuran datos de cuentas y de uso del producto de TiDB Cloud, datos de contratos y facturación, y valores encriptados de claves de API. PingCAP afirma que no hay pruebas de que se haya accedido a los datos almacenados en las bases de datos TiDB de los clientes ni de que se hayan visto afectados, pero sí se copiaron registros relacionados con clientes de sus sistemas internos de analítica, almacenamiento y soporte, y la empresa aún está determinando si se expusieron otras credenciales utilizables. Su informe del 19 de octubre no explica cómo se robaron las credenciales. La nota del CEO de PingCAP del 23 de octubre y el análisis posterior de NebuSec describen el acceso inicial como una cuenta de GitHub comprometida y credenciales expuestas, y afirman que la clave de encriptación de los valores de claves de API exportados no quedó expuesta, por lo que no pudieron descifrarse para obtener claves utilizables. Esto no cubre las credenciales que los clientes compartieron en materiales de soporte.

Por qué importa: las cuentas de servicio rara vez tienen un propietario, una fecha de caducidad o una persona que detecte un comportamiento anómalo. El periodo de acceso notificado fue de 28 días, aunque no necesariamente en una única sesión ininterrumpida.

La lección defensiva: asigne a cada cuenta de servicio un propietario identificado, los permisos mínimos que funcionen y una fecha de rotación. Configure alertas ante exportaciones grandes e inusuales. PingCAP describe como trabajo en curso una rotación de credenciales más amplia, revisiones de accesos y un análisis de secretos ampliado, lo que constituye una plantilla razonable para su propia lista.

Fuentes: PingCAP; Nota del CEO de PingCAP; NebuSec

Aokigahara: Un infostealer que va tras las credenciales de herramientas de programación con IA

Qué ocurrió: Check Point Research documenta (23 de octubre) un infostealer para Windows al que denomina Aokigahara, con un módulo específico para las sesiones de herramientas de IA. Busca archivos utilizados por Claude, Codex, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Amazon Q, Kiro y JetBrains AI Assistant, además de credenciales de AWS y cachés de SSO. Su módulo para IDE también recopila archivos de credenciales de Git, archivos SSH que pueden contener claves privadas y credenciales de Azure y Google Cloud. Conserva funciones más antiguas: contraseñas y cookies del navegador, monederos de criptomonedas y datos de aplicaciones de gestores de contraseñas. El informe de Symantec del 15 de octubre, que recogió Infosecurity Magazine, identifica el malware como Aoki (también conocido como Aokigahara), detectado por primera vez a lo largo de 2026, y señala que las claves de IA robadas pueden revenderse o utilizarse para generar cargos en la cuenta de la víctima, una práctica que a veces se denomina LLMjacking.

Por qué importa: un equipo de desarrollo contiene las mismas credenciales que los atacantes utilizaron contra LiteLLM: tokens, claves de la nube y claves SSH. Check Point afirma que no pudo confirmar cómo monetizan los datos los operadores, y menciona como posibilidades la reventa, el abuso de servicios de pago y la extorsión. Las listas anteriores recogen lo que el malware recopila, no prueban que se exfiltraran los datos de todas las víctimas.

La lección defensiva: trate las credenciales y los archivos de sesión de las herramientas de IA con la misma sensibilidad que las sesiones del navegador, las credenciales de la nube y las claves de desarrollo, como recomienda Check Point. Siempre que sea posible, mantenga las claves de larga duración fuera de los equipos de desarrollo, utilice tokens de corta duración y rote rápidamente cuando una estación de trabajo se marque como sospechosa.

Fuentes: Check Point Research; Symantec; Infosecurity Magazine

Qué significa para su equipo

Todos los casos anteriores terminan igual: una credencial que alguien daba por inactiva seguía funcionando. Seis comprobaciones que conviene hacer ya:

Revocar ante cualquier exposición. Sobrescribir un commit no invalida una clave. Trate como quemado cualquier secreto que haya pasado por un repositorio, un log o un chat, y confirme que el valor antiguo ya no funciona.
Limitar el alcance y la caducidad de cada token. Sustituya los tokens de propietario de la organización por otros de alcance reducido y corta duración. Ponga fecha de caducidad a los tokens de administración y de servicio, para que un token de enero de 2024 no pueda abrir nada en octubre de 2026.
Mantener controles de aprobación que dos tokens robados no puedan superar. La aprobación de versiones debería depender de identidades y dispositivos que un token de CI no pueda suplantar, y relajar una regla debería desencadenar una revisión.
Proteger los secretos de CI. Priorice el acceso de corta duración a la nube frente a las claves almacenadas, restrinja quién puede subir flujos de trabajo y configure alertas ante nuevos archivos de flujo de trabajo en ramas nuevas, también en repositorios privados.
Tratar los equipos de desarrollo y las configuraciones de herramientas de IA como almacenes de secretos. Haga inventario de lo que hay en archivos dotenv, directorios SSH y sesiones de asistentes de IA, y rote desde un equipo limpio tras un compromiso.
Rotar por completo, no a medias. Mantenga un inventario de cada token de administrador y clave de la nube, para que una rotación tras un incidente los cubra todos.

Si las claves de API, los tokens y las credenciales de servicio siguen en archivos de configuración e hilos de chat, reunirlos en un solo lugar es el primer paso para revocarlos según lo previsto. Passwork los guarda en bóvedas encriptadas con acceso basado en roles y un registro de actividad, para que usted vea quién accede a cada secreto y lo rote en un único lugar. Probar Passwork gratis.

Ataque a la cadena de suministro de LiteLLM, brecha de seguridad de Zeabur, Gheist: Credenciales no revocadas