🛡 MALWARE 🛡

Filtrada la clave maestra de LiteLLM que permite a atacantes robar tokens de GitHub y secuestrar la canalización de lanzamientos.

⏰25 de octubre de 2026🛡CyberObservatorio

Idioma

◢ MALWARE ◣

Filtrada la clave maestra de LiteLLM que permite a atacantes robar tokens de GitHub y secuestrar la canalización de lanzamientos.

⟫ 24/10/2026 ⟫ info@thehackernews.com (The Hacker News)

Fuente: The Hacker News

LiteLLM reveló el pasado viernes que una clave maestra de la plataforma Agent Platform fue publicada accidentalmente en un repositorio público de GitHub a finales de mayo de 2026, lo que permitió a un atacante llevar a cabo la inyección de una versión maliciosa de un popular paquete de Python. Según explicaron Oliver Jensen y Mateo Wang de LiteLLM, el 27 de mayo de 2026 se comprometió un archivo de configuración en el repositorio público LiteLLM-Labs/lite-harness, el cual contenía inadvertidamente la clave maestra de una implementación de la plataforma Agent Platform, una herramienta de código abierto utilizada para orquestar agentes.

El error fue rápidamente identificado, y se realizó un "force push" para eliminar el commit, reconociendo que las claves expuestas requerían ser revocadas. Sin embargo, la revocación de la clave maestra no se llevó a cabo. Este lapsus permitió que un atacante no identificado, que operaba desde la dirección IP "69.48.229[.]143", utilizara la clave no revocada el 10 de octubre de 2026. Con esta clave, el atacante pudo acceder a la plataforma Agent y extraer un token OAuth de GitHub CLI que el servicio tenía configurado para permitir que agentes en la nube autoalojados pudieran realizar solicitudes de extracción a los repositorios de GitHub.

De acuerdo con los desarrolladores de este modelo de lenguaje de código abierto, el token no estaba limitado a un ámbito específico y estaba asociado a la cuenta del propietario de la organización en GitHub. El acceso al token otorgó al atacante privilegios a nivel de propietario en todos los repositorios de la organización, lo que le permitió llevar a cabo una exfiltración adicional de credenciales. Las acciones sucesivas realizadas por el actor de amenazas tras este acceso se desarrollaron de la siguiente manera:

El 10 de octubre de 2026, entre las 22:11 y las 22:12 UTC, el autor realizó commits en ramas efímeras de repositorios internos para ejecutar flujos de trabajo (BerriAI/litellm y BerriAI/litellm-auto) diseñados para adquirir tokens OAuth de GitHub CLI asociados a dos ingenieros con privilegios de mantenimiento a través de un endpoint de webhook controlado por el atacante. Ambas ejecuciones fueron eliminadas minutos después. Posteriormente, el 21 de octubre de 2026, entre las 10:08 y las 11:08 UTC, se sobrepasaron las protecciones de ramas y se alteró el pipeline de lanzamiento, apuntando la fuente al repositorio similar "Berri-AI/litellm" en lugar de "BerriAI/litellm".

A las 11:39 y 11:40 UTC del mismo día, se publicó la versión 1.107.0 de LiteLLM en PyPI, y a las 11:46 UTC se publicaron imágenes en Docker Hub y GHCR. Más tarde, entre las 11:53 y las 11:54 UTC, los registros de ejecución de producción y staging fueron eliminados, y a las 12:06 UTC, un investigador de Upwind, Lidor Machluf, reportó el ataque a la cadena de suministro. Finalmente, a las 13:23 UTC, PyPI puso en cuarentena la versión 1.107.0 de LiteLLM, y a las 14:20 UTC, las etiquetas de Docker Hub v1.107.0, latest, main-latest y main-stable fueron eliminadas o redirigidas a imágenes verificadas y limpias.

LiteLLM explicó que, en condiciones normales, la creación y publicación de un lanzamiento requiere la autorización de un ingeniero autorizado y la aprobación de una cuenta especial bloqueada a un dispositivo físico en sus oficinas. Sin embargo, esta restricción fue relajada a principios de esa semana para facilitar un lanzamiento más frecuente de correcciones de errores, permitiendo que cualquier par de ingenieros pudieran desencadenar y aprobar un lanzamiento. Esto permitió al atacante utilizar uno de los tokens para iniciar el lanzamiento (tras haber redirigido al desplegador hacia su repositorio malicioso) y otro para aprobarlo.

