LiteLLM 1.107.0 Supply Chain Compromise

• You installed litellm 1.107.0 from PyPI

  pip, uv or Poetry between 11:39 and 13:23 UTC on 21 October, including unpinned installs and CI jobs

  Act now

  Treat the machine or runner as compromised. The theft happened when Python first started, so rotate every secret it could read. Clean up and rotate

• You ran a LiteLLM Docker image from a floating tag

  latest, main-latest, main-stable or v1.107.0, pulled or restarted between 11:46 and 14:20 UTC on 21 October

  Act now

  Treat the container and the secrets passed to it as compromised. Redeploy pinned to a digest. Check the digest you ran

• You run the LiteLLM proxy with a database

  The litellm-database image, or any deployment with DATABASE_URL set

  Act now

  If it ran the bad release, the malware queried the proxy database for its stored provider keys. Rotate every provider key, the master and virtual keys, and the database password.

• You use LiteLLM through another package

  DSPy, langchain-litellm, llama-index-llms-litellm, Open Interpreter, Guardrails AI, or the litellm extra of CrewAI, smolagents and others

  Update needed

  Check your lockfile and install logs. You are affected only if the install resolved to 1.107.0 during the window. How to check

• You pin LiteLLM to an earlier version or image digest

  Any version up to 1.106.2, or a digest you chose before 21 October

  Protected

  Not affected. LiteLLM says every earlier version is safe. Keep the pin until releases resume.

• You use LiteLLM’s private enterprise registry

  Enterprise customers pulling from BerriAI’s private registry

  Protected

  Not affected, according to LiteLLM.

1. 01

   Find every place that ran 1.107.0

   Check developer machines, CI runners, containers and Kubernetes clusters. Include anything that pulled a floating Docker tag or installed LiteLLM without a pinned version. How to check
2. 02

   Isolate it and keep the evidence

   Take the machine or container off the network, and save process, file and network evidence before you change anything. Do not start Python or pip in it: that runs the malware again.
3. 03

   Rotate every secret it could read, from a clean machine

   Start with cloud roles and AI provider keys, which the attacker is already using. What to rotate
4. 04

   Rebuild, then pin

   Rebuild environments and images from scratch with litellm==1.106.2, and pin Docker images by digest instead of a tag. Clean digests
5. 05

   Look for use of stolen credentials

   Search cloud audit logs and network logs for the indicators below, especially AWS calls from unfamiliar IP addresses after 11:39 UTC on 21 October. Indicators

On every registry the affected tags were v1.107.0, latest, main-latest and main-stable. A deployment that follows a floating tag could have pulled the bad image without anyone choosing 1.107.0. The source archive (sdist) carried the tampered build setting but not the malicious files.

Safe versions

LiteLLM says every earlier version is safe and tells users to pin litellm==1.106.2. Normal releases are paused while it investigates, so there is no newer clean release yet. The floating Docker tags now point to the 1.106.2 images. Pin these image index digests rather than a tag:

Clean digests are from issue #47826 and matched the registries on 22 October. Check them again before you deploy.

Installed packages

Look for the malicious files directly on disk. Any match means the environment ran, or will run, the malware.

# Run from a shell. Do not start Python or pip in a suspect environment.
find / -path '*-packages/litellm-1.107.0.dist-info' -type d 2>/dev/null
find / -path '*-packages/cook.pth' -type f 2>/dev/null

LiteLLM’s own report suggests pip show litellm, but also warns that any Python start runs the malware. Use pip only from a clean interpreter pointed at the suspect environment, or stick to the file checks above.

Lockfiles and install logs

# requirements files, and uv.lock or poetry.lock (which list wheel file names)
grep -rnE 'litellm(\[[^]]*\])? *(==|-) *1\.107\.0([^0-9a-z]|$)' .

Pre-releases such as 1.107.0rc1 and 1.107.0rc2 are reported clean. Pipfile.lock puts the version on a separate line, so open it and read the litellm entry. Unpinned installs leave no lockfile, so also search CI logs and package caches from 21 October for litellm-1.107.0.

Docker and Kubernetes

docker images --digests | grep -E 'berriai/litellm|litellm/litellm'
docker images --digests | grep -E '1bbcb1443bc9|c00f9d92c427|7b00e91cd2fe'

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.status.containerStatuses[*].imageID}{"\n"}{end}' \
  | grep -E '1bbcb1443bc9|c00f9d92c427|7b00e91cd2fe|bd1aeee419ea|56b74573eed6|24581ddc3076|827dd893c74c|645a67d81062|f75c8edae59b'

