LiteLLM 1.107.0 Compromised: What to Check Before Starting Python

TL;DR

LiteLLM says its release pipeline was compromised on October 21, 2026, distributing malicious version 1.107.0 through PyPI and public container registries. Datadog describes LiteLLM as a Python proxy library for LLM providers with about 23 million weekly downloads. That is a download estimate, not a count of affected users. [S1, S3]

The payload planted Python startup hooks. Starting Python in an affected environment could execute malware without importing LiteLLM. Microsoft explicitly advises investigators not to start Python or pip inside a suspect environment. An unused cached wheel warrants investigation, but its presence alone does not establish that malware executed. [S3, S4]

Start by isolating suspect systems and investigating from a known-clean system. Inventory installed environments and retained artifacts, rebuild affected environments, and rotate reachable credentials from a clean machine. The checklist below separates read-only inspection from recovery actions. [S4]

What happened: the attack chain

LiteLLM's October 23 retrospective is its canonical account. Its initial October 21 post was updated October 23 to acknowledge that early assumptions were inaccurate or incomplete. Microsoft separately says it has not independently determined how the attacker first accessed the upstream environment. Keep those attributions distinct. [S1, S2, S4]

• May 27, 2026: LiteLLM says opencode.json in public repository LiteLLM-Labs/lite-harness exposed the master key of a LiteLLM Agent Platform deployment, an internal alpha tool for agents filing PRs. The commit was force-pushed over and keys identified for revocation, but the master key was not revoked. [S2]
• October 10: The attacker used that key against the Agent Platform API. GET /api/v1/managed_agents/agents?limit=100 returned a GitHub organization owner's GitHub CLI OAuth token. LiteLLM says this was not a scoped service account and that GitHub CLI tokens are post-2FA and outside GitHub's super-user 2FA reauthentication flows. [S2]
• October 10 and 12: Throwaway-branch CI workflows sent repository secrets to a webhook.site endpoint, obtaining two more maintainers' GitHub CLI tokens stored as GH_TOKEN and RELEASE_PLEASE_TOKEN. Runs were deleted. More secrets were taken from private repositories October 12; LiteLLM describes those as minimally sensitive. [S2]
• October 21: The owner token overrode branch protection on the private release repository and redirected the release workflow to lookalike fork Berri-AI/litellm. Normally approval required a special account locked to a physical device. LiteLLM says that restriction had been relaxed earlier that week to allow any two engineers to trigger and approve releases. One stolen token triggered the release; another approved the production gate at 11:11:18 UTC. [S2]
• Later that day: A third token deleted run records at 11:53-11:54 UTC. History was force-pushed clean at 12:09-12:24 UTC. LidorMachluf opened issue #47826 at 12:06:41 UTC, identifying the compromise. These events overlap; they are not presented as a strictly sequential list. [S2, S5]

The official v1.107.0 git tag does not contain the malicious files, according to LiteLLM. The compromised artifacts came from an attacker-controlled repository. Inspecting that official tag alone therefore cannot establish that a downloaded wheel or image was clean. [S1]

Artifact windows: preserve the different accounts

All times below are UTC on October 21, 2026. LiteLLM and Datadog report different endpoint times and event descriptions. Do not combine them into one supposedly exact removal time. [S1, S3]

The affected tags were v1.107.0, latest, main-latest, and main-stable. LiteLLM identifies this compromised Docker Hub image-index digest: [S1]

sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e

As conservative triage advice, investigate pulls throughout the wider reported windows, then use retained artifacts and deployment records to determine exposure. A timestamp alone is not proof of execution or safety. Cached artifacts and internal mirrors also belong in the inventory. [S4]

What the payload did

Datadog identifies cook.pth, cook.py, and sitecustomize.py in site-packages. The startup-hook mechanism runs malware when Python starts in the affected environment, even without a LiteLLM import. This does not establish that every separate Python environment on the same host executes those hooks. Microsoft describes exposure across developer workstations, CI/CD agents, test environments and containers. [S3, S4]

