One Unrevoked Key, 49,000 Downloads: The LiteLLM Teardown

What Happened

LiteLLM, a popular open-source AI gateway, experienced a supply chain attack due to a master key accidentally committed to a public GitHub repository. This key was linked to an internal tool LiteLLM used for orchestrating AI agents. Although the team removed the commit, they failed to revoke the key.

This oversight is the crux of the issue. Removing a commit doesn't eliminate the secret. Anyone who copied the key while it was public retained access. An attacker later exploited this key to access the LiteLLM Agent Platform, extracted a GitHub CLI OAuth token, and gained owner-level access to all repositories in LiteLLM's GitHub. They uploaded a compromised version (1.107.0) of the gateway to PyPI and container registries, which included an infostealer and a remote access trojan. PyPI quarantined it in under two hours, but about 49,000 downloads had already occurred, according to Wiz.

Timeline

• May 27: A configuration file with a master key is committed to the public LiteLLM-Labs/lite-harness repository. Developers notice and remove the commit but leave the key active.
• October 10: The attacker uses the key to access the LiteLLM Agent Platform, extracting a GitHub CLI OAuth token and gaining owner-level access across the organization's repositories.
• After October 10: Malicious commits are made on internal repos, harvesting tokens and secrets during CI. This yields OAuth tokens for two engineers with maintainer privileges and several other internal systems. Activity focuses on upstream inference API tokens.
• Last Wednesday: Version 1.107.0 is published to PyPI and container registries. It is quarantined in under two hours, after about 49,000 downloads.
• Friday: LiteLLM publishes its postmortem and begins revoking every token tied to every internal system and vendor platform.

The gap between May 27 and October 10 is significant. The exposed key was live for months before it was used. It's unclear from public records whether anyone else accessed it during that time.

Which Controls Failed or Were Missing

Revocation after exposure. This was the primary failure. Removing a commit addresses the symptom. Once a secret is public, it must be treated as compromised, regardless of how quickly the commit is removed.

Detection of anomalous use. The key was idle for months before being used to access an internal platform. There's no indication that this use triggered an alert. A master key authenticating from an unfamiliar context should raise a high-priority alert.

Token scope and lifetime. The GitHub CLI OAuth token provided owner-level access across all repositories. These tokens bypass the sudo mode authentication flows usually required for high-impact actions. One stolen token circumvented the control designed to prevent such actions.

CI secret exposure. Workflows exposing tokens and secrets during continuous integration allowed the attacker to harvest further privileged identities, including tokens for two maintainers.

Release integrity. With maintainer-level identities, malicious changes appeared legitimate. Publishing to PyPI and the container registries didn't prevent a trojanized build from being released.

What the Relevant Standard Requires

ISO 27036 addresses information security in supplier relationships, applying to both LiteLLM as a supplier and every enterprise using its package as a dependency.

For suppliers, the standard mandates that security obligations and controls over shared assets, credentials, and delivery channels are defined and enforced. A credential known to be exposed and left active is an unenforced control. For acquirers, the standard expects you to understand your suppliers' protective measures and verify them.

SR 23-4 and the EBA Outsourcing Guidelines emphasize risk-based oversight throughout the relationship, not just during selection. SR 23-4 requires Continuous Monitoring of Active Arrangements and an incident response path when a supplier is compromised. The EBA guidelines require monitoring and Right to Audit capabilities to see how a provider handles credentials and releases. Neither document prescribes a rotation interval, but they expect controls to match the service's criticality.

If an AI gateway manages your model provider API keys, it's a high-criticality component. Your Criticality Classification should reflect that, and your oversight should scale accordingly.

Lessons and Action Items for Your Team

For your own secrets:

1. Treat exposure as compromise. Include a rule in your incident procedure: any secret appearing in a public location is revoked and reissued immediately, even if the commit is deleted quickly.
2. Make Access Revocation a tracked task. "Remove commit" and "revoke key" should be separate checklist items with separate owners to avoid confusion.
3. Scan for secrets before they land. Use pre-commit and repository-level secret scanning to catch exposure at the source.
4. Narrow token scope. Audit where owner-level or post-2FA tokens exist and replace them with scoped, short-lived credentials where possible.
5. Isolate CI secrets. Limit which secrets workflows can access and require review for changes to workflow definitions.

For your vendors:

1. Ask about post-exposure procedures. Add questions to your SIG Core follow-ups and Pre-Contractual Assessment: when a credential is exposed, is revocation mandatory? Who verifies it?
2. Verify release integrity controls. Ask how a vendor prevents a single compromised maintainer identity from publishing to a registry.
3. Build Continuous Monitoring of Active Arrangements around dependencies, not just vendor questionnaires. Know which open-source components feed your critical services, and pin or verify versions rather than pulling the latest automatically.
4. Pre-write your response. If you used version 1.107.0, assume every credential reachable from that system is stolen. This includes cloud credentials, service account keys, browser data, and LLM provider API keys. Have a Vendor Breach Management runbook to rotate all of them quickly.
5. Contract for notification. Ensure agreements set a Notification Timeline and Termination Rights that apply when a supplier's compromise affects your environment.

The lesson isn't that open source is unsafe. It's that a single unrevoked credential turned a cleanup into an incident affecting tens of thousands of downstream systems. LiteLLM's conclusion, that this was a failure to rotate a potentially exposed key, is the standard to hold yourself and your suppliers to.