A repository can appear clean, artifacts can carry valid signatures, and a release can pass two-person approval while still being compromised. LiteLLM’s incident exposes the shared identity and privilege assumptions beneath those controls. An unrevoked key led through an agent platform to organization-owner access, then through CI to additional maintainer credentials. Initial incident report and The attack chain behind the v1.107.0 LiteLLM release document the event.
LiteLLM · Initial report 2026-10-21; investigation by Oliver Jensen and Mateo Wang, 2026-10-23
Compromised artifacts can differ from the source tag
The confirmed artifacts include seven PyPI wheels for 1.107.0 and affected Docker Hub/GHCR tags. PyPI exposure was approximately 11:39–13:23 UTC; Docker Hub distribution lasted approximately 11:46–14:20 UTC. Registry-specific remediation times matter rather than one universal two-hour interval.
The official v1.107.0 GitHub source tag did not contain the malicious files. Artifacts were built from an attacker-controlled fork. Inspecting the tag or current main therefore cannot establish the safety of binaries previously downloaded. Investigation needs the source repository, commit, workflow run, and actual artifact digest.
Hidden exposure did not revoke the key
A May 27 public commit exposed the master key of an experimental Agent Platform. The team rewrote visible history and identified the need for revocation, but did not revoke this key. On October 10, the attacker used it to read agent configuration and obtain an organization owner’s GitHub CLI OAuth token.
Two failures combined: incomplete revocation and an experimental service holding an excessively privileged personal identity. Removing visible history cannot recall copied secrets. Storing a token inside an internal service does not reduce its authority. This was a post-two-factor-authentication credential, so using it did not repeat the protections of an interactive login.
CI expanded access to other identities
Owner access enabled temporary-branch workflows to export CI secrets from repositories, yielding two additional maintainers’ OAuth tokens. Associated run records were then deleted. One service’s credential failure expanded into control over several apparently independent GitHub identities.
Two-person approval adds a barrier when the identities and privileges remain independent. If the initiating party can obtain the approver’s token, or an owner can disable branch protection, the confirmations can be performed by one attacker through different accounts. The lesson concerns independence of authority, not the general usefulness of multiple approvals.
A legitimate pipeline built from an illegitimate source
On October 21, the attacker changed the private release repository to consume a lookalike malicious fork. A direct push under an ordinary maintainer token was rejected; owner credentials then disabled protections and forced the change. One identity initiated the release and another approved the production gate. The pipeline signed and published its output.
The investigation also says an approval requirement tied to a physical office device had temporarily been relaxed that week for more frequent releases. This increased opportunity, but the owner could potentially change the restriction anyway. A signature establishes that a trusted release path processed an artifact, not that its source repository was correct.
Deleting runs did not erase every record
After publication, the attacker removed staging and production run records and rewrote workflow history. Organization audit logs, token hashes, API requests, and commits retrievable by SHA still supported reconstruction. A fork commit accessible through an upstream repository URL also complicated source interpretation.
Evidence should distinguish current repository state from the state used by a historical build. Agent platforms, code hosting, CI, registries, and inference-provider accounts form a connected control plane. Application deployment logs alone miss authorization changes across those services.
Separate containment from future improvements
The team locked registries, removed most organization members, and proceeded on the assumption that internal credentials could have been exposed. A fuller process-improvement report was still forthcoming, so recommendations such as least privilege, separate release identities, and independent approval should not be presented as completed remediations.
Consumers need exposure decisions tied to artifacts actually installed or run, rather than a currently clean repository. Maintainers need verifiable revocation, enforceable build-source constraints, and retained control-plane evidence. These lessons follow the confirmed chain, not the initial report’s subsequently corrected theory of tokens leaking from logs. Neither official report offers a suitable architecture illustration for this mechanism, so this note remains textual.
Check the dependencies behind release trust
The chain separates three facts that need evidence: who approved a release, which source the pipeline actually consumed, and which artifact a user received. Assuming any one of them can hide source substitution beneath valid signatures and approvals. Build automation should not acquire configuration authority, broad secret access, and approval-rule control merely for maintenance convenience.
An experimental service’s importance is determined by its credentials, not its user count. An internal alpha holding an organization-level token can have organization-wide impact. Low traffic, internal use, and temporary status do not create security boundaries. The same reasoning applies to agents that submit code repairs or dependency updates: each capability needs an appropriately scoped identity.
These are design implications from confirmed events, not claims about unpublished remediations. The timeline should distinguish exposure, recognition that revocation is needed, and revocation becoming effective. A closed handling ticket can otherwise hide the decisive gap.
Supply-chain exposure and operational impact also require separate tracking. Removing an artifact does not resolve the investigation of environments that ran it, while systems that never acquired it should not be assigned identical exposure merely because they use the same project.