Teams that already survived LiteLLM’s March theft treated Wednesday like a rerun. Same project, same advice, same closed ticket: rotate the keys and get back to feature work. That reaction is the hole. A malicious LiteLLM release landed on PyPI and Docker registries on Wednesday carrying malware built to harvest cloud logins, developer secrets, and API keys for AI services from anyone who installed it. Your cybersecurity program still files an official package bump under maintenance. This one was an intrusion wearing a version number.

Wednesday’s wheel harvested the keys March already mapped

Security researcher Kevin Beaumont said it without the varnish. LiteLLM got compromised again. Help Net Security’s reporting is the part a lot of shops will skim past: the Wednesday drop went to PyPI and to Docker registries. Grep one channel and you miss the other. App teams run pip install. Platform teams run docker pull. Both land in processes that already hold live cloud credentials, because that is how you make an LLM proxy useful.

March already told you the prize. Hudson Rock went through a 153GB archive stolen in that earlier supply chain attack and linked it to 2,488 corporate domains, including AWS, Samsung, Cisco, and Salesforce. Those names are a diagram, not a trophy slide. They show what an LLM gateway can touch when you wire it the way the README suggests: provider tokens, object storage, CI variables pasted into a compose file so the demo does not fail on Monday.

Call it what it is. LiteLLM is a credential vacuum with a friendly CLI. It exists to hold the keys that talk to model APIs, and in too many shops it also inherits the application identity that can read secret stores, buckets, and admin endpoints. Load a harvester into that process and the steal stays quiet. Your SOC is staffed for brute-force noise against the IdP. A successful install of a package you asked for never looks like an alert.

If you rotated after March and kept a floating tag, you ran incident response as a ritual. The new keys sat in the same runtime, fetched by the same unsigned habit: latest, unpinned, pulled because a build broke and someone needed the gateway up. Operators who already have your industry in a stolen archive do not need a fresh zero-day. They need you to treat the second release as a patch.

Ownership is how this persists. AppSec subscribes to PyPI advisories and files tickets against CVE numbers. Platform engineering signs cluster images and argues about admission controllers. The AI stack lives in a third pile: a GPU node, a laptop, a forgotten Actions runner with pip install -U litellm in a setup step. Threat detection never got a use case named “we installed our own tool.” Until cloud consoles show access keys created in a region nobody uses, the install looks like diligence.

Your cybersecurity stack still blesses the install

Most cyber security scorecards still bottom out at the edge. There is a firewall, a threat-protection license, MFA on the VPN, and a dashboard that lights up when strangers hammer SSH. Useful. Incomplete. None of those controls parse the tarball a runner fetched because a job YAML named LiteLLM. Defense in depth that stops at the perimeter is one layer with a budget line for “depth.”

AI tooling made the blind spot worse on purpose. Speed is the product. READMEs say copy this compose file. The compose file mounts a home directory and exports every key the human has used this quarter. Security hardening for that pattern is supposed to mean short-lived tokens, scoped roles, and a deny on any instance permission that inference does not need. What you actually get is a long-lived access key in a .env that has been copied into four repos and a shared chat channel.

SCA does not save you if it allowlists the package name. Name trust is how a second malicious release works. The identifier is famous. The digest is new. A policy that says “LiteLLM is approved” approved the next implant in advance. Private indexes that pull-through cache upstream without pinning hashes do the same job with extra steps. They launder the malicious wheel into an internal URL your developers are trained to trust.

After March, plenty of teams rotated, posted a postmortem, and went back to floating tags because pinning “slows the researchers.” That is a choice about whose time you value. The people who walked out with 153GB already know you will trade a digest pin for a working notebook. Wednesday is what that trade costs when the publisher’s pipeline is the delivery path.

Pin the digest, starve the process, prove the rotation

You do not need a new product for this. You need evidence. Start with the hosts, then the identities those hosts could use, then the pipeline that will try to install the next “fix” unattended.

The next four hours

1. Inventory every laptop, CI runner, notebook host, and container that pulled LiteLLM from PyPI or Docker during the malicious window. If your logs are thin, start in March and work forward. Name the image tags, wheel versions, and accounts that performed the pulls.
2. Take those runtimes off the network path. Snapshot only if you have a legal or IR reason to keep the disk. Rebuild from a known-good base. An in-place upgrade on a box that already ran the bad wheel leaves you arguing with a process you no longer control.
3. Rotate every secret that process could read: cloud IAM users and roles, AI provider API keys, tokens in env files, CI variables, webhooks, and anything injected into the container environment. Scope the replacements. A replacement god key so the demo works by lunch repeats March with new identifiers.
4. Hunt egress and identity use around the install timestamps. Look for unusual AssumeRole calls, newly created access keys, tokens posted to throwaway webhook hosts, and outbound connections from build agents that should only talk to your registry and your model endpoint.

Then change the default so Wednesday cannot recur as a calendar event. Pin package hashes and image digests in lockfiles and deployment manifests. Disable floating tags in the clusters that run inference. Put an internal registry in front of PyPI and Docker Hub, and only promote artifacts you have fetched, hashed, and recorded. Treat a package bump on a credential-bearing gateway as a production change, with the same approval you would demand for a firewall rule that exposes a database.

Starve the process. Whatever you run in LiteLLM’s seat should hold model-provider credentials and nothing else. No org-wide cloud admin. No IAM enumeration. No mount of a developer’s SSH directory. If inference needs an object in a bucket, give it a role that can read that prefix. Broader access belongs in a throwaway account you can burn without a change advisory.

Prove the rotation. A slide that says “we rotated” is how March became Wednesday. Pull cloud audit logs and provider dashboards and show that the old keys are dead, that new keys were created after the rebuild, and that the rebuilt hosts are the only ones using them. Incident response that cannot show that evidence is a status meeting.

Frequently Asked Questions

We never deployed LiteLLM. Can we ignore Wednesday?

Ignore the package name, not the pattern. Any AI gateway, SDK, or helper that holds provider keys plus cloud credentials is the same class of target. Inventory those processes, how they get their code, and which identities they inherit before you declare yourself out of scope.

We rotated cloud keys. Can the old hosts stay up?

The malicious wheel ran in those processes. Secrets in memory, in env, in volume mounts, and in local caches may still be live, and so may a foothold. Rebuild from known-good images, then introduce the new keys only on the rebuilt systems.

Should we block PyPI and public Docker Hub?

A blanket block with no internal promote path pushes people onto laptops and shadow installs. Put a registry in front, pin digests, and make the blessed path faster than the rogue one. Blocking without that path just moves the next compromise off your logs.

Sources

• LiteLLM hit by second supply chain attack this year, users urged to rotate credentials