LiteLLM compromise: check what ran and which keys it could reach

What was affected

LiteLLM reports that its October 21 release pipeline published malicious litellm==1.107.0 wheels and container images. The incident notice identifies credential theft and remote code loading. It lists affected container tags including v1.107.0, latest, main-latest, and main-stable, with registry-specific exposure windows and digests.

A tag's value today cannot establish what ran on October 21. Check deployment records and image digests against the vendor's list. LiteLLM says its private enterprise release was outside the affected distribution path; confirm which registry your deployment actually used.

The corrected account matters

LiteLLM's October 23 investigation supersedes earlier explanations. It traces access to an Agent Platform master key exposed in May that was never revoked. The attacker used it to obtain a GitHub organization owner's token, then acquired additional credentials and changed the release process. The initial theory about tokens coming from internal request logs was corrected.

Our reading is straightforward: removing a secret from a repository leaves an exposed credential usable until it is revoked. Separately, an agent that can submit a pull request should receive credentials limited to that task. An organization owner's token gives the surrounding system much more authority.

KernelHawk's response priorities

If the affected artifact ran, follow the vendor's incident procedure from a clean administration environment. LiteLLM warns that starting Python, including pip, in the affected environment can run malicious startup hooks again. Replacing the package alone leaves credential exposure unresolved.

1. Establish exposure. Preserve deployment times, package records, and image digests. Include build runners, test systems, and developer environments.
2. Contain and rebuild. Isolate affected systems and preserve useful evidence before rebuilding from reviewed artifacts.
3. Revoke accessible credentials. Work from the secrets the process could read: model-provider keys, cloud identities, database access, and release credentials. Issue replacements through a clean system.
4. Review subsequent use. Check those accounts for activity after the exposure window and keep investigating where logs or artifact history are missing.

Related: inventorying the permissions behind AI tools.