These show only images present now. A pod that ran the bad image and was replaced since leaves no trace here, so also check deployment history and registry pull logs for 11:46 to 14:20 UTC on 21 October. Inside a LiteLLM image the files sit in /app/.venv/lib/python3.13/site-packages/.

Signs the malware ran

ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null
lsof /tmp/remote_code_loader.lock

• /tmp/.pc_once_72129118c59f5636c0bb means the stolen data was sent successfully.
• A process holding /tmp/remote_code_loader.lock is the background loader still running.

A missing marker proves nothing. Failed uploads, temporary folder clean-up and container restarts all leave none behind.

# 1. Stop the background loader
kill $(lsof -t /tmp/remote_code_loader.lock)

# 2. Remove the startup files (set SP to each affected site-packages folder)
SP=/path/to/site-packages
rm -f "$SP/cook.pth" "$SP/cook.py" "$SP/sitecustomize.py" \
  "$SP"/__pycache__/cook*.pyc "$SP"/__pycache__/sitecustomize*.pyc

Some systems ship a legitimate sitecustomize.py. Check its hash against the indicators before you delete it. Then reinstall litellm==1.106.2, and block 1.107.0 in any package proxy or mirror you run.

What to rotate

If 1.107.0 ran on a machine with internet access, assume the theft succeeded. Rotate from a clean machine, starting with what the attacker is known to use: cloud roles and AI provider keys.

When it runs

Python reads .pth files and sitecustomize.py every time it starts. The release used both, so the malware ran whenever any Python program started in that environment, whether or not it imported LiteLLM: pip, pytest, a notebook, or the LiteLLM proxy itself. Installing the package did not run it; the next Python start did. According to Socket, the files were slipped in through one added line in the build configuration, which the official 1.107.0 tag does not contain.

What it collects

It encrypts everything with a key only the attacker can unlock and sends it to www.litellm.dev, a domain registered on 13 October that looks like LiteLLM’s own. Because the upload is encrypted, captured network traffic will not show what was taken.

The remote loader

The second file starts a hidden background process. Every hour it reads a small file from a GitHub repository to learn which server to contact, then downloads and runs whatever Python code that server returns, with no checks. The pointer file only ever held test values and has been empty since 20 October, and the account has since been taken down. No second stage has been seen, but a running loader would obey whoever controls that pointer, so stop it. On Windows the loader fails and only the theft runs.

Is it being exploited?

Yes. Wiz reports that from 16:20 to 17:01 UTC on 21 October the attacker tested AWS role credentials stolen from CI runners and Kubernetes nodes across multiple environments. Each was checked, then used to list the AI models available in Amazon Bedrock. That pattern points to LLMjacking: running AI models at the victim’s expense. In some environments the attacker also listed IAM users, roles and access keys and checked CloudTrail settings. No victim count or download count for 1.107.0 has been published.

Network

• Data upload: HTTP POST to hxxp://www[.]litellm[.]dev/healthcheck with the header X-Token: XWiA8gZNa7NcX2XRoAEb
• Loader pointer: the GitHub repository letters9813/pythonclient-test, read through raw[.]githubusercontent[.]com
• Second stage: any request to a path ending in /codepy
• Python processes calling cloud metadata addresses 169.254.169.254 or 169.254.170.2
• Stolen credentials used from 168.100.8[.]57 and 165.227.201[.]8 (Wiz)

litellm.dev sits behind Cloudflare, so block the domain, not its IP addresses. Block the GitHub repository path, not all of raw.githubusercontent.com.

In cloud audit logs

In AWS CloudTrail, look for sts:GetCallerIdentity from an instance or task role around the time 1.107.0 first ran, followed by use of the same role from outside your network, especially bedrock:ListFoundationModels and IAM listing calls.

On disk

• cook.pth, cook.py or an unexpected sitecustomize.py at the top of site-packages, and their .pyc files
• litellm-1.107.0.dist-info
• /tmp/.pc_once_72129118c59f5636c0bb, /tmp/remote_code_loader.lock, and folders named /tmp/.pc_sq_* or /tmp/.pc_e_*
• The environment variable PRIVCOLLECT_ACTIVE=1, and a detached Python process whose working folder is /

Wheel hashes (SHA-256)

Payload file hashes (SHA-256)

7598727f209d717041db37f7dca271d3a7d328a279890e0e1d55375729aeb86d
0aaf7ba346d41ef2f40390436738b001180d5a1c03aa093f121078a9969d9a1a
668169d35b87bf51324080390b1b1c5ab12bd335cfe5f1a99e3689abd5e02ae6
462d0c9f67ca522d9e0e4acd245e90b36ce0d5353604a66bb7c43a1ec4a6fcf7
c2e32d0ce2548aa662c18bf5001911a79fe5b30cf8357132275add02fdcde054
1bbce8caa94f01c0aaa0b7ddae51553a8a32e1ce53d96d44fe583272aff7ad00
12d4ccc5c6f8d35cf4f2cf233b7f3e418e863e657d81ff5f5fc9e210005b9484
2befe2a79fb4fbbd9a543b5b40b530c8cffa8771bab22b8fb22b2e4ae3b1f819
7f191632e7320705d154b85204f1ae546b543acbd7e8861229b76f5042b92bdb
84dc8c82c0a4a4a62552ef826b49fcc86d1a5c4a5d0f2c06665723f93d129d7d
9dd0a3926f96a37eb86cf1ee2310d9be93139cc4ebef3ef9e2efe9531390be25
03ac2a8b752605d1d7710979c17ff18b03dd978203ba23ba97fd8ce3d6f897ea
34bef04fe88ac9d0aae0475630b1738681d15b94f233ac8aa46eacf5968305fa
b6122440d0d9cb1eb1ade9933f49214da8c31288de7710c076c2680dfa528465

Container image digests (sha256)

The image index for litellm on GHCR and Docker Hub is 1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. The index digests for litellm-database and litellm-non_root have only been published in part: c00f9d92c427… and 7b00e91cd2fe…. Hashes are from Socket, Wiz, SafeDep and the LiteLLM report.

After an earlier compromise in March, LiteLLM moved releases to a private repository, published through PyPI’s trusted publishing, made Docker tags immutable and signed its images. Publishing was limited to one account tied to a laptop kept in the office. The attacker went around these controls rather than through them: with stolen credentials they ran LiteLLM’s own release pipeline, so the malicious release was built, signed and published like a normal one.

• The attacker held GitHub CLI tokens for three LiteLLM engineers. One belonged to one of the two owners of LiteLLM’s GitHub organisation.
• With the owner’s token they turned off branch protection and changed the release workflow so it could build from another repository.
• They pointed it at Berri-AI/litellm, a lookalike of BerriAI/litellm that differs by one hyphen. A second account approved the release, and a third deleted the workflow records afterwards.
• A permission change made the day before, to let two engineers ship daily fixes, widened who could release.

Where the tokens came from

LiteLLM found an unexpected, innocently named user account in its own internal LiteLLM deployment, which was reachable from the internet. It believes the attacker read the tokens from that deployment’s logs. LiteLLM says it has seen specific situations in which Claude Code puts a user’s GitHub CLI token into a response body, and where response bodies are logged, the token lands in LiteLLM’s logs. It has not published those situations, and at the time of writing we found no statement from Anthropic about this.

• Unconfirmed: how the attacker got into the internal deployment. LiteLLM suspects a recently patched vulnerability but has not named it.
• Unconfirmed: how the other two engineers’ tokens were obtained.
• Unknown: who is behind it. No link to the March attack has been established, and JFrog treats them as separate campaigns.

The lesson applies beyond LiteLLM. An AI gateway’s logs can hold anything that passes through it, including tokens. Treat those logs as secret, limit who can reach them, and keep internal gateways off the public internet.

How LiteLLM is responding

LiteLLM revoked the tokens involved, removed all but one user from its GitHub organisation, cut the trusted links between public registries and GitHub, locked its registries and paused releases. It is rotating every token across the organisation. An unrelated embargoed security fix, due for disclosure on 27 October, is going only to its private enterprise registry.

Not the March 2026 incident

In March 2026 LiteLLM 1.82.7 and 1.82.8 were malicious for about 40 minutes, in an attack tied to the Trivy compromise. The October payload, infrastructure and way in are all different. The two incidents share one GitHub advisory and one OSV record, while the PyPA record PYSEC-2026-2 lists only the March versions. A scanner that relies on that record alone may not flag 1.107.0, so check the version directly.

