Safeguard
AI Security•

LiteLLM PyPI compromise of March 2026: what the advisory says

Two litellm releases on PyPI carried credential-harvesting code in March 2026. The affected versions, what it collected and what the advisory says to do.

Safeguard Security Team
3 min read

Two releases of the litellm Python package, 1.82.7 and 1.82.8, were published to PyPI carrying credential-harvesting code in March 2026. The advisory says anyone who installed and ran them should assume credentials in that environment are exposed, then revoke and rotate them.

Facts from the advisory

The GitHub advisory GHSA-5mg7-485q-xm76 is rated critical and has no CVE. It lists affected versions as 1.82.7 and 1.82.8, with no patched version. It was published on 25 March 2026. The advisory attributes the malicious uploads to an API token exposure linked to an exploited Trivy dependency.

A related listing on the oss-security list says the code runs when any module in the package is imported, and that it looks for:

  • SSH keys, Git and Docker credentials and dotenv files.
  • Kubernetes service account tokens and database or directory configuration.
  • Shell history and wallet keys.
  • Cloud access tokens, by querying metadata servers, and secrets in a cloud secrets manager.

It sent what it found to a remote API, and set up a persistent service disguised as a telemetry service. In Kubernetes it also created a new pod. The listing names the exfiltration domain models.litellm[.]cloud.

Why a gateway library is a rich target

A library that sits between your application and several model providers tends to run where provider keys, cloud credentials and application secrets are all within reach. That makes the environment worth stealing from, regardless of who is behind it. The same is true of any proxy or gateway component you run next to production secrets.

What to do if you ran those versions

  1. Check lockfiles, images and caches for 1.82.7 and 1.82.8.
  2. Remove them and rebuild from a version you have verified.
  3. Rotate every secret the environment could read, including model provider keys.
  4. Look for the persistent service and unexpected pods, and review outbound network logs.
  5. Purge the versions from internal mirrors.

What to change for next time

  • Pin exact versions with hashes in your lockfile and install from it in CI.
  • Consider a short waiting period before adopting brand new releases, so reports can surface first.
  • Give gateway processes only the keys they need, and do not mount broad cloud credentials into them.
  • Keep a software inventory so you can answer "do we run this?" in minutes.

Safeguard's SBOM and dependency scanning lists direct and transitive packages per repository, which helps answer the inventory question quickly. You can try the free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a package version shows up in a full dependency list.

Quick check

Is there a CVE for this?

The advisory says no known CVE. It is tracked as GHSA-5mg7-485q-xm76 and PYSEC-2026-2.

Was 1.82.6 affected?

The advisory lists only 1.82.7 and 1.82.8 as affected.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.