LiteLLM 1.107.0 compromise: credential and AI gateway response

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

LiteLLM's October 21 incident involved malicious release artifacts for version 1.107.0. Treat this as a software supply-chain and credential-exposure investigation. It is a separate event from the earlier LiteLLM incident covered on this blog.

Which artifacts were affected?

LiteLLM identifies all seven 1.107.0 PyPI wheels and specified public container images as affected. Its notice says the PyPI artifacts were available from approximately 11:39 to 13:23 UTC on October 21; container availability differed by registry. The initial post points readers to a later, canonical investigation because some early assumptions were incomplete. Use the artifact details in the official incident notice to establish exposure.

What did the corrected investigation establish?

LiteLLM's October 23 report traces the incident to an administrative key left valid after appearing in public repository history. Access to an internal agent platform exposed a privileged GitHub token; further credentials and release-workflow changes enabled publication of malicious artifacts. This corrects the earlier theory about tokens coming from deployment logs. Source: LiteLLM's canonical attack-chain report.

SafeDep's artifact analysis describes credential theft and a remote-code loader that could run at Python startup, independently of whether the application imports LiteLLM. That is why replacing an application import or downgrading a dependency does not establish that the surrounding host is clean. Source: SafeDep's original analysis.

A containment plan for teams that ran affected artifacts

1. Identify executed artifacts. Use deployment records, image digests, package-install history, runner caches, and developer-environment inventories. A mutable container tag does not establish which image ran last week.
2. Contain the environment. Work with responders to preserve evidence and isolate suspect hosts or workloads. Plan recovery from a verified clean environment rather than treating the compromised runtime as a trusted administration tool.
3. Map accessible credentials. Include provider API keys, workload identities, database credentials, repository access, and downstream service tokens. Follow the vendor's incident instructions and coordinate revocation at each issuing service.
4. Rebuild and verify. Restore from trusted artifacts, check credential invalidation, and monitor privileged activity and unexpected provider usage. Document unknowns; an absent indicator does not prove that no execution occurred.

The AI-agent security lesson

An agent platform's tool permissions are part of the production security boundary. Review whether a developer credential grants organization-wide power, whether an agent API reveals secrets, and whether a release gate can be bypassed by the same identity it is supposed to constrain.

These are testable authorization questions. An AI and LLM security assessment should describe who can invoke tools, what credentials are reachable, how approval works, and which actions require human review. Prompt-injection testing alone does not cover the complete identity and release chain.

Evidence to ask for in an assessment

Ask for a documented scope, synthetic test identities, sanitized findings, and repeatable checks for the permission boundaries that matter to your deployment. Include build provenance and release permissions where authorized. Keep incident response conclusions separate from results obtained in a later test environment.

FailSafe SWARM supports configured testing across applications, APIs, and AI systems. Review the agentic testing evaluation guide, or the first pentest offer for businesses evaluating an agreed scope.