1. 2026-10-13

   2026-10-13

   The domain litellm.dev is registered, and the GitHub account that later hosts the loader’s pointer file is created.

   GitHub issue #47826

2. 2026-10-20

   2026-10-20

   LiteLLM temporarily widens release permissions so two engineers can publish daily bugfix backports.

   LiteLLM incident report

3. 2026-10-21

   2026-10-21 · 08:56 UTC

   The attacker starts committing the malicious files to a lookalike repository, Berri-AI/litellm.

   GitHub issue #47826

4. 2026-10-21 · 10:08 UTC

   Branch protection blocks a change to the private release workflow. Seconds later a privileged developer credential overrides it.

   LiteLLM incident report

5. 2026-10-21 · 11:11 UTC

   A second developer’s credential approves the production release.

   LiteLLM incident report

6. 2026-10-21 · 11:39 UTC

   Seven malicious litellm 1.107.0 wheels are uploaded to PyPI.

   LiteLLM incident report

7. 2026-10-21 · 11:43 UTC

   Automated scanners begin flagging the wheels: AISLE at 11:43, Socket at 11:46.

   AISLE

8. 2026-10-21 · 11:46 UTC

   The malicious Docker images are published, and floating tags such as latest start pointing to them.

   LiteLLM incident report

9. 2026-10-21 · 11:53 UTC

   A third developer’s credential deletes the release workflow records, limiting the logs available to investigators.

   LiteLLM incident report

10. 2026-10-21 · 12:06 UTC

    Upwind researcher Lidor Machluf reports the compromise publicly.

    GitHub issue #47826

11. 2026-10-21 · 13:23 UTC

    PyPI has removed litellm 1.107.0.

    LiteLLM incident report

12. 2026-10-21 · 13:50 UTC

    LiteLLM acknowledges the compromise and declares its top severity.

    GitHub issue #47826

13. 2026-10-21 · 14:20 UTC

    All affected Docker Hub tags are removed or pointed back at clean images.

    LiteLLM incident report

14. 2026-10-21 · 16:20 UTC

    Wiz sees the attacker testing stolen AWS role credentials and listing Amazon Bedrock models, until 17:01.

    Wiz

15. 2026-10-21 · 16:32 UTC

    LiteLLM says the attacker used stolen GitHub CLI tokens belonging to three engineers.

    GitHub issue #47826

16. 2026-10-21 · 21:46 UTC

    OpenSSF adds 1.107.0 to its malicious package record.

    OpenSSF malicious-packages

17. 2026-10-21 · 23:37 UTC

    LiteLLM is rotating every token across its organisation. Registries stay locked and releases are paused.

    GitHub issue #47826

OX Security names 1.106.0 as the clean version. Every other source, including LiteLLM, names 1.106.2.

Evidence to keep: when you assessed it, the systems, lockfiles and image digests you checked, what you found, the rebuilds, every secret rotated with its date, and the log review. If the malware ran where personal data was reachable, such as a proxy database holding customer prompts, assess whether you have a duty to notify.

For how these controls work day to day, see our guides to SOC 2 third-party risk, ISO 27001 third-party risk, SOC 2 secrets management, and incident response plans for ISO 27001 and SOC 2.

• LiteLLM incident report, 21 October 2026Affected artifacts and windows, remediation steps, and the maintainers’ account of the attack chain.
• GitHub issue #47826The original report, maintainer updates, attacker commits and the decoded payload.
• Socket Research TeamBuild provenance pointing to the lookalike repository, payload behaviour and indicators.
• Wiz ResearchStolen AWS credentials used against Amazon Bedrock, and attacker IPs.
• StepSecurityDetailed payload analysis, detection commands and the loader’s pointer history.
• Endor LabsHow the startup hooks run, and checks for hosts, lockfiles and Kubernetes.
• JFrog Security ResearchComparison with the March 2026 compromise, and loader behaviour.
• Datadog Security LabsIndicators and response guidance.
• SafeDepWheel contents, and the review of public GitHub Actions runs.
• AISLEDetection timing for each wheel.
• UpwindThe first public analysis, including the Docker images.
• OSV MAL-2026-2144The malicious package record, shared with the March incident.
• GitHub Advisory GHSA-92x9-889m-jgmwLists 1.107.0 alongside the March versions.