LiteLLM 1.107.0 on PyPI Is Malicious: What the Credential Stealer Takes and How to Clean Up

If you ran pip install litellm or pulled the Docker latest tag on October 21, 2026, check your version before anything else. Security teams at JFrog and SafeDep report that LiteLLM 1.107.0, the Python gateway many teams use to call dozens of model providers through one interface, shipped with a credential stealer and a remote-code loader. PyPI has removed the release, and SafeDep reports that 1.106.2, uploaded earlier that morning, is clean.

This post lays out what the researchers found, what is still unknown, and a cleanup order that avoids the most common mistake: running Python on a machine that is already infected.

TL;DR: what is confirmed

What did the malicious wheels contain?

JFrog describes the wheels as a functional copy of the legitimate project plus three extra files placed in site-packages: cook.pth, cook.py and sitecustomize.py. Python processes .pth files during normal startup and runs any line that begins with import, so cook.pth, which contains only import cook, runs the stealer in every Python process. The second file, sitecustomize.py, is imported automatically after path setup and starts a detached background loader.

Magnifier examining one link in a chain, illustrating a dependency audit after the LiteLLM compromise

The stealer, which decodes to roughly 61 KB of Python and calls itself privcollect, encrypts what it gathers with AES-256-CBC, wraps the key with an embedded RSA-4096 public key, and sends the archive over plain HTTP to a look-alike domain, litellm.dev. JFrog notes the official project uses litellm.ai and that the look-alike was registered on October 13, 2026. Because of the encryption, defenders cannot recover stolen content from a network capture.

The loader reads a domain from a file in a GitHub repository every hour, runs a second copy of the stealer, and downloads and executes whatever code the resulting server returns. JFrog observed the file empty when it checked, which left the loader dormant, but notes that changing the file could re-arm it. SafeDep reports that the GitHub account behind that repository returned 404 about two hours after the release, and that hosts which ran the daemon before then could have received second-stage code that nobody has recovered.

What does it steal?

JFrog's analysis lists the targets, and the list is built for the places AI engineers keep secrets:

• SSH, GPG and TLS private keys, shell and database-client histories, and key files such as .pem and .pfx.
• Browser passwords, cookies and history in Chromium-family browsers and Firefox.
• Cloud credentials for AWS, Azure and Google Cloud, plus Kubernetes configs and service-account tokens, Docker secrets, GitHub CLI tokens and .netrc.
• CI/CD and infrastructure secrets from GitLab Runner, Jenkins, Vault, Terraform and Packer.
• Package-manager and source-control tokens, including .pypirc, .npmrc, .git-credentials, Cargo and Maven settings.
• Credentials and configs for AI developer tools: Claude, Cursor, Codex, Gemini, GitHub Copilot, Hugging Face, Windsurf, Zed, aider, goose and others.
• Environment variables from the current process and, on Linux, every readable /proc/<pid>/environ.
• Cloud instance credentials from AWS and Azure metadata services.
• LiteLLM proxy data: through DATABASE_URL, it attempts to dump the credentials table and the model table, which hold the upstream provider keys.

That last item is what makes a gateway compromise worse than an ordinary library one. A LiteLLM proxy is a vault of keys for many providers at once; one infected proxy host can expose OpenAI, Anthropic, Google and other keys together.

How did it get into the release?

This is the part nobody has fully answered. JFrog reports the published source tarball contains a changed pyproject.toml with a line data = "cook" that tells the Maturin build tool to copy a cook/ folder into the wheel, but the tarball itself does not include that folder. The wheel build therefore had access to files that were not in the published source. JFrog says the metadata favors inclusion during the ordinary build over manual repacking, but does not prove which CI system, machine or credential was compromised.

SafeDep goes further. It compared the source tarball with Git trees and reports that the release does not match its tag: the tag points to a commit whose version says 1.108.0, while the tarball matches a later main-branch commit with the version set back to 1.107.0 and the dependency pins copied from the release candidate, so a quick diff against the candidate shows nothing odd. It also found no public GitHub Actions run that built or published the release, and no provenance attestations on PyPI for 1.107.0, 1.106.2 or the candidate. SafeDep assesses, with "moderate to high confidence," that BerriAI's private release pipeline built the wheels from attacker-modified source. It stresses that only the maintainers' pipeline logs can confirm the cause. Treat that as an assessment, not a finding.

