Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Illustration: a dark server room at night, a glowing open package box with a cracked seal, shadowy code tendrils pulling glowing key-shaped glyphs toward a distant shadowed server rack, one amber warning light flaring

LiteLLM 1.107.0 Was Trojanized: How to Check If You Were Hit

by

In brief

  • A trojanized LiteLLM 1.107.0 release stole cloud credentials and AI API keys on October 21, 2026. How to tell if you’re affected and exactly what to rotate first.
  • On October 21, 2026, a trojanized version of LiteLLM — the open-source AI gateway with roughly 23 million weekly downloads — was distributed through PyPI and Docker registries. Unknown attackers had compromised the project’s release process, and version 1.107.0, uploaded at 11:39 UTC, carried credential-stealing malware plus a remote access trojan.
  • Anyone who installed or ran 1.107.0 should treat every credential on that machine as compromised: cloud credentials (AWS, Google Cloud, Azure), LLM provider API keys (OpenAI, Anthropic, Cohere and others), browser-stored logins, SSH and GPG keys.
  • Two files prove whether the malware fired on your system: /tmp/.pc_once_* (exfiltration happened) and /tmp/remote_code_loader.lock (the remote-access daemon ran or is still running). The latest safe release is v1.106.2 — PyPI quarantined 1.107.0 within hours and the Docker image was pulled.
  • This is the second LiteLLM supply-chain compromise this year. An earlier incident in March potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines, according to CloudSEK.
  • Update, October 24: LiteLLM disclosed the root cause — a leaked master key, committed in May and never revoked, gave the attacker owner-level access to its GitHub organization. Wiz counts roughly 49,000 downloads of the trojanized release, and observed the attacker validating stolen AWS credentials within hours.

What happened

LiteLLM, developed by BerriAI, is one of the most widely used open-source gateways for routing requests to large language models — it sits between applications and LLM providers like OpenAI and Anthropic, which means it typically runs alongside the most sensitive credentials an AI team holds: provider API keys, cloud identities, and database connection strings.

On October 21, attackers compromised the project’s release process and pushed a malicious 1.107.0 through the normal distribution channels: PyPI (the Python package index) and Docker registries, including Docker Hub and GHCR. Because it came through the project’s own pipeline rather than a lookalike package, there was nothing visibly wrong with it — pip install litellm or a routine image pull during a few-hour window was enough.

Wiz researchers Benjamin Read and Rami McCarthy traced the payload to malicious commits made through github.com/Berri-AI/litellm — a hyphenated variant of the legitimate BerriAI organization — which injected three files into the release pipeline. Per their analysis, reported by The Register’s Jessica Lyons: cook.pth acts as the trigger, causing cook.py to execute automatically whenever Python is invoked, with no further user action required. cook.py is the infostealer; sitecustomize.py is the remote access trojan, spawning a background daemon that polls attacker infrastructure every hour for commands.

The infostealer’s reach is unusually broad. Read and McCarthy counted 16 stealer modules targeting: browser credentials and cookies from Chrome, Firefox, Edge, and Safari; AWS credentials from ~/.aws/, environment variables, and EC2/ECS instance metadata; Google Cloud service account keys and application default credentials; Azure tokens from the CLI cache; API keys for OpenAI, Anthropic, Cohere, and other LLM providers; plus SSH private keys, GPG keys, and shell history files. The stolen data was encrypted with AES-256-CBC under an RSA-4096 wrapped key and sent by HTTP POST to an attacker-controlled domain.

The window was short but the blast radius is unknown. PyPI quarantined the package within hours of the 11:39 UTC upload, and the Docker image litellm/litellm:1.107.0 was pulled from both Docker Hub and GHCR soon after. But LiteLLM sees about 23 million weekly downloads, and the compromise also touched the latest, main-latest, and main-stable image tags. BerriAI did not respond to The Register’s inquiries at the time of the first report; its October 24 disclosure is covered in the update below.

Update: what LiteLLM disclosed on October 24

Three days after the trojanized release, LiteLLM published its account of how the attacker got in — and it is a credential-hygiene failure, not a code vulnerability. A master key for its Agent Platform was committed to a public repository on May 27, 2026. The commit was later force-pushed, but the key was never revoked. That unrevoked key opened the experimental Agent Platform, which stored a GitHub CLI OAuth token belonging to the organization owner — with no scope restrictions, so it carried owner-level rights across every BerriAI repository.

From there, the chain ran through LiteLLM’s own internal deployment: LiteLLM says an innocuously named user account in that deployment was exposed to the public internet, and the attacker likely reached the GitHub CLI OAuth tokens through response bodies logged by that deployment. On October 10 the attacker used the tokens to create disposable branches and siphon OAuth tokens from two maintainer engineers via an external webhook; on October 21 it overrode branch protections, rewired the release pipeline to the lookalike Berri-AI/litellm repository, and published 1.107.0. LiteLLM says all tokens involved have since been revoked, and its private enterprise release was not affected.