Además, los mantenedores del proyecto señalaron que el atacante podría haber relajado aún más esta restricción o eliminarla por completo, dado que ya poseía un token perteneciente a un propietario de la organización. Se sospecha que esta acción no se tomó para evitar la detección. LiteLLM también indicó que los flujos de trabajo están diseñados para identificar y exfiltrar claves y tokens adicionales, centrándose específicamente en los tokens de API de inferencia ascendentes. En respuesta a este incidente, la empresa afirmó que está trabajando para revocar cada uno de los tokens asociados a todos los sistemas internos y plataformas de proveedores.

Socket, que publicó su propia investigación sobre los flujos de trabajo maliciosos, recuperó dos commits maliciosos que añadieron cada uno un flujo de trabajo en ".github/workflows/cache.yml". El primer commit se realizó el 10 de octubre de 2026 a las 22:11:45 UTC, seguido por un segundo commit el 12 de octubre. "Ninguno de los commits fue enviado a una rama que todavía exista", comentó Karlo Zanki, investigador de seguridad de Socket, en un informe compartido con The Hacker News. "Ambos fueron enviados a ramas de corta duración nombradas ci-tmp- que fueron creadas, utilizadas y eliminadas en minutos, razón por la cual la actividad deja casi nada en la historia ordinaria del repositorio".

De acuerdo con el análisis de la firma de seguridad de aplicaciones sobre los registros de actividad del repositorio, ambos commits se basan en un commit legítimo como base de la rama para hacer que el push parezca inofensivo. Se crea una rama desechable llamada "ci-tmp-" (específicamente, ci-tmp-a351cc y ci-tmp-4d8517) a partir de un commit legítimo reciente en el repositorio y se empuja un commit que añade ".github/workflows/cache.yml" con el mismo asunto, "ci: bump cache config". Este flujo de trabajo está configurado para ejecutarse cada vez que se envía un commit o etiqueta, lo que provoca que se active.

Ambos flujos de trabajo, tal como lo destacó LiteLLM, están equipados para recoger tokens de GitHub y claves API para el espacio de trabajo Linear de la organización, la implementación de LiteLLM y Together AI, así como el identificador y la clave de firma de una aplicación de GitHub. La ejecución del 12 de octubre amplía la recolección a más secretos, incluidos las claves API de Anthropic, OpenAI, AWS Bedrock, Tavily y el inquilino de escaneo de secretos de GitGuardian. También captura el estado de almacenamiento de Playwright, información de bases de datos PostgreSQL (cadena de conexión, nombre de cuenta, contraseña), dirección de endpoint de Redis, puerto y contraseña de autenticación.

Los datos recopilados a partir de ambos flujos de trabajo son exfiltrados a dos diferentes endpoints de webhook[.]site:

- webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37 - webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1

Un token de GitHub y una clave privada de aplicación de GitHub son credenciales específicas para la plataforma que alberga el repositorio, y no para un servicio de terceros, afirmó Zanki. Por otra parte, el identificador GITGUARDIAN_API_KEY se refiere a una credencial de la propia plataforma de escaneo de secretos, lo que otorga a un atacante visibilidad y, potencialmente, control sobre las alertas generadas por esta actividad.

El parámetro E2E_LINEAR_STORAGE_STATE_B64 representa el estado de la sesión del navegador serializado, utilizado por Playwright para realizar pruebas de extremo a extremo. Un estado de almacenamiento válido permite acceso autenticado a la cuenta asociada de Linear sin necesidad de contraseña y eludiendo los requerimientos de autenticación multifactor.

Los hallazgos descartan la hipótesis inicial de LiteLLM, que sostenía que los tokens OAuth de la interfaz de línea de comandos de GitHub fueron sustraídos de los registros de una implementación interna de LiteLLM. "La investigación fue un proceso en el que continuamente aprendimos información adicional, lo que significó que algunas de nuestras suposiciones y creencias resultaron ser inexactas o incompletas", reconoció Jensen.

