By ByteBot
On October 21, 2026, LiteLLM — the open-source LLM gateway with 23 million weekly PyPI downloads — had a trojan in its official release for roughly two hours. Version 1.107.0 installed a credential stealer that fired on every Python startup and a remote-access backdoor that called home hourly. If you use LiteLLM anywhere near a machine with cloud keys or AI API secrets, stop what you are doing and check it.
How the Attackers Got In
The entry point is genuinely surprising. Claude Code, when used against LiteLLM’s self-hosted AI gateway, inadvertently embedded GitHub CLI OAuth tokens in LLM response bodies. LiteLLM’s gateway logged those responses. Attackers harvested the logged tokens, then compromised three developer accounts with surgical precision: one to modify the release pipeline, one to approve the poisoned release, and one to delete the workflow logs and cover the trail.
The release was built from a lookalike repository — Berri-AI/litellm instead of the real BerriAI/litellm — and pushed to PyPI and Docker Hub simultaneously. The floating Docker tags latest, main-latest, and main-stable all pointed to the infected image.
What the Malware Actually Does
The payload had two components working in tandem. The first was “privcollect,” a credential stealer dropped as cook.pth — a file Python’s site module processes on every startup, system-wide. It harvested AWS, GCP, and Azure credentials, AI API keys, SSH and TLS private keys, browser passwords, CI/CD tokens (GitHub Actions, GitLab, CircleCI), Kubernetes service account tokens, and database passwords. Anything on the machine or in environment variables was in scope.
The second component was sitecustomize.py, which forked a background daemon. Every hour, the daemon fetched a fresh payload from an attacker-controlled server via a hostname stored in a GitHub repository, then executed it directly with exec(). The malware persists indefinitely on already-infected machines — the window being live was only the entry point.
Are You Affected?
The malicious window was 11:39 to approximately 13:23 UTC on October 21. Only version 1.107.0 on PyPI and the Docker images that pointed to it were trojanized. Run pip show litellm and check if the version is 1.107.0. Then inspect your Python site-packages directory for a file named cook.pth — its presence confirms infection.
For Docker, compare your running image digest against the infected digests published by Socket.dev and Upwind Security. The affected Docker Hub tags are litellm/litellm:latest, main-latest, and main-stable as pulled before approximately 14:20 UTC on October 21. Containers built from those images are compromised regardless of when they were launched.
What to Do Right Now
If you found 1.107.0, the sequence matters:
- Isolate the host before running Python again — the stealer activates on startup.
- Remove the payload files: delete
cook.pth,cook.py, andsitecustomize.pyfrom your Python site-packages directory. - Kill the daemon: kill the process holding
/tmp/remote_code_loader.lock. - Rebuild containers from
litellm==1.106.2pinned by digest — do not clean a compromised container in place. - Rotate everything: AWS keys, GCP service accounts, Azure client secrets, all AI provider API keys, GitHub tokens, CI/CD secrets, SSH keys, Kubernetes tokens, and database passwords. Assume any credential the machine could reach is known to the attacker.
- Block
litellm[.]devat your network perimeter to cut off the RAT callback.
The official remediation guidance from LiteLLM’s incident post and Datadog Security Labs both confirm: do not attempt to clean a compromised container in place. Rebuild.
This Is the Second Time in Seven Months
The March 2026 attack — versions 1.82.7 and 1.82.8, poisoned via a compromised Trivy CI dependency — was live for about 40 minutes and still touched an estimated 2,500 organizations and 430,000 CI/CD pipelines. The October attack was live for two hours and accumulated roughly 49,000 downloads before PyPI quarantined it.
The attack vector shifted between March and October: CI dependency compromise gave way to stolen developer credentials harvested from the library’s own gateway logs. The attacker adapted, and the entry point this time was the AI tooling stack itself. Floating version tags on packages with 23 million weekly downloads are a documented liability — pin by digest or pin by exact version, full stop.
The broader signal is harder to ignore now. The AI tooling layer — the proxies, gateways, and SDKs sitting between your code and the models — is an active attack surface. Your AI stack probably logs more than you think. Your credentials probably flow through more intermediaries than you have mapped. The March attack should have been the wake-up call. The October one does not get to be a surprise.
