Signed, Protected and Still Poisoned: How Attackers Slipped a Credential Stealer Into the LiteLLM AI Gateway’s Official Release

LiteLLM is the kind of software most business owners have never heard of but may already depend on. It gives developers one interface for calling AI models from OpenAI, Anthropic, Google and others, and according to The Register it is downloaded about 23 million times a week. Because it sits where API keys and cloud credentials live, a poisoned copy is a valuable thing for an attacker to ship. On Wednesday, that is what happened.

This account draws on The Hacker News’ report on LiteLLM’s findings, its earlier coverage of the compromise, and The Register.

The exposure window

PyPI: anyone who installed an unpinned LiteLLM between 11:39 and 13:23 UTC on October 21 (7:39 to 9:23 a.m. Eastern) received the malicious version 1.107.0.
Docker: anyone who pulled v1.107.0, latest, main-latest or main-stable from Docker Hub or GitHub’s container registry between 11:46 and 14:20 UTC (7:46 to 10:20 a.m. Eastern) is affected.
Now: PyPI has quarantined the package and the malicious images have been removed. The last safe version is 1.106.2.

The postmortem: four safeguards, four ways around them

LiteLLM was not careless. After a similar compromise in March, it moved releases into a private repository, made Docker release tags immutable and started signing its Docker images. Here is how the attacker still got through, as LiteLLM describes it.

Safeguard 1: Only a few people can release

How it was bypassed: On October 19, LiteLLM temporarily widened release permissions so two internal engineers could publish daily bugfix backports for customers. The attacker held three sets of developers’ GitHub command-line credentials, including one that could run GitHub workflows.

Safeguard 2: Branch protection

How it was bypassed: Using a token that belonged to an owner of LiteLLM’s GitHub organization, the attacker turned branch protections off and force-pushed malicious changes.

Safeguard 3: Two-person release approval

How it was bypassed: With multiple stolen identities, the attacker used one account to start the release run and a second to approve it.

Safeguard 4: Signed artifacts

How it was bypassed: The workflow was pointed at a lookalike repository, Berri-AI/litellm, instead of the real BerriAI/litellm. The pipeline then signed and published the poisoned build as if it were genuine. A signature proves which pipeline produced a file, not that the code going into it was clean.

Where the keys came from (probably)

LiteLLM’s leading theory involves its own product. It says it found cases where Claude Code embeds a user’s GitHub CLI OAuth token in a response body, and where those response bodies are logged, the token can end up in LiteLLM logs. It also found an internal LiteLLM deployment exposed to the internet with an unexpected, innocuously named user account. The suspicion is that the attacker got into that deployment, likely through a recently patched vulnerability, and read the tokens from its logs. LiteLLM says it has not confirmed how the tokens were obtained. It has revoked them and, for now, removed all but one unaffected user from its GitHub organization.

What the malware does

Starts with Python itself. A file named cook.pth makes Python run the payload every time the interpreter starts, before LiteLLM is even imported.
Steals broadly. The stealer, which calls itself privcollect, collects browser passwords and cookies, AWS, Google Cloud and Azure credentials, cloud instance metadata, environment variables, API keys for AI providers, SSH and GPG keys and shell history, and can pull saved credentials from LiteLLM proxy deployments.
Phones home. The stolen data is encrypted and sent to litellm[.]dev, a lookalike domain.
Leaves a backdoor. On Linux and macOS, a sitecustomize.py file starts a background process that checks a GitHub “dead drop” every hour for a server address and runs whatever Python that server provides. Wiz says the dead drop held only test values before GitHub removed it, and that using a .pth file and sitecustomize.py together appears to be the first documented case in the wild.
Credentials are already being used. Wiz saw stolen AWS credentials from compromised build runners and Kubernetes nodes being tested about four and a half hours after theft, including checks of which Amazon Bedrock AI models were available, a pattern consistent with “LLMjacking,” or running up AI bills on someone else’s account.

Socket says the evidence so far does not link this attack to the March incident, though it cannot rule out the same operator.

If 1.107.0 ran anywhere you manage

Remove it and pin version 1.106.2 by its digest, not just its version number.
Isolate any host, container or build runner that ran it.
Look for the artifacts: Aikido says a file matching /tmp/.pc_once_* means the theft already happened, and /tmp/remote_code_loader.lock means the backdoor ran or is still running.
Block the exfiltration domain at your firewall or DNS filter.
From a clean machine, rotate every credential that machine could reach: cloud keys, AI provider keys, GitHub tokens, database passwords, SSH keys.
Check cloud logs for unexpected activity, including AI model usage, after the install time.

What this means for your company

If your company builds or runs anything with AI, ask your developers or software vendors one question today: did LiteLLM 1.107.0 run anywhere, including build servers and containers? If they are not sure, treat it as a yes. The broader lesson applies to any software you install: a trusted project with signed releases can still ship something malicious for a few hours. Pin dependencies to known-good versions, delay automatic adoption of brand-new releases where you can, keep long-lived secrets out of developer machines and logs, and put spending alerts on cloud and AI accounts so misuse shows up quickly. Those habits shrink both the chance of pulling a bad package and the damage if you do.

Need help reviewing how your developers and vendors handle open-source packages, secrets and AI service keys? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.