Two numbers now pin down the scale. Wiz, citing ClickPy data, counts roughly 49,000 downloads of the trojanized release — the PyPI window ran 11:39 to 13:23 UTC, and the poisoned container tags ran 11:46 to about 14:20 UTC. And the theft was not theoretical: Wiz observed the attacker validating stolen AWS credentials between 16:20 and 17:01 UTC on October 21, including sts:GetCallerIdentity checks and Amazon Bedrock model-listing calls — the pattern of LLMjacking, spending someone else’s inference budget. The exfiltration domain was litellm.dev, a lookalike of the project’s real domain. The remote loader’s GitHub dead drop (letters9813/pythonclient-test) was taken down around 13:30 UTC, so the loader is dormant for now — but any machine that ran the payload earlier may already have received a second stage. The attacker has not been publicly named, and Socket notes there is no evidence so far linking this incident to the March attack.

How to check if you were hit

Aikido Security malware hunter Ilyas Makari published the two indicators that matter, and they are refreshingly concrete. Run these on any machine, container, or CI runner where LiteLLM might have been installed or updated on October 21:

  1. /tmp/.pc_once_* — if files matching this pattern exist, the exfiltration already fired. Your credentials left the machine.
  2. /tmp/remote_code_loader.lock — if this file exists, the command-and-control daemon ran or is still running. Assume active compromise, not just past theft.

Socket’s researchers add the scope rule: anyone on 1.107.0 should stop deploying it immediately and investigate every environment where Python ran after installation — that explicitly includes proxy containers and CI runners, the two places LiteLLM most commonly lives in production. The same credential-hygiene logic applies to dormant AI agents whose credentials still work: a credential that still works is a credential that can be stolen.

If neither file exists and you can verify you never installed or pulled 1.107.0 (check pip show litellm / your image digests), you are clear of this incident. If you cannot verify — the honest answer is to treat the environment as compromised.

What to rotate, in order

If the indicators hit, everything on the box is burned. Rotation order matters because some credentials are spendable in seconds and others take work to abuse:

  1. LLM provider API keys first (OpenAI, Anthropic, Cohere, others). These are the most immediately monetizable — an attacker can burn thousands of dollars of inference in minutes, and the keys sit in the exact environment LiteLLM was designed to hold them in.
  2. Cloud credentials: AWS, Google Cloud, Azure. Rotate access keys, service account keys, and check for new resources or users created since October 21 — cloud access is the path to your data, not just your bill.
  3. Database connection strings and other secrets in environment variables. The stealer harvested env vars wholesale.
  4. SSH private keys and GPG keys. These persist beyond any single service and are easy to forget.
  5. Browser-stored passwords. The 16 stealer modules included browser credential stores across all four major browsers. Anything saved in the browser on that machine should be considered exposed.

Then rebuild or reimage the affected hosts — a remote access trojan that phones home hourly cannot be cleaned by deleting two files.

Why this one is worse than a typical PyPI attack

Most Python supply-chain incidents are typosquats: litellm2, lite-llm, a lookalike name that catches the careless. This was not that. The attackers compromised the release process itself, so the malicious code shipped inside the real package, through the real channels, signed by the normal pipeline. Version pinning — the standard defense — would not have helped anyone whose automation pulled “latest” during the window; only a pinned hash or a frozen lockfile from before October 21 would have.

It is also a pattern, not an anomaly. CloudSEK’s analysis of the March 2026 LiteLLM compromise put the potential exposure at more than 2,500 organizations and 434,000 CI/CD pipelines. Two release-pipeline compromises in seven months on a package with 23 million weekly downloads, running with production API keys by design, is a systemic problem with how AI infrastructure software is shipped — not a one-off. It landed the same week as PHP2Shell, two critical flaws in PHP itself, and the same week OpenAI’s own agents disabled their own safety monitoring: the attack surface is now the agent stack itself.

For teams, the durable lessons are unglamorous: pin dependency versions with hashes, not ranges; run package updates through a staging step that diffs the new release against the old one; and treat any gateway that holds API keys as the highest-value target in your environment, because attackers already do.

Sources

Related: Aokigahara, a Windows infostealer profiled by Check Point, now hunts AI-tool logins and session tokens — the same developer machines a poisoned package reaches are the ones holding ChatGPT, Claude and Cursor credentials. If a supply-chain hit worries you, the credential-theft angle is the next check. A vendor-side breach at Warp exposed AI agent logs days later — what agent traces reveal and what affected users should check.

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment