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.

Update (October 23, 2026): Socket finds the attacker was inside 11 days earlier

Socket's timeline, published October 23, reports that malicious GitHub Actions workflows ran in the LiteLLM repository well before the release. On October 10 at 22:11 UTC a commit titled "ci: bump cache config" added .github/workflows/cache.yml on a short-lived branch; it read six organization secrets, posted them base64-encoded to a webhook.site collector, and the branch was deleted the same day. On October 12 a second commit added a six-job version that reached environment-scoped secrets and took 14 more. In total Socket counts 20 secrets, including GH_TOKEN, a GitHub App private key, and Anthropic, OpenAI, Bedrock, Together and Tavily keys, plus database and Redis credentials.

Socket says the GitHub activity log attributes the branch events to the ishaan-berri account, but stresses that this shows which credential was used, not who held it. LiteLLM's own investigation, as summarized by Socket, traces initial access to an Agent Platform master key committed to a public repository in May and never revoked, then to a GitHub organization owner's token, and says its audit logs link the token stolen on October 10 to approval of the malicious October 21 release. That would answer part of the "how did it get into the release" question above, though SafeDep's pipeline assessment is not contradicted and Socket lists open questions: whether October 10 was the first activity, what happened between October 12 and 21, and whether the collectors received the data.

What to add to your response: treat every secret in that list as exposed even if you never installed 1.107.0, because the theft happened in LiteLLM's CI, not on your machines. If you run a fork or contribute to a project with similar workflow permissions, review the audit log for new branches named ci-tmp-* and unexpected workflow files, and rotate GitHub tokens and App keys first.

Update (October 24, 2026): LiteLLM publishes its own attack chain and withdraws the log-leak theory

LiteLLM's attack-chain write-up confirms the master-key route that Socket summarized, and corrects the original incident post, which had suspected that tokens were lifted from the logs of an exposed internal deployment. The new account says a config file holding the Agent Platform master key was committed to a public repository on May 27 and, although the commit was force-pushed over, the key was never revoked. On October 10 the attacker used it to call the Agent Platform API, and a response exposed the GitHub CLI token of an organization owner. In LiteLLM's words, the token "was not associated with a service account and was not scoped down."

From there the attacker used CI workflows to take tokens for two maintainers, ran a second round of secret theft on October 12, and on October 21 used the owner token to override branch protection, a maintainer token to pass the production approval gate, and a third to delete run records. LiteLLM says it believes the separate tokens were used to evade detection through noisy audit logs. PyPI quarantined 1.107.0 at 13:23 UTC and Docker tags were cleaned up by 14:20.

Remediation LiteLLM lists: public registries locked, all GitHub organization members removed except one temporary owner, every token and key treated as exfiltrated and rotated, release workflow stripped of GitHub permissions, and a fix release planned that removes the eMudhra certificate authority from the trust store. It promises releases only when it can be confident in their safety. The lesson for your own repos is the part that is cheap to act on: revoke a leaked key even after you scrub the commit, and never let a personal owner token be what an internal service hands back.

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

• Google GTIG on LLMjacking: LiteLLM CVE-2026-40217 and LLM Mixers (November 3, 2026)

• Newer incident: Trojanized Claude Code extension 2.1.313 and its SSH backdoor

• A $50 backdoored Qwen2.5-7B leaked .env credentials via Codex CLI

• 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

• October 2026 cyberattacks: the full list of 48 incidents

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