The lesson both teams draw is the same: a clean Git tag or source distribution does not prove the wheel you install is clean. Inspect the artifact itself, including the RECORD file and any .pth or sitecustomize entries.

Is this the same actor as the March incident?

JFrog says no evidence currently links the two. In March 2026 the first LiteLLM compromise came through a poisoned, unpinned Trivy release in LiteLLM's CI pipeline, which exposed publishing credentials and led to backdoored versions 1.82.7 and 1.82.8. For the wider campaign and the arrest that followed, see our coverage of the TeamPCP open-source supply-chain arrest. The new payload differs in startup files, persistence and infrastructure, so use the new indicators for this one.

What should you do, in order?

JFrog's remediation guidance, condensed:

1. Find out if you are exposed. Search every environment, container image and CI cache for litellm==1.107.0 and for the Docker tags above. Check for cook.pth, cook.py and sitecustomize.py in site-packages, and for /tmp/.pc_once_72129118c59f5636c0bb and /tmp/remote_code_loader.lock. Absence of the marker does not prove a host is clean, because the marker is written only after a successful upload.
2. Isolate before you touch. Do not start by running pip in the affected environment, because starting Python can run the payload again. Take the host or container off the network first.
3. Remove the startup files and their compiled copies under __pycache__, using tools that do not launch the affected interpreter, then look for detached Python processes holding the lock file or running with / as the working directory.
4. Block the indicators: www.litellm.dev, the GitHub dead-drop file path, and any domain it returned. Keep DNS, proxy and cloud audit logs.
5. Rotate everything reachable from that host. That means cloud and Kubernetes credentials, SSH and GPG keys, TLS keys, package-publishing and source-control tokens, AI developer tool tokens, the database URL, LiteLLM master and virtual keys, and every provider key stored in the LiteLLM database. If the second-stage loader may have run, assume arbitrary code ran as your user.
6. Rebuild affected virtual environments, hosts and images from verified artifacts rather than trying to prove every artifact is gone. Pin litellm==1.106.2 only in a fresh, clean environment.
7. Review cloud logs for use of the stolen credentials. JFrog notes the stealer tries to validate stolen AWS keys, so look for calls from unfamiliar addresses.

If you run coding agents on the same machines, they inherit the same exposure: an agent with a shell can read the same files the stealer reads. A policy layer that blocks dangerous agent actions before they run, such as AgentBeam from the explainx.ai team, is one way to limit that, but it does not replace rotating secrets.

Why does this keep happening to AI infrastructure?

AI gateways, agent frameworks and MCP servers sit where secrets concentrate: they hold many provider keys, they run with broad network access, and they are updated often because the field moves fast. That makes them an efficient target, and the speed of updating is part of the risk. Our MCP security guide covers the broader pattern for tool servers, and the Respan gateway write-up looks at alternatives to LiteLLM for teams reconsidering their gateway.

Practical habits that would have limited the damage here: pin exact versions and hashes, delay adopting a new release by a day or two, install from a lockfile with hash checking, prefer packages with published provenance attestations, keep provider keys out of long-lived environment variables, and give each gateway a database with only the keys it needs. Detection also mattered: SafeDep and JFrog report that scanners flagged the wheels within minutes, and PyPI removed the release within hours, which shrank the exposure window to a few hours rather than days.

What is still unknown

• How the attacker got the modified source or wheels into BerriAI's release path.
• Whether any host received second-stage code before the dead-drop account disappeared, and what it did.
• How many installs and image pulls happened in the window between the upload at about 11:40 UTC and the removal observed by 13:40 UTC (SafeDep's timeline).
• Whether the maintainers will publish a post-incident report. The community is tracking the incident in LiteLLM issue 47826, per JFrog.

Related reading

• TeamPCP open-source supply-chain arrest, August 2026
• MCP security guide
• Respan: open-source Rust AI gateway as a LiteLLM alternative
• LiteLLM Lens: agent trace analysis
• PHP2Shell: what happened and what to do now
• Cloudflare's open-source security audit skill for agents

Details reflect JFrog and SafeDep write-ups published October 21, 2026; indicators and the root cause may be updated as the investigation continues.