<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8" -->

---
title: litellm 1.107.0 on PyPI is backdoored with a credential...
description: LiteLLM 1.107.0 on PyPI was published with malware in all seven of its compiled wheels, affecting every supported OS. The GitHub source repo and source tarball...
canonical: https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: litellm 1.107.0 on PyPI is backdoored with a credential stealer and a remote code loader | daily.dev
og:description: LiteLLM 1.107.0 on PyPI was published with malware in all seven of its compiled wheels, affecting every supported OS. The GitHub source repo and source tarball...
og:url: https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8
og:image: https://api.daily.dev/og/posts/N3sXkwgU8.png
og:image:alt: litellm 1.107.0 on PyPI is backdoored with a credential stealer and a remote code loader
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# litellm 1.107.0 on PyPI is backdoored with a credential stealer and a remote code loader

**[Collections](https://daily.dev/sources/collections)** · 3 min read · 3 upvotes · 0 comments

## Summary

LiteLLM 1.107.0 on PyPI was published with malware in all seven of its compiled wheels, affecting every supported OS. The GitHub source repo and source tarball are clean, so only the prebuilt wheels are compromised. This is the second LiteLLM PyPI compromise this year, after versions 1.82.7 and 1.82.8 in March. The malicious wheels drop cook.pth, cook.py and sitecustomize.py, which run on every Python startup and steal browser passwords, SSH/GPG keys, cloud credentials, CI/CD secrets and configs from over 20 AI coding tools, sending them encrypted to a lookalike domain. A second payload installs a background daemon that checks a GitHub dead drop hourly and executes whatever code it finds. Anyone who installed this version should reinstall litellm 1.106.2 and rotate every credential the machine could reach.

## Content

LiteLLM 1.107.0 was published to PyPI and Docker with malware in it. It sat on PyPI for under two hours (about 100 minutes by one count) and was downloaded roughly 49,000 times. The official Docker `latest` tags pointed to it as well. PyPI has since removed the release. LiteLLM gets about 23 million weekly downloads, so the exposure is not small.

## What the malware does

All seven compiled wheels, covering Linux, macOS and Windows, drop three files into site-packages: `cook.pth`, `cook.py` and `sitecustomize.py`. They run on every Python process start. You don't need to import litellm. The GitHub source repo and the source tarball stayed clean.

There are two payloads.

- **The stealer** (called privcollect) takes browser passwords, SSH and GPG keys, cloud credentials (AWS, GCP, Azure), CI/CD secrets, and configs and tokens for more than 20 AI coding tools, including Claude Code and Cursor. It also takes OpenAI and Anthropic API keys and the LLM provider keys stored in a LiteLLM proxy database. Everything is encrypted with AES-256-CBC and a hardcoded RSA-4096 key, then sent to `www.litellm[.]dev`, a lookalike domain.
- **The backdoor** is a background daemon started by `sitecustomize.py`. Every hour it checks a GitHub-hosted dead drop and runs whatever code comes back, which gives the attacker ongoing arbitrary code execution.

Wiz later saw stolen AWS keys being tested against Bedrock.

## Who is affected and what to do

Versions 1.106.2, 1.107.0rc1 and 1.107.0rc2 are clean. If you ran `pip install litellm==1.107.0`, or pulled a Docker `latest` image during the window, assume the machine is compromised.

1. Look for `/tmp/.pc_once_*` and `/tmp/remote_code_loader.lock`.
2. Remove the payload files and kill the daemon.
3. Reinstall litellm 1.106.2, or another release published before the attack.
4. Rotate every secret the machine could reach: cloud keys, SSH and GPG keys, CI/CD secrets, AI provider keys.

A package cooldown, where new releases aren't installed until they've been public for a while, would have avoided this one.

## How it happened

LiteLLM says the attacker got in through GitHub tokens that leaked into its own logs. Claude Code sometimes puts a user's GitHub CLI OAuth token into a response, and if something logs those responses, the tokens can end up in the logs. Using three stolen developer credentials, the attacker disabled branch protection, pushed 1.107.0 from a lookalike repo, and deleted workflow records. SafeDep believes with moderate to high confidence that BerriAI's own release pipeline built the malicious wheels from an attacker-modified git source.

The attack started earlier than it first appeared. Socket found secret-stealing workflows running in the BerriAI/litellm repository eleven days before the release, on October 10, 2026. The method was simple: push a workflow to a throwaway branch, let `on: [push]` run it with real secrets, then delete the branch. That took 20 secrets, including a GitHub App private key. LiteLLM has said it finished its investigation of the attack chain.

## Not the first time

This is the second LiteLLM PyPI compromise this year. In March, versions 1.82.7 and 1.82.8 were hit, potentially exposing more than 2,500 organizations and 434,000 CI/CD pipelines.

Two compromises in one year for a package that sits between apps and every major model provider is hard to shrug off. A gateway library holds exactly the keys an attacker wants, so rotating credentials and delaying new releases are now basic hygiene for anyone running one.

## Questions this post answers

### Is litellm 1.107.0 on PyPI safe to install?

No, litellm 1.107.0 is backdoored. All seven compiled wheels for every supported operating system contain malware, while the GitHub source repo and source tarball remain clean. The payload drops cook.pth, cook.py and sitecustomize.py, which run automatically on every Python startup without requiring litellm to be imported.

_Teams tracking PyPI supply chain incidents like this one can follow dependency security news on daily.dev._

### What should I do if I installed litellm version 1.107.0?

Treat the machine as compromised, since the stealer runs on the first Python start after install. Remove cook.pth, cook.py and the malicious sitecustomize.py, kill the background daemon, reinstall litellm 1.106.2, and rotate every credential the machine could reach, including SSH/GPG keys, cloud keys, CI/CD secrets, browser passwords, AI tool tokens and proxy API keys.

_Developers responding to a compromised dependency can track remediation guidance like this on daily.dev._

### What data does the litellm malware steal and where does it send it?

A payload called privcollect steals browser passwords, SSH and GPG keys, cloud credentials, CI/CD secrets, configs for over 20 AI coding tools including Claude Code and Cursor, and API keys from LiteLLM proxy databases. It encrypts everything with a hardcoded RSA-4096 key and sends it to www.litellm.dev, a lookalike of the real project domain.

_Anyone auditing what a compromised package can exfiltrate can find incident breakdowns like this on daily.dev._

## Community take

How the wider developer community reacted, aggregated from 1 discussion and 115 comments across hackernews (as of 2026-10-24).

**TL;DR:** The discussion is dominated by alarm that this is LiteLLM's second major supply-chain compromise, with many saying it's now negligent to keep using the project and others debating how to prevent such attacks via cooldowns, sandboxing, and pinned versions.

**Sentiment:** 5% positive · 20% mixed · 75% skeptical

**The case for**

- Some note the incident is at least prompting broader conversations about supply-chain defenses like dependency cooldowns and sandboxing tools.
- A few acknowledge that disclosing and documenting the incident publicly helps the ecosystem get stronger over time.

**The pushback**

- Many argue this is the second serious compromise for the project and call continued use negligent or malpractice.
- Several are skeptical that short dependency cooldowns (24-48h) would help, since supply-chain attacks often hide undetected for months or years.
- Criticism that the maintainers announced a private, paid-only patch for an undisclosed enterprise vulnerability while OSS users wait, which some call an unethical optic.
- Concern that three separate developer GitHub credentials were compromised, suggesting a deeper systemic problem in the release pipeline.
- Doubts raised about whether cooldowns, sandboxing, or LLM-based scanning can meaningfully stop novel attacks without creating new risks like prompt injection.

**By community**

- hackernews (heated): A large, contentious thread mixing frustration over LiteLLM's repeat compromise with a long technical debate over cooldowns, sandboxing, and whether enterprise customers getting embargoed patches first is appropriate.

**Hottest debate:** Whether dependency cooldown periods actually protect against supply-chain attacks, given some attacks stay hidden for months, versus being an easy, mostly-sufficient mitigation.

**Open questions**

- How exactly attacker-controlled code got into the official build pipeline despite no trace in public commits.
- Whether the three compromised developer credentials point to a broader systemic weakness beyond this single incident.
- What a reasonable cooldown length would actually be, given attacks that remain undetected for months or years.

**Highlights**

> I am not following how someone snuck the files into the release. All I read was that it creates a directory from the build file but seemingly no description how new files or added dependencies slipped by. Was `cook.pth` a dependency that got automatically downloaded from PyPI on install and then the build system put it into dependencies? -- Leaving this for others: > BerriAI’s private release pipeline built these wheels from an attacker-modified git source. The attacker could have used a compromised maintainer or bot credential, a private branch or mirror, or the reference the pipeline builds from. A stolen PyPI token used from the attacker’s own machines fits the evidence less well. Makes sense. It was that a maintainer or the private pipeline was attacked and the malicious dependency was injected there by squatting on the maintainer's local copy rather than the dependency being hijacked for everyone. Very clever.
> — [madamelic on hackernews](https://news.ycombinator.com/item?id=50183673)

> "Attackers compromised 3 unique developer github credentials" is a little scary; this seems systemic - if three developers had their keys stolen, it implies the real problem is elsewhere. They revoked all but one developers, which is probably the right approach, but I'd pin LiteLLM to "something before this version" and keep it there until further notice!
> — [threecheese on hackernews](https://news.ycombinator.com/item?id=50186105)

> They are saying that 1. there is a second vulnerability that will be disclosed next Tuesday (can't be this one because talking about it as undisclosed in the GH issue disclosing it makes no sense) 2. the patch for that vulnerability is somewhere in the diff between $current_public_release and $current_enterprise_release 3. You have to pay to get $current_enterprise_release They might not be selling the vulnerability directly, but they are selling access to the patch that fixes it. Which would be enough of a hint even in pre-LLM times. And unlike other vendors they don't just claim "you get faster updates and additional features" or something like that, they directly point out that if you buy now you get advance access to the fix to an unannounced vuln I'm not saying they are advertising this to bad actors. But if they wanted to do that with a shred of plausible deniability, this would be the way to do it
> — [wongarsu on hackernews · 1 comments](https://news.ycombinator.com/item?id=50184948)

> Well it seems like it’s over for litellm. You’d have to be negligent to be using them at this point. If you’re managing this at your company good luck explaining why you should continue to use litellm after this
> — [abletonlive on hackernews](https://news.ycombinator.com/item?id=50185796)

> This is the second significant exploit against LiteLLM in what, a year or two ? Just last night I came across notes and a script from an older claude session to help audit all project dependencies and verify nothing used litellm. Okay, checked, it was March of this year: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attac.... What even is time anymore in the llm age?
> — [rsanheim on hackernews](https://news.ycombinator.com/item?id=50187074)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=50181114) · 305 points · 115 comments

## Similar posts on daily.dev

- [What the LiteLLM Breach Teaches Us About Securing LLM Gateways](https://daily.dev/posts/what-the-litellm-breach-teaches-us-about-securing-llm-gateways-ysbbrmwzu) · Medium · 0 upvotes · 0 comments

---

Tags: [#security](https://daily.dev/tags/security), [#cyber](https://daily.dev/tags/cyber), [#python](https://daily.dev/tags/python), [#litellm](https://daily.dev/tags/litellm)

[View this post on daily.dev](https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"litellm 1.107.0 on PyPI is backdoored with a credential stealer and a remote code loader","url":"https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8"},"datePublished":"2026-10-21T14:20:33.216Z","dateModified":"2026-10-24T06:44:36.492Z","description":"LiteLLM 1.107.0 on PyPI was published with malware in all seven of its compiled wheels, affecting every supported OS. The GitHub source repo and source tarball...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/31a91b23bd37af914ddc6d89475691b4?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/31a91b23bd37af914ddc6d89475691b4?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,cyber,python,litellm","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"litellm 1.107.0 on PyPI is backdoored with a credential stealer and a remote code loader"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/litellm-1-107-0-on-pypi-is-backdoored-with-a-credential-stealer-and-a-remote-code-loader-n3sxkwgu8#faq","mainEntity":[{"@type":"Question","name":"Is litellm 1.107.0 on PyPI safe to install?","acceptedAnswer":{"@type":"Answer","text":"No, litellm 1.107.0 is backdoored. All seven compiled wheels for every supported operating system contain malware, while the GitHub source repo and source tarball remain clean. The payload drops cook.pth, cook.py and sitecustomize.py, which run automatically on every Python startup without requiring litellm to be imported. Teams tracking PyPI supply chain incidents like this one can follow dependency security news on daily.dev."}},{"@type":"Question","name":"What should I do if I installed litellm version 1.107.0?","acceptedAnswer":{"@type":"Answer","text":"Treat the machine as compromised, since the stealer runs on the first Python start after install. Remove cook.pth, cook.py and the malicious sitecustomize.py, kill the background daemon, reinstall litellm 1.106.2, and rotate every credential the machine could reach, including SSH/GPG keys, cloud keys, CI/CD secrets, browser passwords, AI tool tokens and proxy API keys. Developers responding to a compromised dependency can track remediation guidance like this on daily.dev."}},{"@type":"Question","name":"What data does the litellm malware steal and where does it send it?","acceptedAnswer":{"@type":"Answer","text":"A payload called privcollect steals browser passwords, SSH and GPG keys, cloud credentials, CI/CD secrets, configs for over 20 AI coding tools including Claude Code and Cursor, and API keys from LiteLLM proxy databases. It encrypts everything with a hardcoded RSA-4096 key and sends it to www.litellm.dev, a lookalike of the real project domain. Anyone auditing what a compromised package can exfiltrate can find incident breakdowns like this on daily.dev."}}]}
```

