As reported by The Hacker News, LiteLLM version 1.107.0 was compromised in a software supply chain attack that deployed a credential stealer ("privcollect") and a persistent backdoor daemon via Python .pth files. This marks the second compromise of the LiteLLM project in 2026, following the TeamPCP campaign in March — a pattern that demands serious conversation about the security maturity of AI-adjacent open-source tooling.

Threat Alert: As reported by The Hacker News, LiteLLM version 1.107.0 was compromised in a software supply chain attack that deployed a credential stealer ("privcollect") and a persistent backdoor daemon via Python .pth files.

What Makes This Incident Significant

The threat actor reportedly obtained stolen GitHub CLI OAuth tokens from three engineer accounts, using one to trigger a release and another to approve it. This is a stark reminder that developer identity is the new perimeter in supply chain security. The attack didn't require a zero-day or a sophisticated exploit — it required credential theft from maintainers with publish-level access.

What's particularly concerning is the payload design:

What Makes This Incident Significant
privcollect — a credential stealer targeting cloud credentials, private keys, browser data, and AI development tool authentication files
Backdoor daemon — a background process that polls a GitHub dead drop hourly and executes arbitrary Python served by the attacker
Pre-import execution — the cook.pth file executes before LiteLLM is even imported, meaning merely having the package installed triggers the payload
The targeting of AI development tool credentials is notable. Attackers are increasingly recognizing that AI engineering environments aggregate high-value secrets — API keys, model provider tokens, training data access — in ways traditional dev environments do not.

Who Is Affected

Any organization that pulled LiteLLM 1.107.0 from PyPI or Docker between the malicious release and the quarantine is potentially impacted. The affected wheels span macOS, Linux (glibc and musl), and Windows — meaning virtually all deployment targets were covered.

Most exposed are:

  • AI/ML engineering teams using LiteLLM as an LLM proxy or gateway
  • Cloud-native environments running LiteLLM Docker containers
  • Organizations with automated CI/CD pipelines that pull latest package versions
  • Any environment where LiteLLM was installed alongside cloud provider credentials

The Bigger Pattern

This is the second LiteLLM compromise this year. The March TeamPCP attack also used .pth files for pre-import execution. The recurrence suggests either the same threat actor or a copycat exploiting the same unpatched project governance gaps. The fact that stolen OAuth tokens were sufficient to publish a malicious release — and get it approved — indicates that LiteLLM's release pipeline lacked the kind of multi-factor, hardware-backed verification that mature supply chains require.

Shield53 Recommendations

Immediate Actions

  • Audit package installations — Search all environments for LiteLLM 1.107.0 specifically. Check pip show litellm and Docker image digests against the affected wheel list
  • Rotate all credentials — If 1.107.0 was installed anywhere, rotate cloud provider credentials, SSH keys, browser-stored credentials, and any AI/ML service API keys that may have been accessible from the affected host
  • Hunt for indicators — Search for cook.pth files in Python site-packages directories and investigate any unknown background processes polling GitHub repositories on an hourly schedule
  • Pin versions — Downgrade to a known-good LiteLLM version (pre-1.107.0) or wait for a verified clean release. Use hash-pinned dependencies in requirements files

Strategic Hardening

  • Adopt Sigstore verification — Require signed artifacts via Sigstore/cosign for all package installations to detect tampering
  • Implement OAuth token rotation — Enforce short-lived, scoped GitHub tokens with mandatory refresh cycles for all maintainer accounts
  • Separate publish and approve roles — Require out-of-band verification for releases, not just a second GitHub account approval
  • Scan dependencies continuously — Deploy tools like Socket or SafeDep in CI/CD to detect behavioral anomalies in packages before they reach production
  • Isolate AI dev environments — Run AI tooling in containers with minimal credential access. Don't co-locate cloud provider credentials with LLM proxy tools
The AI ecosystem's rapid adoption of open-source tooling has outpaced its security governance. Until AI infrastructure projects adopt the supply chain hardening standards that the broader open-source community has been pushing for years, we should expect more of these incidents — not fewer.