Datadog says the stealer encrypted data with AES-256 and RSA-4096 and sent it to www.litellm[.]dev/healthcheck. Its targets included cloud credentials and instance metadata; Kubernetes, Docker, Vault and Terraform data; SSH/GPG/TLS keys; Git/npm/PyPI tokens; .env files and shell history; model-provider API keys; browser passwords and cookies; and provider credentials in the LiteLLM proxy database. It also targeted sessions for Claude, Codex, Gemini, Cursor, Copilot and other AI coding tools. Microsoft says the collector called itself PRIVCOLLECT. [S3, S4]

Datadog describes a backdoor checking the GitHub-hosted file letters9813/pythonclient-test/main/domain.txt hourly for a domain from which to download and run Python code. The file was subsequently removed. Datadog reports that it held only test values and that no second-stage payload was observed in the wild. Microsoft says remote retrieval and execution through this Unix-oriented loader were not confirmed, while describing a mechanism that could be re-armed. Neither account confirms second-stage execution against a real target. [S3, S4]

Deleting the LiteLLM package directory does not remove the planted files. Starting Python or pip can trigger them again. Microsoft's Windows example involved a routine Python invocation to install an unrelated dependency; the supplied evidence does not identify that invocation specifically as pip. [S3, S4]

Microsoft says the marker is written after an HTTP 200 upload, but its absence does not rule out exfiltration because processes can be short-lived and temporary files cleaned. The GitHub issue recommends assuming exfiltration succeeded if 1.107.0 was installed on an internet-connected host. That is incident-response guidance, not proof of an upload on every host. [S4, S5]

What to check: response checklist

Step 1: Isolate suspect systems and investigate from a known-clean system. Do not start Python, pip or uv run in suspect environments. Microsoft explicitly warns against Python and pip; avoiding other Python execution paths follows the same precaution. [S4]

Step 2: Inventory every copy. Include installed environments, pip and uv caches, internal mirrors, lock files, build outputs and container images. Distinguish installed artifacts from retained but unused copies. [S4]

Step 3: Inspect files without starting Python. The Bash examples below are read-only starting points. Run file searches against an offline evidence copy mounted read-only on a known-clean system, replacing the example path. For Docker, query a trusted daemon's local inventory. Do not execute suspect images. These are inspection examples, not vendor-published commands.

# Existing read-only evidence mount; assignment does not alter files.
evidence_root='/mnt/suspect'

# Startup files and compiled leftovers, without crossing mount boundaries.
find "$evidence_root" -xdev -type f \( \
  -name 'cook.pth' -o -name 'cook.py' -o \
  -name 'sitecustomize.py' -o -name 'cook*.pyc' -o \
  -name 'sitecustomize*.pyc' \) -print

# Broad text search: inspect matches for version 1.107.0 manually.
# This also finds lock formats that separate package name and version.
grep -rInI --include='requirements*.txt' --include='*.lock' \
  --include='pyproject.toml' -- 'litellm' "$evidence_root"

# Known marker and loader lock in the evidence copy's tmp directory.
find "$evidence_root/tmp" -maxdepth 1 -type f \( \
  -name '.pc_once_72129118c59f5636c0bb' -o \
  -name 'remote_code_loader.lock' \) -print

# Local image listing only; does not pull, start or modify images.
docker image ls --digests --no-trunc

The example mount path and dependency filenames are generic inspection choices. -xdev skips other filesystems: inventory and inspect relevant mounts separately. No matches, permission errors or missing paths cannot establish cleanliness. Local image listings are only one input to artifact identification.

Datadog names /tmp/.pc_once_72129118c59f5636c0bb and /tmp/remote_code_loader.lock as indicators. The GitHub issue also identifies matching __pycache__ files and a detached Python daemon holding the loader lock. Investigate those with trusted tooling; the commands above do not assess running processes. [S3, S5]

Step 4: Correlate artifacts with release records. Compare versions, tags, digests and pull times with the separately attributed windows above. Preserve uncertainty where retained evidence is incomplete. [S1, S3]

Step 5: Rebuild affected environments. Microsoft recommends rebuilding rather than trusting deletion. Datadog and the GitHub issue recommend reverting to litellm==1.106.2. Perform recovery separately from inspection; no installation commands are shown here. [S3-S5]

