LiteLLM Says Master Key Left Unrevoked Since May Led to Malware Release on PyPI and Docker

LiteLLM, the open-source AI gateway downloaded roughly 23 million times a week, has published its explanation of how attackers hijacked its release pipeline. The company says the trail starts with a mistake made almost five months before the attack.

On May 27, 2026, a configuration file was committed to the public LiteLLM-Labs/lite-harness repository on GitHub. It contained the master key to a deployment of the LiteLLM Agent Platform, a tool the company uses to orchestrate agents. LiteLLM engineers Oliver Jensen and Mateo Wang wrote that the error was caught, the commit was force-pushed over, and the exposed keys were flagged for revocation. "However, key revocation did not occur for the master key," they said.

How the attack unfolded

According to LiteLLM, an unknown attacker operating from the IP address 69.48.229[.]143 used that key on October 10 to get into the Agent Platform. From there the attacker pulled a GitHub CLI OAuth token the service used to file pull requests for self-hosted cloud agents.

That token was "not scoped down" and was tied to the account of the GitHub organization's owner. It gave the attacker owner-level access to every repository in the organization.

Security firm Socket recovered two malicious commits that each added a workflow file at .github/workflows/cache.yml. The first was made October 10 at 10:11:45 p.m. UTC, the second on October 12. Neither sits on a branch that still exists. Socket says the workflows ran for 11 days before the release and targeted 20 secrets, including GitHub, cloud and AI credentials.

The release itself came October 21. LiteLLM normally requires an authorized engineer to start a release and a special account locked to a physical device in its office to approve it. The company says that rule was relaxed earlier in the week to allow more frequent releases and bugfix backports, so any two engineers could trigger and approve one.

The attacker used stolen tokens from three engineers. According to LiteLLM, one account overrode branch protection and changed the release workflow, one approved the production gate, and one deleted workflow records. The build pulled code from Berri-AI/litellm, a hyphenated lookalike of the real BerriAI repository.

LiteLLM added that the attacker, already holding an owner's token, could have loosened or removed the approval rule alone. The company suspects that was not done to avoid detection.

What the poisoned release did

Seven wheels of litellm 1.107.0 reached PyPI at 11:39 UTC on October 21, according to SOCRadar's timeline. PyPI quarantined the version around 13:20 UTC and removed it by 13:23. Malicious Docker images went up at about 11:46 UTC under the v1.107.0, latest, main-latest and main-stable tags. The litellm-database and litellm-non_root variants on GHCR were hit too. GHCR images came down at 13:51 UTC and Docker Hub's at 14:20. The official v1.107.0 source tag on GitHub does not contain the malicious files.

Aikido, a security firm, found that files in the package ran automatically every time Python started, even if an application never imported LiteLLM. The payload was a stealer that collected cloud, Kubernetes, SSH, AI tool and browser secrets, plus LiteLLM proxy credential tables. It also reached for CI/CD secrets tied to systems like GitLab and Jenkins. On Linux and macOS, a second component polled GitHub hourly for remote code to run.

"A compromised LiteLLM gateway provides a strong foothold to hackers and could expose far more than AI API keys," said Keith Prabhu, CEO of Confidis.

The damage did not stop at theft. Wiz observed the attacker validating stolen AWS instance role credentials about 4.5 hours after exfiltration, then listing Amazon Bedrock models and enumerating IAM permissions. Wiz called that consistent with LLMjacking, where stolen credentials are used to run someone else's AI workloads.

Two accounts of the entry point

LiteLLM's first incident report, as relayed by CSO Online, said the attackers may have obtained GitHub credentials from logs of an internet-facing internal LiteLLM deployment. It said Claude Code could, in some circumstances, expose GitHub authentication tokens in responses that LiteLLM then recorded. At that point, how the attackers first reached the deployment was unknown.

Aviatrix, a cloud security vendor, has built its analysis around that logging angle. It argues that AI coding assistants writing OAuth tokens into gateway logs create a new credential-leak surface.

LiteLLM's Friday findings, published October 23, put the initial access on the unrevoked master key instead.

What users are told to do

LiteLLM says the incident is contained and that customers on its private enterprise registry were unaffected. Only version 1.107.0 is affected on PyPI. Users who ran an unpinned install between 11:39 and 13:23 UTC, or who ran the listed images before their removal, are told to assume compromise. Removing the package is not enough. Credentials on those hosts have to be rotated, and maintainers advise pinning to version 1.106.2.

This is the project's second supply chain compromise this year. A March 2026 incident, in which the group TeamPCP abused a compromised Trivy scanner to publish versions 1.82.7 and 1.82.8, followed a different path.

The lapses in the May-to-October chain are LiteLLM's own, as it describes them: a leaked key never revoked, a GitHub token with owner-level reach, and a two-person release approval that stood in for the hardware-locked one.

LiteLLM says it is now revoking every token tied to every internal system and vendor platform. It is not yet known how much of what was taken can still be used. As of October 22, SOCRadar reported the remote code loader appeared dormant because its GitHub dead drop file held no live domain. Wiz has already seen stolen keys tested, which leaves any organization that ran 1.107.0 racing to rotate secrets before an attacker uses them.