LiteLLM 1.107.0 Malicious Release: Leaked Key to PyPI

LiteLLM 1.107.0 was a malicious release published to PyPI, Docker Hub and GHCR on October 21, 2026, after an attacker used a leaked, never-revoked LiteLLM Agent Platform master key to steal a GitHub OAuth token with organization-owner access. With it, the attacker overrode branch protection, repointed the release pipeline to a lookalike repository and shipped the release. If you installed 1.107.0, remove it and rotate every credential the host could reach.

LiteLLM is a popular open-source LLM gateway and Python package that teams use to route calls to many model providers, which means it usually sits next to a lot of provider API keys. In its postmortem, reported by The Hacker News, LiteLLM said a configuration file committed to the public LiteLLM-Labs/lite-harness repository on May 27, 2026 contained the master key to a LiteLLM Agent Platform deployment. The team spotted it, force-pushed over the commit and flagged the exposed keys for revocation, but the master key itself was never revoked.

On October 10 the attacker used that key to access the Agent Platform and pull out a GitHub CLI OAuth token the service used to let cloud agents open pull requests. The token was not scoped down and belonged to the GitHub organization owner, giving owner-level access to every repository. Within minutes the attacker committed workflows to short-lived branches in BerriAI/litellm and BerriAI/litellm-auto that harvested GitHub tokens for two maintainers, sending them to a webhook.site endpoint, then deleted the runs. Application security firm Socket recovered two malicious commits that each added a .github/workflows/cache.yml file on branches named ci-tmp-<hex> that existed for only minutes.

How was the LiteLLM release pipeline hijacked?

Normally a LiteLLM release has to be started by an authorized engineer and approved by a special account locked to a physical device in the office. That week the rule had been relaxed so any two engineers could trigger and approve a release, to speed up bugfix backports. On October 21 the attacker overrode branch protection, changed the release source from BerriAI/litellm to the lookalike Berri-AI/litellm, then used one stolen maintainer token to trigger the release and the other to approve it. LiteLLM notes the attacker could have removed the restriction outright with the owner token, and suspects they did not in order to stay quiet. The malicious workflows were also built to find and exfiltrate more keys, focusing on upstream inference API tokens.

What happened when, and what should you do?

Check lockfiles, requirements files and image digests for LiteLLM 1.107.0 or any LiteLLM image pulled from the latest, main-latest or main-stable tags around October 21. If you find it, treat the host as compromised: rebuild it, and rotate every model provider key, cloud credential and token available to that environment, not only the ones LiteLLM itself used. Pin LiteLLM to a known-good version by hash going forward.

How do you stop a leaked key from becoming a supply chain attack?

Every step here is a familiar control that was slightly loose. A secret reached a public repository, and force-pushing removed it from the branch but not from anyone who had already copied it, so revocation is the only real fix. The OAuth token was owner-scoped when the job only needed to open pull requests. The release approval rule was relaxed for convenience. Short-lived branches running unreviewed workflows had access to secrets. Scanning commits for secrets before they merge, scoping automation tokens to the minimum, and restricting which branches can run privileged workflows each would have broken a link in this chain. GitHub's secure use reference for Actions covers token permissions and workflow triggers in detail. Our guides to finding hardcoded secrets and securing GitHub Actions pipelines walk through each control, and our software supply chain attack guide covers the wider pattern. ARGUS scans every commit for secrets and checks packages before install; see the agents behind an ARGUS scan.

Our read

The leak was caught within the hour and still led to a malicious release five months later, because "we removed it" and "we revoked it" were treated as the same thing. That gap is easy to miss and easy to verify. AI tooling makes it worse: agent platforms are wired up with broad tokens so agents can act on their own, and LiteLLM's token existed precisely so cloud agents could open pull requests. As more teams give agents write access to repositories, the token behind each agent becomes part of the release path and deserves the same scoping and review as a human maintainer's. Teams that depend on LiteLLM should also read our earlier coverage of the August LiteLLM PyPI compromise, a separate incident with a different root cause.

Reporting by The Hacker News, citing LiteLLM's postmortem and Socket's analysis; package registry guidance per PyPI and the OpenSSF.

Frequently asked questions

Is LiteLLM 1.107.0 malicious?
Yes. LiteLLM 1.107.0 was published by an attacker on October 21, 2026 through a hijacked release pipeline, and PyPI quarantined it about two hours later.

How did attackers compromise LiteLLM?
A LiteLLM Agent Platform master key leaked to a public GitHub repository in May 2026 and was never revoked. The attacker used it to steal an organization-owner GitHub OAuth token, then maintainer tokens, and repointed the release pipeline to a lookalike repository.

What should I do if I installed LiteLLM 1.107.0?
Remove it, rebuild the affected host or container, and rotate all model provider keys, cloud credentials and tokens the environment could access. Pin LiteLLM to a known-good version by hash.

Were LiteLLM Docker images affected?
Yes. Malicious images were pushed to Docker Hub and GHCR on October 21, and the v1.107.0, latest, main-latest and main-stable tags were later removed or repointed to clean images.

Is this the same as the August 2026 LiteLLM incident?
No. This October incident stems from a leaked Agent Platform master key; the August compromise had a different root cause.