Múltiples informes han revelado que los archivos incluidos en la versión 1.107.0 de LiteLLM están diseñados para ejecutarse automáticamente al iniciar Python, incluso si una aplicación no había importado explícitamente LiteLLM.

El malware presenta dos rutas de ejecución: un módulo destinado a la recolección de credenciales que apunta a material de autenticación a través de herramientas de desarrollo, aplicaciones de inteligencia artificial, entornos en la nube y navegadores web; y un backdoor orientado a Unix que se ejecuta como un proceso en segundo plano para descargar y ejecutar código arbitrario proporcionado por el atacante cada hora.

Además, el ladrón de datos recopila información del sistema, archivos SSH, credenciales y tokens de Git y GitLab, variables de entorno, así como tokens asociados a npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems y Cargo. Esta información es luego comprimida y enviada a "litellm[.]dev/healthcheck" mediante una solicitud HTTP POST. Cabe destacar que el dominio fue registrado el 13 de octubre de 2026, lo que puede implicar un uso malicioso a largo plazo.

"Juntos, estos mecanismos ampliaron la posible exposición más allá de las implementaciones activas de LiteLLM: simplemente iniciar Python en un entorno afectado podría activar el código malicioso, incluso cuando LiteLLM en sí nunca había sido importado", indicó el equipo de Microsoft Security Research.

"Debido a que los archivos de inicio se encontraban fuera del directorio de la aplicación LiteLLM, eliminar únicamente los archivos de la aplicación podría dejar atrás los componentes maliciosos de inicio", concluyeron los investigadores. Este aspecto resalta la importancia de una gestión adecuada de las dependencias y la implementación de medidas de seguridad robustas para mitigar el riesgo de infecciones por malware.

◢ MALWARE ◣

Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline

⟫ 24/10/2026 ⟫ info@thehackernews.com (The Hacker News)

Source: The Hacker News

