Short answer: If you installed, mirrored, or ran a container with LiteLLM 1.107.0 on October 21, 2026, treat the environment as exposed until you prove otherwise. The compromised release could steal developer, cloud, AI, browser, and SSH credentials simply by starting Python, even if your code never imported LiteLLM. Uninstalling LiteLLM alone is not enough, because the malicious startup files lived outside the normal LiteLLM directory. Rebuild the environment from clean artifacts and rotate every credential the affected identity could reach.
What happened to LiteLLM 1.107.0
LiteLLM is a popular open source gateway that sits between applications and large language model providers. Teams use it to route requests, manage provider keys, and apply consistent policies across models. That central position is exactly why this incident matters: a gateway often holds the keys to many other services.
On October 21, 2026, a compromised LiteLLM 1.107.0 release was published to the Python Package Index (PyPI) and distributed through official container images. Microsoft Threat Intelligence analysed the package and published a detailed breakdown on October 23, 2026. According to LiteLLM maintainers, stolen developer GitHub credentials were used to alter the release workflow and redirect it to a lookalike repository, Berri-AI/litellm, rather than the legitimate BerriAI/litellm repository. A credential linked to another developer account was then used to satisfy a production approval step. Microsoft notes that it has not independently determined how the attacker first obtained those credentials.
The malicious artifacts were removed from PyPI and the container registries the same day, but removal does not undo exposure on systems that already installed or ran the release. If Python started in an affected environment after installation, the payload had a chance to run.
Why simply starting Python was enough
Most supply chain attacks wait for the victim application to import the poisoned library or call a specific function. This one did not. The compromised wheel placed three files, cook.pth, cook.py, and sitecustomize.py, in the Python environment library directory, outside the normal litellm application folder.
Python processes .pth files and the sitecustomize module during normal interpreter startup. The single executable line in cook.pth, import cook, loaded cook.py, which decoded and ran a credential collector known as PRIVCOLLECT in a background thread. A separate Unix-oriented loader in sitecustomize.py could also fetch and run additional Python code from a remote server, although Microsoft says that second-stage retrieval was not confirmed at the time researchers examined the pointer file.
That design widened the blast radius well beyond live AI gateways. Developer workstations, build agents, test systems, containers, and CI/CD runners that started Python with the package installed could all trigger the collector, even for a completely unrelated task. Microsoft gives one telling example: on Windows, a routine Python invocation to install an unrelated dependency activated the collector.
It also explains the most dangerous cleanup mistake. Deleting the litellm folder, rolling a container tag back, or uninstalling the package can leave cook.pth, cook.py, and sitecustomize.py behind. Those files are the persistence mechanism, not a side effect.
What the payload tried to collect
The collector ran several modules in sequence, each with its own error handling, so one unavailable target did not stop the rest. Microsoft lists the following targets:
- Developer and AI tools: authentication and configuration files for AI assistants, IDEs, GitHub Copilot, VS Code, and MCP integrations.
- Source control and package ecosystems: Git credentials, package-manager configuration, selected dotenv files, and private-key material.
- Cloud and workload credentials: AWS, Azure CLI, and Google Cloud configuration and credential caches, Kubernetes service-account files, Docker configuration, mounted secrets, and cloud metadata credentials.
- Browsers and histories: Chromium-family and Firefox credential-related data and browsing history, plus shell, database-client, and interactive-tool histories.
- Process environments: its own environment and, on Linux, other process environments readable through procfs, which can expose secrets beyond the variables configured for LiteLLM itself.
- Private keys and infrastructure: readable SSH material and selected GPG, TLS, CI/CD, Vault, and infrastructure-tool configuration.
- LiteLLM proxy data: where prerequisites were met, selected fields from two proxy database tables, with a 500-row limit per query.
Microsoft is careful on one point that is worth repeating: a target appearing in the code does not prove successful access in every case. Password decryption, for example, depends on platform and format. But for response purposes, any credential reachable by the affected identity should be treated as exposed until investigation shows otherwise.
Collected data was encrypted with a fresh AES-256 key per run, wrapped with an embedded RSA public key, packed into a gzip-compressed archive, and uploaded to an attacker-controlled endpoint. The collector retried uploads and treated only an HTTP 200 response as success.
Which versions and images were affected
Only LiteLLM 1.107.0 on PyPI was affected, across all seven platform wheels. On Docker Hub and GitHub Container Registry, the v1.107.0, latest, main-latest, and main-stable tags pointed to the malicious image during the exposure window, as did the litellm-database and litellm-non_root variants on GHCR. The official v1.107.0 source tag on GitHub does not contain the malicious files, which is an important distinction for anyone verifying a build from source.
Reported safe practice is to pin a release published before October 21, 2026, such as 1.106.2, and to verify container images by digest rather than by mutable tag. A tag can be repointed; a digest identifies immutable image content. If your lock files, mirrors, caches, or build outputs reference 1.107.0, include them in the hunt, not just the machines that are still running.
This is the second LiteLLM supply chain incident in 2026. An earlier campaign compromised versions 1.82.7 and 1.82.8 in March 2026. The pattern is now hard to ignore: AI infrastructure packages are high-value targets because one compromised gateway can reach many providers, clouds, and developer accounts at once. The same lesson runs through the Tensorlake npm compromise, where a poisoned package also spread through the developer toolchain, and the PoeLLM campaign, which turned exposed AI servers into crypto miners.
What to do right now if you used LiteLLM 1.107.0
Do not start by running Python or pip inside a suspect environment to check whether the package is present. That is exactly the action that can trigger the payload again. Investigate from a known-clean system, using trusted tools that do not invoke the affected interpreter.
1. Find every affected copy
Search installed environments, pip and uv caches, internal package mirrors, lock files, build outputs, and container images for LiteLLM 1.107.0. Include mutable container tags and the exposure window, and compare artifacts against the hashes in Microsoft’s indicators of compromise. Do not forget developer laptops and CI runners; they are often the quietest copies.
2. Isolate before you clean
Isolate affected workstations, build agents, test systems, containers, and gateway hosts. Where it is safe to do so, stop running Python processes and prevent automation from restarting them. Keep evidence intact until you have correlated file hashes, process ancestry, network connections, and later cloud or identity activity.
3. Rebuild, do not just uninstall
Confirm that cook.pth, cook.py, and sitecustomize.py are gone from the environment library path. Rebuilding from verified artifacts is more reliable than assuming that deleting the litellm directory cleaned the top-level startup files. Rebuild container images from a clean base and a pinned, pre-October 21 release, and verify by digest.
4. Rotate credentials from a clean machine
Rotate model-provider keys, cloud and workload credentials, CI/CD secrets, source-control and registry tokens, SSH and GPG keys, AI coding-tool tokens, and browser sessions available to the affected identity. On proxy hosts, include stored provider credentials and the database connection string. Revoke active sessions rather than assuming a key rotation immediately invalidates every token. If you find evidence of follow-on use, such as unexpected cloud activity, treat that as a separate incident to scope, not as a routine cleanup.
5. Check for follow-on access
Correlate before declaring the incident closed. Look for the collector’s staging artefacts, outbound connections to the reported endpoint, new or unexpected cloud identities, and use of credentials that were reachable from the affected host. Package presence alone is not a verdict, and absence of the package alone is not proof of safety.
What this means for teams that did not use LiteLLM
Even if you never deployed LiteLLM, this incident is a useful stress test for your own supply chain. Ask three questions: do your builds pin exact versions and verify hashes or digests, do your CI runners and developer machines run with least-privilege credentials, and could a single compromised dependency reach production cloud keys?
Pinning versions, separating build credentials from production credentials, and keeping developer and production secrets apart all reduce the damage when, not if, another widely used package is compromised. The free AI security scanning work from Anthropic and the steady drumbeat of October 2026 patches, including the Node.js October 2026 security update, point in the same direction: AI-era supply chain risk is now a routine operational problem, not a rare event.
Frequently asked questions
Was I affected if I installed LiteLLM 1.107.0 but never ran it?
Installation alone placed the startup files, but the payload ran when Python started in that environment. If Python never started there, the risk is much lower, yet you should still remove the affected artifacts from caches, mirrors, and images before anything else uses them.
Is uninstalling LiteLLM 1.107.0 enough?
No. Microsoft is explicit that removing the package or rolling a release tag back is not sufficient recovery, because cook.pth, cook.py, and sitecustomize.py lived outside the litellm directory. Rebuild the environment and verify those files are gone.
Which LiteLLM version should I use instead?
Use a release published before October 21, 2026, such as 1.106.2, and pin it exactly. For containers, verify by digest rather than trusting a mutable tag such as latest.
Do I need to rotate all my credentials?
Rotate every credential the affected identity could reach, including model-provider keys, cloud credentials, CI/CD secrets, registry tokens, SSH keys, and AI tool tokens. Revoke active sessions as well, since rotation alone may not invalidate every live token.
Was the second-stage remote code loader used?
Microsoft says remote retrieval and execution through the sitecustomize.py loader were not confirmed, and the pointer file researchers examined was empty at the time. That does not make the loader harmless: it remained a re-armable remote-code execution mechanism, so affected environments still needed a full rebuild.