--- title: Compromised LiteLLM 1.107.0 on PyPI Installs a... description: LiteLLM version 1.107.0 on PyPI shipped a credential stealer and a remote code execution backdoor. All seven wheels (Linux, macOS, Windows) planted three... canonical: https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor | daily.dev og:description: LiteLLM version 1.107.0 on PyPI shipped a credential stealer and a remote code execution backdoor. All seven wheels (Linux, macOS, Windows) planted three... og:url: https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96 og:image: https://api.daily.dev/og/posts/0O33GPS96.png og:image:alt: Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor 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. # Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor **[Hacker News](https://daily.dev/sources/hn)** · 9 min read · 0 upvotes · 0 comments ## Summary LiteLLM version 1.107.0 on PyPI shipped a credential stealer and a remote code execution backdoor. All seven wheels (Linux, macOS, Windows) planted three files, cook.pth, cook.py and sitecustomize.py, in site-packages. Both payloads run on every Python process start, even without importing litellm. The stealer grabs SSH keys, cloud credentials, CI/CD secrets, AI tool tokens, browser passwords and LiteLLM proxy LLM provider keys, then sends them to www.litellm[.]dev. The backdoor daemon checks a GitHub-hosted domain file hourly and executes whatever code that server returns. Versions 1.106.2, 1.107.0rc1 and 1.107.0rc2 are clean, and PyPI has removed 1.107.0. SafeDep believes with moderate to high confidence that BerriAI's own release pipeline built the malicious wheels from an attacker-modified git source. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Is LiteLLM version 1.107.0 on PyPI safe to install? No. LiteLLM 1.107.0 on PyPI contains a credential stealer and a remote code execution backdoor planted as three files, cook.pth, cook.py and sitecustomize.py, in site-packages across all seven wheels. Versions 1.106.2, 1.107.0rc1 and 1.107.0rc2 are clean, and PyPI has since removed 1.107.0. _daily.dev helps developers auditing LiteLLM dependencies catch supply chain compromises like this one._ ### How did attackers inject malicious code into the LiteLLM package build without it appearing in the GitHub source? The sdist's pyproject.toml had one injected line, data = "cook", in the maturin build section, which copied a cook/ folder (absent from the public git history) into the wheel during build. The release also didn't match its tag: the tag commit showed version 1.108.0, while the sdist matched a later main commit plus five edited files including the injection, with moderate to high confidence it came from BerriAI's own private release pipeline. _daily.dev keeps build-pipeline security researchers current on techniques attackers use to poison packages._ ### What data does the cook.py credential stealer in the LiteLLM supply chain attack collect? It collects SSH keys, cloud credentials (AWS, Azure, gcloud, Kubernetes, Docker), CI/CD secrets (GitLab, Jenkins, Terraform), browser passwords and history, shell history, GPG and TLS private keys, AI dev tool tokens (Claude Code, Cursor, Copilot, Codex, and others), environment variables, and LiteLLM proxy database LLM provider API keys, encrypting it with AES-256-CBC and RSA-OAEP before sending it to www.litellm[.]dev. _daily.dev helps security teams track which credential types new malware campaigns target._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 115 comments across hackernews (as of 2026-10-23). **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 - [Schneier on Security](https://daily.dev/posts/schneier-on-security-e5bm44uro) · Schneier on Security · 0 upvotes · 0 comments --- Tags: [#cyber](https://daily.dev/tags/cyber), [#python](https://daily.dev/tags/python), [#malware](https://daily.dev/tags/malware), [#litellm](https://daily.dev/tags/litellm) [View this post on daily.dev](https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96) ```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":"Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor","url":"https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96"},"datePublished":"2026-10-21T16:03:35.675Z","dateModified":"2026-10-23T08:52:29.025Z","description":"LiteLLM version 1.107.0 on PyPI shipped a credential stealer and a remote code execution backdoor. All seven wheels (Linux, macOS, Windows) planted three...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6cb19c95650c07e52b7067eae41c9fee?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6cb19c95650c07e52b7067eae41c9fee?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","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":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"cyber,python,malware,litellm","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/compromised-litellm-1-107-0-on-pypi-installs-a-credential-stealer-and-backdoor-0o33gps96#faq","mainEntity":[{"@type":"Question","name":"Is LiteLLM version 1.107.0 on PyPI safe to install?","acceptedAnswer":{"@type":"Answer","text":"No. LiteLLM 1.107.0 on PyPI contains a credential stealer and a remote code execution backdoor planted as three files, cook.pth, cook.py and sitecustomize.py, in site-packages across all seven wheels. Versions 1.106.2, 1.107.0rc1 and 1.107.0rc2 are clean, and PyPI has since removed 1.107.0. daily.dev helps developers auditing LiteLLM dependencies catch supply chain compromises like this one."}},{"@type":"Question","name":"How did attackers inject malicious code into the LiteLLM package build without it appearing in the GitHub source?","acceptedAnswer":{"@type":"Answer","text":"The sdist's pyproject.toml had one injected line, data = \"cook\", in the maturin build section, which copied a cook/ folder (absent from the public git history) into the wheel during build. The release also didn't match its tag: the tag commit showed version 1.108.0, while the sdist matched a later main commit plus five edited files including the injection, with moderate to high confidence it came from BerriAI's own private release pipeline. daily.dev keeps build-pipeline security researchers current on techniques attackers use to poison packages."}},{"@type":"Question","name":"What data does the cook.py credential stealer in the LiteLLM supply chain attack collect?","acceptedAnswer":{"@type":"Answer","text":"It collects SSH keys, cloud credentials (AWS, Azure, gcloud, Kubernetes, Docker), CI/CD secrets (GitLab, Jenkins, Terraform), browser passwords and history, shell history, GPG and TLS private keys, AI dev tool tokens (Claude Code, Cursor, Copilot, Codex, and others), environment variables, and LiteLLM proxy database LLM provider API keys, encrypting it with AES-256-CBC and RSA-OAEP before sending it to www.litellm[.]dev. daily.dev helps security teams track which credential types new malware campaigns target."}}]} ```