LiteLLM on Friday revealed that an Agent Platform master key accidentally published to a public GitHub repository in late May 2026 ultimately allowed the threat actor topush a malicious versionof the popular Python package. "On May 27, 2026, a configuration file wascommittedto the public LiteLLM-Labs/lite-harness repository which inadvertently contained the master key to a deployment of the LiteLLM Agent Platform, an open source tool we use for orchestrating agents," LiteLLM's Oliver Jensen and Mateo Wangsaid. "The error was quickly identified, the commit force-pushed over, and we identified the exposed keys as requiring revocation. However, key revocation did not occur for the master key." LiteLLM said the unknown attacker (operating from "69.48.229[.]143") used this unrevoked key on October 10, 2026, to gain access to the Agent Platform and extracted a GitHub CLI OAuth token the service was configured with to allow self-hosted cloud agents to file pull requests to GitHub repositories. The token, per the developers of the open-source large language model (LLM) gateway, was "not scoped down" and associated with its GitHub organization owner's account. Gaining access to the token allowed the attacker to possess owner-level access to all repositories across the organization and perform additional credential exfiltration. The sequence of actions performed by the threat actor following this step is as follows - October 10, 2026, between 10:11 and 10:12 p.m. UTC: Author commits into throwaway branches on internal repositories to run workflows (BerriAI/litellm and BerriAI/litellm-auto) designed to acquire GitHub CLI Oauth tokens associated with two engineers with maintainer privileges via an attacker-controlled webhook[.]site endpoint. The two runs are deleted minutes later. October 21, 2026, between 10:08 and 11:08 a.m. UTC: Override branch protection and alter the release pipeline with the source set to the lookalike repository "Berri-AI/litellm" rather than "BerriAI/litellm." October 21, 2026, between 11:39 and 11:40 a.m. UTC: LiteLLM version 1.107.0 gets published to PyPI on October 21, 2026, 11:46 a.m. UTC: Docker Hub and GHCR images are published. October 21, 2026, between 11:53 and 11:54 a.m. UTC: Production and staging run records are deleted. October 21, 2026, 12:06 p.m. UTC: Supply chain attack reported by Upwind researcher Lidor Machluf. October 21, 2026, 1:23 p.m. UTC: PyPI quarantines LiteLLM version 1.107.0. October 21, 2025, 2:20 p.m. UTC: Docker Hub tags v1.107.0, latest, main-latest, and main-stable are removed or repointed to verified clean images. "In typical operation, building and publishing a release requires being kicked off by an authorized engineer and being approved by a special account locked to a physical device in our office," LiteLLM said. "This restriction was relaxed earlier this week to accommodate the temporary push for more frequent releases and bugfix backports, allowing any two engineers to trigger and approve a release. As such, the threat actor used one of the tokens to trigger the release (after having repointed the deployer to their malicious repository), and another to approve it." In addition, the project maintainers noted that the threat actor could have very well loosened this restriction (or removed it entirely) themselves given that they were already in possession of a token belonging to an organization owner. It's suspected that this was not done to evade detection. LiteLLM also said the workflows are designed to identify and exfiltrate additional keys and tokens, specifically focusing on upstream inference API tokens. In response to the incident, the company said it's working to revoke each and every token associated with every internal system and vendor platform. Socket, whichpublishedits own investigation into the malicious workflows, said it recovered two malicious commits that each added a workflow at ".github/workflows/cache.yml." The first commit was made on October 10, 2026, at 10:11:45 p.m. UTC. It was followed by a second commit on October 12. "Neither commit was pushed to a branch that still exists," Socket security researcher Karlo Zanki said in a report shared with The Hacker News. "Both were pushed to short-lived branches named ci-tmp- that were created, used, and deleted within minutes, which is why the activity leaves almost nothing behind in the repository's ordinary history." According to the application security firm's analysis of the repository's activity log records, both commits rely on a legitimate commit as the branch base to make the push look seemingly harmless - Create a throwaway branch named "ci-tmp-" (namely, ci-tmp-a351cc and ci-tmp-4d8517) from a recent legitimate commit on the repository. Push a commit adding ".github/workflows/cache.yml" with the same subject, "ci: bump cache config." The workflow is configured to be run every time a commit or tag is pushed (i.e., "on: [push]"), causing it to be triggered. Both workflows, as highlighted by LiteLLM, are equipped to harvest GitHub tokens and API keys for the organization's Linear workspace, LiteLLM deployment, and Together AI, along with the identifier and signing key of a GitHub App. The October 12 run extends the collection to more secrets, including API keys for Anthropic, OpenAI, AWS Bedrock, Tavily, and GitGuardian's secret-scanning tenant. It also captures Playwright storage state, PostgreSQL database information (connection string, account name, password), Redis endpoint address, port, and authentication password. The data gathered from the two workflows is exfiltrated to two different webhook[.]site endpoints - webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37 webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1 "A GitHub token and a GitHub App private key are credentials for the platform hosting the repository, not for a third-party service," Zanki said. "GITGUARDIAN_API_KEY is a credential for the secret-scanning platform itself, which gives an attacker visibility into, and potentially control over, the alerts that would surface this activity. "E2E_LINEAR_STORAGE_STATE_B64 is serialized browser session state used by Playwright for end-to-end tests; a valid storage state permits authenticated access to the associated Linear account without a password and without satisfying multi-factor authentication." The findings rule out LiteLLM's initial hypothesis that the GitHub CLI OAuth tokens were stolen from the logs of an internal LiteLLM deployment. "The investigation was a process in which we continually learned additional information, meaning some of our assumptions and beliefs were later proven to be inaccurate or incomplete," Jensenacknowledged. Multiple reports haverevealedthat the files bundled with LiteLLM version 1.107.0 are engineered to execute automatically when Python starts, even if an application did not import LiteLLM. The malware featurestwo execution paths: a credential harvesting module that targets authentication material across developer tools, AI applications, cloud environments, and web browsers, and a Unix-oriented backdoor that's launched as a background process to fetch and execute arbitrary code supplied by the attacker every one hour. The stealer also collects system information, SSH files, Git and GitLab credentials and tokens, environment variables, and tokens associated with npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems, and Cargo. The data is then compressed and sent to "litellm[.]dev/healthcheck" using an HTTP POST request. The domain was registered on October 13, 2026. "Together, these mechanisms extended potential exposure beyond active LiteLLM deployments: simply starting Python in an affected environment could activate the malicious code, even when LiteLLM itself was never imported," the Microsoft Security Research teamsaid. "Because the startup files resided outside the LiteLLM application directory, removing only the application files could leave the malicious startup components behind."

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD