LiteLLM 1.107.0 Supply-Chain Attack: What to Check and Rotate

Check what actually ran

The October 21, 2026 LiteLLM compromise reached published Python wheels and container images. Replacing a dependency is only part of recovery when an affected process could read cloud identities, developer credentials or model-provider keys. Distribution has been contained; investigation of the attack chain continues. Official incident report

Which LiteLLM releases were affected?

LiteLLM identifies seven malicious 1.107.0 PyPI wheels. Its official timeline gives these distribution windows on October 21, in UTC:

• PyPI: 11:39:51 to 13:23.
• Docker Hub: 11:46:56 to 14:20.
• GHCR: 11:46:56 until affected tags were unavailable by 13:51.

Container tags were v1.107.0, latest, main-latest and main-stable. GHCR variants included litellm, litellm-database and litellm-non_root. LiteLLM says its private enterprise release registry was unaffected. That exception concerns the distribution path, not every organisation with an enterprise subscription. Affected artifacts and timeline

These are registry availability windows, not a deadline after which existing copies became harmless. Cached wheels, mirrored packages and previously pulled images can execute later. Include development environments, CI runners, ephemeral jobs and downstream images.

The main compromised image index was sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Other variants have different indexes; platform-specific manifest digests also differ from multi-platform indexes. Compare like-for-like and use the full indicator lists. Original research and container analysis

Why starting Python matters

Malicious wheels installed cook.pth, cook.py and sitecustomize.py into the Python library directory. Socket's static analysis found a credential collector and a separate remote-code loader. Ordinary Python startup could trigger them without importing LiteLLM. Socket technical analysis

Python documents that executable import lines in .pth files can run during initialization, and that Python attempts to load sitecustomize. A check that starts the affected interpreter may do more than inspect packages. Python startup documentation

Do not begin response by running Python, pip show or pip install inside a suspect environment. Use trusted investigation tooling and inspect mounted files or collected images without executing their contents. The original research warns against beginning with pip and recommends rebuilding affected images or virtual environments. Original remediation guidance

What was stolen, and what was observed?

Aikido describes collection targets spanning cloud credentials, SSH keys, developer-tool authentication, environment variables, browser data and secrets reachable from the gateway, including database-backed provider credentials and model configuration. Its reported collection destination was hxxp://www[.]litellm[.]dev/healthcheck, a lookalike endpoint rather than an official service. This address is defanged for reference; do not visit it. Aikido payload analysis

Capabilities and outcomes need separate treatment. Attempting to read a credential does not prove the payload obtained it in every environment. Permissions, operating-system behavior, available files and network access affect the result.

Wiz reported use of stolen AWS instance-role credentials across multiple environments between 16:20 and 17:01 UTC on October 21. Observed calls included sts:GetCallerIdentity and model enumeration, with additional IAM discovery in some environments. Wiz assessed model-related activity as consistent with LLMjacking. Wiz post-exploitation observations

Wiz did not observe the loader's second-stage endpoint active in its analysis and reported the GitHub dead-drop repository taken down. This limits claims about remote-command execution. It does not undo credential collection or observed subsequent use. Wiz payload findings

A recovery sequence for operators

This is a practical response plan, not a claim every affected host suffered every possible consequence.

1. Stop execution and preserve the record

Isolate affected workloads and block deployment of malicious artifacts. Coordinate evidence collection before destroying ephemeral infrastructure. Preserve build and pull records, image digests, filesystem evidence and central audit logs.

Assign an owner to maintain an exposure list: artifact, environment, first known execution, accessible identities, containment status and recovery status. Running-service inventories miss jobs that already ended.

2. Investigate with more than filenames

Hunt for startup files, package metadata, known hashes, the loader lock and network evidence. sitecustomize.py has legitimate uses, so its name alone is not a malware verdict. Absence of a temporary marker is not a clean bill of health. Socket investigation guidance

Use indicator destinations for log searches and controls, not URLs to visit. Preserve exact paths for suspicious resources on shared infrastructure; blocking all GitHub traffic can cause unnecessary damage.

3. Revoke credentials from a clean environment

Build a reachability-based list instead of rotating only the most visible application key. Consider model-provider keys, gateway credentials, database access, cloud sessions, registry access, developer-tool sessions and mounted secrets.

Replacing a static key elsewhere may not invalidate already-issued temporary cloud sessions. Use provider session-revocation and containment procedures. Keep replacement credentials away from workloads that have not been rebuilt or cleared.

4. Rebuild and verify the deployed result

Recover from a reviewed artifact and clean base. The original researcher named 1.106.2 as the recovery version; verify current vendor guidance before rollout and pin the approved artifact. Recovery recommendation

“Not part of this malware incident” is narrower than “free of all vulnerabilities.” Record that distinction when rollback changes your ordinary patch baseline. Verify the running digest, remove contaminated build inputs from reuse after preserving evidence, and confirm controls reject known-bad releases.

5. Review activity after initial exposure

Correlate cloud audit records with identity, repository, registry and provider billing activity. Prioritize unusual source networks, new sessions, privilege changes, model access and unexpected usage. One normal-looking API call does not establish compromise; sequence, identity, location and timing matter.

Give every potentially exposed credential a documented disposition. Removing the container does not answer whether its identity remains usable elsewhere.

What failed in the release trust chain?

LiteLLM says stolen developer GitHub credentials were used to alter and approve its release process. Its proposed route through credentials captured in internal gateway logs remained preliminary, and initial access was unconfirmed. A specific vulnerability or product should not be presented as the proven entry point. Maintainer account

Socket examined provenance recording the hyphenated source owner Berri-AI rather than legitimate BerriAI. The artifact therefore required scrutiny beyond the intended source tag. Provenance analysis

Make expected identity enforceable: restrict source repositories and revisions, constrain publishing-workflow changes, alert on protection overrides, and validate artifacts against intended source and policy.

PyPI Trusted Publishing uses short-lived OIDC authentication to reduce reliance on long-lived publishing tokens. It does not inspect whether published software is benign. Authentication, source policy, artifact inspection and deployment approval remain separate checks. PyPI Trusted Publishing documentation

October is not a replay of March

The March 24 incident involved PyPI versions 1.82.7 and 1.82.8. LiteLLM's March advisory said its official proxy Docker distribution was unaffected and described a suspected link to a compromised Trivy dependency in its security workflow. Do not carry that Docker exception into October, or use previous attribution to identify this incident's actor. March incident report

The connection with PHP2Shell and the eMudhra CA incident is operational: establish which trust decision failed, identify assets relying on it, and verify corrective action reached them. Runtime patching, certificate distrust and poisoned-dependency recovery require different evidence. There is no basis here to combine them into one campaign.

Finish with two verified outcomes

An AI gateway concentrates useful access. Give its build and runtime identities narrow permissions, minimal secret exposure, controlled egress, reviewable provenance and durable audit records. Finish with evidence that the malicious artifact is no longer executing and every potentially exposed identity has been investigated and addressed.