LiteLLM 1.107.0 on PyPI Is Malicious: How to Check Your Systems and What to Rotate

If you installed LiteLLM 1.107.0 from PyPI, treat that machine as compromised. Security firm SafeDep says the release carries a credential stealer and a backdoor, and the upstream GitHub source is clean, so only the PyPI package is affected. Pin to a clean version and rotate your secrets now.

According to SafeDep’s analysis, published October 21, 2026, the poisoned files run every time Python starts. You don’t have to import LiteLLM for the malware to fire.

Quick Facts:

• Affected: LiteLLM 1.107.0 on PyPI, all seven wheels (Linux, macOS, Windows) and the source package.
• Reported clean: 1.106.2, 1.107.0rc1 and 1.107.0rc2.
• What it steals: SSH keys, cloud and CI/CD secrets, AI tool tokens, browser passwords and LiteLLM proxy database keys.
• Your move: remove 1.107.0, pin 1.106.2, hunt for the planted files, then rotate credentials.

What the LiteLLM 1.107.0 malware actually does

SafeDep found two payloads bundled into the package. The first is a stealer that runs at every Python startup. The second is a backdoor that keeps phoning home for new instructions.

The stealer lives in cook.pth and cook.py. A .pth file in site-packages is executed by Python at launch, which is why a simple install is enough. It gathers secrets, encrypts them and uploads them to a look-alike domain, www.litellm[.]dev.

The backdoor sits in sitecustomize.py. It starts a background process that wakes up hourly, reads a server address from a file on GitHub, reruns the stealer, and then downloads and runs code from that server.

The hourly backdoor is the part that raises the stakes. Even if the stealer already got your keys, the attacker could still push new code to your machine later.

How the poisoned release got onto PyPI

SafeDep says the upstream GitHub repository is clean. The trick is one extra line in the source package’s build config, data = "cook", which copies the malicious folder into every wheel.

That points to a hijacked release pipeline or stolen PyPI credentials, though SafeDep describes this as its inference rather than a confirmed cause. If you’re wondering whether this has happened before, it has: LiteLLM was hijacked on PyPI in March 2026 too, with a different set of versions.

This also fits a wider pattern of attackers going after developer tools and keys. We covered a similar case in our post on the OpenCode breach and exposed API keys.

Which LiteLLM versions are safe

Here is where each version stands, based on SafeDep’s report.

Version numbers matter here because the bad release is a point release, not an obvious pre-release. If your requirements.txt says litellm>=1.100 or leaves it unpinned, a fresh build today could have pulled 1.107.0.

How to check if you’re affected

Start with the version, then look for the planted files. These commands are read-only and safe to run.

pip show litellm | grep Version
find / -name "cook.pth" -o -name "cook.py" 2>/dev/null
ls -la /tmp/.pc_once_* /tmp/remote_code_loader.lock 2>/dev/null
env | grep PRIVCOLLECT_ACTIVE

Any hit on those files, or a version of exactly 1.107.0, means you should assume the stealer ran. Also check for a detached Python process with parent ID 1, and for outbound traffic to the litellm[.]dev domain or to the cloud metadata address 169.254.169.254.

SafeDep lists the full set of file hashes and network indicators in its report, so check there if you run a security team.

What to do right now

The order matters. Contain first, then clean, then rotate. Rotating keys on a machine that still runs the backdoor just hands the new keys to the attacker.

1. Disconnect or isolate the affected machine, container or CI runner.
2. Uninstall 1.107.0 and rebuild the environment from scratch rather than patching it in place.
3. Pin to litellm==1.106.2 in your lockfile and use hash-checking where you can.
4. Rotate SSH keys, cloud keys, CI/CD tokens, AI provider keys and LiteLLM proxy database credentials.
5. Review cloud audit logs for activity you don’t recognize since you installed the package.

SafeDep doesn’t explicitly tell users to rotate credentials. That step is our recommendation, based on what the stealer collects.

Frequently Asked Questions

Do I need to import LiteLLM for the malware to run?

No. The stealer is delivered through a .pth file, which Python runs at startup. Any Python process in that environment could trigger it.

Is LiteLLM 1.106.2 safe to use?

SafeDep reports 1.106.2 as clean, along with 1.107.0rc1 and 1.107.0rc2. Verify hashes if you can, and watch the project’s own advisories for a fixed release.

Has PyPI removed the bad release?

SafeDep’s report doesn’t say. Check the LiteLLM page on PyPI and the project’s GitHub issues for the current status before you rely on any 1.107.x build.

Which secrets should I rotate first?

Start with cloud and CI/CD credentials and SSH keys, since those open the most doors. Then do AI provider keys and any database credentials the LiteLLM proxy used.

Our take

If you ran an unpinned install of LiteLLM in the last day, don’t wait for confirmation. Pin 1.106.2, rebuild clean, and rotate everything the machine could reach. Also use this as the nudge to lock your Python dependencies with hashes, because “latest” is a bad default for packages that sit next to your API keys.