Skip to main content
Emerging ThreatsSupply Chain Attacks

Exposed Master Key Sparks LiteLLM Supply Chain Attack

“On October 10th, the threat actor used this key to gain access to our LiteLLM Agent Platform and extracted this GitHub CLI OAuth token,” according to Friday’s postmortem.

How a committed master key opened the gate

LiteLLM traced last week’s supply chain compromise to a configuration file committed on May 27 to the public LiteLLM-Labs/lite-harness repository. The file contained a master key for an open source orchestration tool used internally to run AI agents. Developers noticed and removed the exposed commit quickly, but they did not revoke the key.

That lapse mattered. According to LiteLLM’s Friday postmortem, the exposed key was used on October 10 to access the LiteLLM Agent Platform and extract a GitHub CLI OAuth token. With that token in hand, the intruder obtained owner-level access to all repositories in LiteLLM’s GitHub organization.

Poisoned release on PyPI and a narrow, intense window of distribution

Someone uploaded a trojanized release of LiteLLM’s open source AI gateway — version 1.107.0 — to PyPI and to container registries last Wednesday. The compromised package contained an infostealer and a remote access trojan capable of executing arbitrary code on infected hosts. It remained on PyPI for less than two hours before quarantine, but it was downloaded about 49,000 times in that interval, according to Wiz.

How the GitHub CLI token multiplied access

The GitHub CLI tokens the attacker acquired are “post‑2fa,” the postmortem notes, meaning they do not trigger GitHub’s sudo-mode authentication flows that are typically required for high-impact repository actions. That allowed the actor to author malicious commits into branches on other internal repositories, including CI workflows designed to harvest tokens and secrets that are exposed during continuous integration.

The malicious commits were used to steal additional GitHub CLI OAuth tokens tied to two engineers with maintainer privileges, and to obtain tokens for several other internal systems. LiteLLM’s review of the actor’s activity on those systems “shows attempts to identify and exfiltrate additional keys and tokens, with a primary focus on upstream inference API tokens.” Because the changes and approvals appeared to come from legitimate, credentialed engineers, the attacker could make repository changes without immediately raising suspicion.

What the trojanized package stole — and what users should assume

Inside the compromised package, the infostealers were configured to harvest a broad set of credentials and secrets. LiteLLM listed the following items as targeted for exfiltration:

  • Browser credentials and cookies from Chrome, Firefox, Edge, and Safari
  • AWS credentials
  • Google Cloud Platform service account keys and application default credentials
  • Microsoft Azure tokens
  • API keys for OpenAI, Anthropic, Cohere, and other LLM providers

LiteLLM’s guidance is blunt: if you installed and ran version 1.107.0, assume any credentials accessible to the affected system may have been stolen. Investigate affected systems, change passwords, and rotate exposed keys.

What this means for LiteLLM engineers, vendor partners, and end users

  • LiteLLM engineers: The company is revoking every token associated with every internal system and vendor platform and reviewing access flows; the postmortem frames this incident as “a strong illustration of the risks associated with failing to rotate a potentially exposed key.”
  • Vendor partners and CI/CD operators: Workflows and granted CI secrets became a harvest target; any CI systems that consume repository tokens or provide upstream API credentials need audit and credential rotation.
  • End users and developers who pulled 1.107.0: Treat systems as compromised until proven otherwise — rotate keys and credentials for cloud providers and LLM APIs, and inspect build and deployment pipelines for unauthorized workflows or credential exposures.

The record in LiteLLM’s postmortem is a compact cautionary tale: a single committed configuration file, a forgotten master key and a GitHub CLI token that bypasses additional interactive authentication combined to convert a brief window of malicious distribution into a far larger sea of exposed secrets. LiteLLM’s next steps are sweeping credential revocation and investigation; the remaining question is whether downstream consumers and vendors who used the compromised artifacts have completed the same rotations and audits.

Original story