LiteLLM 1.107.0 Supply Chain Attack Explained

A compromised LiteLLM 1.107.0 release put credential-stealing code into official Python wheels and container images on October 21, 2026. This LiteLLM supply chain attack was not confined to applications that imported LiteLLM: in an affected environment, an ordinary Python start could trigger the payload. LiteLLM's incident notice dates PyPI exposure to roughly 11:39–13:23 UTC. This account reflects the evidence available as of Oct 2026.

Key Takeaways:

• The seven malicious 1.107.0 wheels reached PyPI for about two hours; affected Docker tags had a different exposure window.
• LiteLLM's final root cause analysis traces the release to an Agent Platform key exposed in May and never revoked.
• Python startup hooks could run the collector without a LiteLLM import. Deleting the application folder does not clean the environment.
• If an affected artifact ran, isolate it from a known-clean system, rebuild and rotate every credential the host could reach.

What happened to LiteLLM 1.107.0?

LiteLLM's authorized release pipeline signed and published an unauthorized build. Its canonical root cause analysis dates seven litellm==1.107.0 wheels to 11:39:51–11:40:13 UTC; PyPI quarantined them by 13:23. Container images followed at 11:46:56. The incident notice names compromised v1.107.0, latest, main-latest and main-stable tags. GHCR tags became unavailable by 13:51; Docker Hub tags were removed or repointed by 14:20. Today's floating tag cannot identify yesterday's pulled digest.

How did an unrevoked key become a signed release?

On May 27, public repository LiteLLM-Labs/lite-harness exposed an experimental LiteLLM Agent Platform master key in opencode.json. The team flagged but never revoked it. On October 10, the platform returned a GitHub CLI OAuth token tied to an organization owner. LiteLLM's final RCA supersedes its earlier theory that the first token came from internal proxy logs.

The owner access enabled secret-stealing CI workflows. A second maintainer's token later approved the production gate; a third deleted release-run records. On October 21, an owner-token override defeated branch protection on the private releaser. The pipeline then built from Berri-AI/litellm, a hyphenated lookalike of the real BerriAI/litellm, and signed the poisoned artifacts. The distinction is the source repository, not a claim that signatures were forged.

Socket recovered October 10 and 12 malicious workflows. The second referenced 14 further secret names, including GitGuardian and AWS Bedrock credentials. Workflow success alone cannot prove delivery; LiteLLM's audit logs link the earlier stolen maintainer token to production approval.

What did the malicious wheels do at Python startup?

Microsoft Security Research found cook.pth, cook.py and sitecustomize.py in the affected wheels. They landed in the environment's library path outside the ordinary litellm directory. Python's normal startup processing could activate the first path, which launched a collector identifying itself as PRIVCOLLECT. No import litellm was required. The collector was designed to read accessible cloud, source-control, browser, AI-tool and LiteLLM proxy credentials, then encrypt and send collected material out.

A separate Unix-oriented loader could retrieve additional code on an hourly cycle. Microsoft found no confirmed second-stage retrieval or execution when it investigated. JFrog's artifact comparison found the three malicious files in all seven wheels, but not in the published source archive; checking only a Git tag or deleting only the application directory would miss that difference.

Am I affected, and what should I rotate?

Check deployment records and inventories from a known-clean environment. The PyPI window ended at 13:23 UTC on October 21; Docker exposure began at 11:46. Verify the pulled digest, not today's floating tag. If an affected artifact ran, assume its reachable credentials were exposed. Don't launch pip or Python inside a suspect environment: startup can retrigger the collector.

Defensive response checklist:

• Isolate affected workstations, CI workers, proxy hosts and containers; preserve relevant package, registry and access logs.
• Have responders inspect from a trusted system, stop surviving processes safely and rebuild from verified clean artifacts. Removing a package is insufficient.
• Revoke sessions and rotate every reachable secret from a clean machine: model-provider and proxy keys, DATABASE_URL, cloud and workload identities, registry and GitHub tokens, CI secrets, SSH keys and browser sessions.
• Review downstream activity with your security team; absence of a marker file does not establish that collection failed.

These boundaries come from the LiteLLM response guidance and Microsoft's analysis, not a claim that every targeted credential was actually stolen.

Why is this an AI-agent supply-chain problem?

The forgotten key belonged to an experimental platform for agents filing GitHub pull requests; it held a human owner's broad credential. A poisoned gateway could also reach model-provider keys and AI-tool authentication on affected machines. The issue is concentrated authority.

LiteLLM's first notice also observed cases where Claude Code put a GitHub CLI OAuth token into a response body that proxy logging could capture. Its final RCA does not identify those logs as the entry point for the owner's token. Keep that distinction; it is still a reason to keep secrets out of logged model responses. A solo operator may not run CI, but can ask the same question before granting an assistant access to a client folder: does the tool actually need that account? Our agent-governance guide addresses the permission side; our OpenShell explainer examines runtime boundaries.

Zentor's user-owned workspace memory can reach different AI tools through Zentor MCP; that is a portability proposition, not a LiteLLM integration or a guarantee against compromised dependencies. Zentor's self-adaptive workspace helps organize tasks, but release provenance and credential isolation must come from the systems controlling those actions. For an account-access example outside software delivery, see why banks restrict AI agents.

How can teams harden agent and LLM dependency pipelines?

This LiteLLM supply chain attack suggests a defensive checklist: revoke exposed keys promptly and verify revocation; inventory tokens held by agent services; give automation purpose-limited identities instead of owner sessions. Protect release-source changes against owner-only overrides and review temporary approval exceptions. Verify built artifacts and container digests, not just tags: StepSecurity documents the clean Git tag and poisoned wheels. Zentor can carry user-owned working context between assistants; supplier and account decisions remain with the team.

FAQ: LiteLLM 1.107.0 and recovery

Is LiteLLM safe to use now?

The affected releases were removed, according to LiteLLM. That does not establish the safety of an older install or every later artifact. Review the maintained incident guidance and verify the exact release and digest before redeploying.

Which versions were affected?

LiteLLM names all seven PyPI wheels for 1.107.0 and the listed container tags while they pointed to compromised images. It said previous versions and its private enterprise registry were not affected by this release incident; check its dated notice for scope.

What is the lookalike repo?

Berri-AI/litellm (with a hyphen) was the attacker-controlled release source. BerriAI/litellm is the legitimate project. A signed artifact still requires a trustworthy source.

Should I reinstall from a clean machine?

Yes, if you used an affected artifact: isolate the environment, have qualified responders rebuild from verified sources and rotate reachable credentials from a clean machine. Reinstallation alone cannot revoke a copied token.