Step 6: Rotate reachable credentials from a clean machine and revoke sessions. Microsoft includes model-provider, cloud/workload, CI/CD, source-control, registry, SSH/GPG and AI coding-tool credentials, plus browser sessions. Proxy hosts also require attention to stored provider credentials and DATABASE_URL. The issue additionally calls out instance/task IAM roles, proxy master and virtual keys, and secrets in process environments. [S4, S5]

Step 7: Audit credential use. Datadog recommends reviewing logs for use of exposed credentials. The issue specifically suggests CloudTrail GetCallerIdentity activity from the instance role around installation time. [S3, S5]

Step 8: Reduce repeat exposure. Microsoft's recommendations include hash-pinned lock files, digest-pinned container images and restricted outbound egress from development, build and AI gateway hosts. These controls complement investigation and recovery. [S4]

Microsoft lists Defender Vulnerability Management item TVM-2026-0003 and antivirus detections Trojan:PyPI/LiteLlmSupplyChain.A, Trojan:PyPI/LiteLlmSupplyChain.B, and Backdoor:PyPI/LiteLlmSupplyChain.C. Its published read-only KQL starting point is: [S4]

DeviceTvmSoftwareVulnerabilities
| where CveId == "TVM-2026-0003"

Lessons for AI-agent and release workflows

These are general controls motivated by LiteLLM's account, not claims that a particular control would certainly have prevented the incident:

• Verify revocation after exposure. Rewriting repository history does not revoke a key. Record completion and verify that the exposed credential no longer works. [S2]
• Limit agent-platform privileges. Use narrowly scoped credentials for required repositories and actions. The exposed platform held an organization owner's token. [S2]
• Review credential-specific authentication behavior. Understand whether a token is subject to the reauthentication controls your release process assumes. [S2]
• Preserve independent release approval. Assess changes to approval gates as security changes. In this account, different stolen tokens satisfied the relaxed trigger and approval requirements. [S2]
• Verify release inputs and CI secret access. Check expected repository identities and workflow changes; monitor unusual secret access and deleted workflow runs. The lookalike fork and secret-exfiltrating workflows make those useful review targets. [S2]

For related learning, see AI supply chain security, authentication and secrets management, and CI/CD security. These are reading suggestions, not evidence for incident claims.

FAQ

Does avoiding the LiteLLM proxy protect me? No. The startup hooks could execute in an affected Python environment without importing LiteLLM. Inventory workstations, CI agents and test environments too. [S3, S4]

Is deleting the package enough? No. The planted startup files remain outside its package directory. Microsoft recommends rebuilding; the GitHub issue also identifies compiled leftovers and a detached daemon. [S3-S5]

Which version do the sources recommend? Datadog and the issue recommend 1.106.2. LiteLLM's statement that previous versions are safe should be read in this incident's context, not as a guarantee against every historical compromise. Datadog separately identifies earlier affected versions 1.82.7 and 1.82.8. [S1, S3, S5]

Were private enterprise releases affected? LiteLLM says enterprise customers running the private enterprise release were not impacted. That statement does not clear other public-package installations in the same organization. [S1]

Is this linked to the earlier compromise? Datadog calls this LiteLLM's second supply chain compromise in 2026, attributes the earlier incident to TeamPCP, and says no connection between the incidents has been established. [S3]

What remains uncertain? The reported artifact endpoint times differ, second-stage execution is unconfirmed, and Microsoft's upstream-access finding is explicitly limited. LiteLLM promised process improvements for the following week; the supplied evidence does not establish whether they were subsequently published. [S1-S4]

Sources

• S1: LiteLLM, October 21, 2026, updated October 23, Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised.
• S2: LiteLLM, October 23, 2026, The attack chain behind the v1.107.0 LiteLLM release, canonical account.
• S3: Ian Kretz, Datadog Security Labs, October 21, 2026, LiteLLM supply chain compromise: What you need to know.
• S4: Microsoft Security Blog, October 23, 2026, Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks.
• S5: BerriAI/litellm issue #47826, opened October 21, 2026, by LidorMachluf.