The LiteLLM PyPI Backdoor Shows Where the Next AI Service Business Is: Auditing the Gap Between What a Team Built and What It Actually Installed.

A backdoored package reached PyPI on October 21, 2026 — and the source code on GitHub was never touched.

What actually happened

LiteLLM 1.107.0 shipped with two malicious payloads installed across all seven wheel distributions for Linux, macOS, and Windows. The first, a credential stealer named cook.py, ran automatically in every Python process via a cook.pth file and collected "SSH keys, cloud credentials, CI/CD secrets, AI tool tokens, browser passwords, and the LLM provider keys in a LiteLLM proxy database," encrypting the haul and sending it to an attacker-controlled endpoint. The second, sitecustomize.py, spawned an hourly daemon that pulled a command-and-control domain from a GitHub repo and executed whatever arbitrary code it returned.

SafeDep caught the discrepancy by comparing the sdist files on PyPI against the git commits using blob-hash comparison and found an injected line in pyproject.toml — data = "cook" — that appears in no public commit. Their conclusion: "no public commit in BerriAI/litellm contains data = 'cook' or a cook/ folder." The timeline moved fast — tag created at 06:59 UTC, wheels built 11:20–11:37, uploaded to PyPI by 11:40, pulled by 13:40 once discovered, with the attacker's GitHub account deleted shortly after.

SafeDep assessed "with moderate to high confidence" that this wasn't a stolen PyPI token — it was BerriAI's private release pipeline itself that got compromised, based on wheels matching normal build output (correct maturin version, proper timestamps, correct line endings per platform) with no corresponding public GitHub Actions run behind them.

Why this is a service, not just a warning

The uncomfortable fact buried in that attribution is the one worth selling against: source-code review doesn't catch this. The GitHub repo was clean the entire time. The only way to catch a compromised release pipeline is to independently verify that what got published actually matches what was tagged — and almost no team running an AI gateway, agent framework, or LLM proxy in production is doing that check today.

That's a packageable audit: pull the dependency tree for a client's AI stack, diff every package's published artifact against its source tag using the same blob-hash method SafeDep used, and flag anything with build-time code execution hooks (setup.py, .pth files, sitecustomize.py). Follow it with a retainer that reruns the check on every new release, because a clean audit today says nothing about the update a team pulls next month.

How to apply this beyond LiteLLM

Any team that treats "the GitHub repo looked fine" as sufficient due diligence for an AI dependency is exposed to exactly this attack class. The pitch isn't abstract supply-chain fear — it's the literal exfiltration target list from this incident: AI tool tokens and LLM provider keys, the two categories every team running agents or gateways has sitting in environment variables right now.

Sources:

https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/