Skip to content

LiteLLM 1.107.0 pushed to PyPI and Docker with a credential stealer

LiteLLM 1.107.0 shipped a credential stealer and a remote-code loader via PyPI wheels and GHCR images. Socket flagged it minutes after publish. Pin 1.106.2 and rotate exposed secrets.

Published 3 min read

A malicious release of LiteLLM, the widely deployed LLM proxy and SDK, hit PyPI and GitHub Container Registry on October 21. Version 1.107.0 carried a credential stealer and a loader that executes attacker-supplied Python. Socket, whose AI scanner flagged the wheels roughly seven minutes after publication, put the first malware alerts out at 11:46:30 UTC; SafeDep, StepSecurity, and Upwind reported the same incident. PyPI has quarantined the package and the malicious images are removed.

What's affected

All seven 1.107.0 PyPI wheels (macOS, Linux, Windows) plus a tampered source distribution, and the Docker images ghcr.io/berriai/litellm:v1.107.0 along with the latest, main-latest, and main-stable tags, which resolved to the same image index. Related tags litellm-database:v1.107.0, litellm-non_root:v1.107.0, and docker.io/litellm/litellm:v1.107.0 are also reported.

How it ran

The payload executes at Python interpreter startup through path-configuration hooks — cook.pth and sitecustomize.py — so it runs during ordinary startup without LiteLLM being imported. This is the same .pth startup-hook technique seen in the TeamPCP-linked LiteLLM compromise of March 2026.

Two stages: a stealer (named privcollect by StepSecurity) that harvests cloud tokens, developer-account credentials, private keys, AI-tool credential JSON files, Chromium and Firefox browser data, environment variables, and the LiteLLM proxy's stored credentials and model configuration; and a loader that forks a background daemon, reads a domain from a GitHub dead-drop hourly, and runs whatever Python the attacker serves from http://<domain>/codepy.

LiteLLM's director of security, Oliver Jensen, said the malicious actions went through three engineers' GitHub accounts "appearing to be by way of stolen GitHub CLI OAuth tokens" — one account triggered the release run, another approved it. The method used to obtain the tokens is not yet identified, so further access cannot be ruled out.

Indicators

Socket published indicators of compromise. Verbatim:

# Exfiltration (HTTP POST)
hxxp://www[.]litellm[.]dev/healthcheck
Upload header:  X-Token: XWiA8gZNa7NcX2XRoAEb

# Loader dead-drop / remote code
hxxps://raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain.txt
http://<domain>/codepy

# Malicious wheels (SHA-256)
7598727f209d717041db37f7dca271d3a7d328a279890e0e1d55375729aeb86d  macosx_10_12_x86_64
0aaf7ba346d41ef2f40390436738b001180d5a1c03aa093f121078a9969d9a1a  macosx_11_0_arm64
668169d35b87bf51324080390b1b1c5ab12bd335cfe5f1a99e3689abd5e02ae6  manylinux_2_28_aarch64
462d0c9f67ca522d9e0e4acd245e90b36ce0d5353604a66bb7c43a1ec4a6fcf7  manylinux_2_28_x86_64
c2e32d0ce2548aa662c18bf5001911a79fe5b30cf8357132275add02fdcde054  musllinux_1_2_aarch64
1bbce8caa94f01c0aaa0b7ddae51553a8a32e1ce53d96d44fe583272aff7ad00  musllinux_1_2_x86_64
12d4ccc5c6f8d35cf4f2cf233b7f3e418e863e657d81ff5f5fc9e210005b9484  win_amd64

Action checklist

  1. Find it. Grep lockfiles, pip freeze, and image manifests for LiteLLM 1.107.0 and the GHCR/Docker tags above. Any host that installed or pulled it since October 21 should be treated as compromised.
  2. Pin down. Roll back to 1.106.2 by digest. Upwind recommends this version; verify artifacts before pinning, as no release has been certified clean.
  3. Rotate everything reachable. From a clean environment, revoke and replace cloud tokens, API keys, SSH and signing keys, browser-stored sessions, and the LiteLLM proxy's own credentials and model-provider keys.
  4. Hunt. Check egress for POSTs to litellm[.]dev/healthcheck, startup artifacts cook.pth / sitecustomize.py, and background Python processes polling GitHub.
  5. Audit GitHub OAuth. Review and revoke GitHub CLI OAuth grants for any engineer with release rights; this is how the actor got in.

Context

This is at least the second LiteLLM supply-chain compromise in 2026 and reuses the March incident's startup-hook trick, the same class of unconditional-execution sink we saw in the Laravel-Lang Composer hijack. The twist here is the entry point: not a leaked publish token this time, but OAuth tokens for a developer CLI, used to drive the project's own release automation. The AI-tooling ecosystem inherits the same registry trust problems as npm and PyPI, and attackers are now treating LLM gateways — which sit on a pile of model-provider and cloud credentials — as a target worth a repeat visit.

Related stories