A poisoned LiteLLM release exposed users to credential theft and remote access. The attack began with a master key accidentally published in a public repository in May and removed without being revoked. The attacker later used that key to obtain a privileged GitHub token and compromise additional identities and systems. Version 1.107.0 received about 49,000 downloads before it was quarantined.
What Happened
LiteLLM traced a software supply-chain attack to a master key that had been committed to a public GitHub repository on May 27. The project removed the exposed commit after discovering the mistake, but it did not revoke the key. The key belonged to an internal open-source tool used to orchestrate AI agents, so deletion of the public file did not remove the credential’s authority.
On October 10, an attacker used the still-valid key to access the LiteLLM Agent Platform and extract a GitHub command-line OAuth token. That token provided owner-level access across the project’s repositories. Because the token was already past two-factor authentication, it did not trigger the additional authentication flows normally associated with high-impact repository actions.
The attacker used the access to create malicious commits and workflows intended to steal tokens and secrets available during continuous integration. This led to the compromise of GitHub tokens associated with two engineers who had maintainer privileges, along with tokens for other internal systems. Actions appeared to come from legitimate, credentialed engineers, reducing the visible distinction between authorized work and attacker activity.
A poisoned LiteLLM version, 1.107.0, was then published to the Python package index and container registries. It included an information stealer and a remote access trojan capable of running arbitrary code. The package was available on the Python index for less than two hours before quarantine but received about 49,000 downloads during that period, according to Wiz.
Why It Matters
The compromised package targeted high-value credentials available on developer and AI systems. Its collection capabilities included browser credentials and cookies, AWS credentials, Google Cloud service account keys and application credentials, Microsoft Azure tokens, and API keys for OpenAI, Anthropic, Cohere, and other model providers.
That creates a risk beyond the machine where the package ran. A developer workstation or build environment may hold access to repositories, cloud services, deployment systems, and external AI platforms. Stealing those credentials can give an attacker several paths for continued access.
The incident also shows how legitimate identity can conceal malicious behavior. Once the attacker held privileged tokens linked to real engineers, repository changes and approvals could appear authorized. Controls focused only on unknown accounts or failed authentication would not fully address that scenario.
The initial error was brief public exposure, but the durable failure was leaving the key valid. Removing a secret from source control limits future discovery; it does not invalidate copies that may already have been collected.
What to Watch
Organizations should determine whether version 1.107.0 was downloaded, installed, or executed in their environments. Download counts indicate potential exposure, but they do not establish how many systems ran the malicious code.
Affected teams should watch for unauthorized use of credentials that were accessible to those systems, including cloud, source-control, browser, and AI-provider access. Repository activity performed under legitimate engineer identities deserves review because the attacker used valid privileged tokens.
LiteLLM said it was revoking every token associated with internal systems and vendor platforms. Further findings may clarify the complete set of affected services and identities. Until that scope is established, potentially exposed credentials should not be assumed safe merely because no obvious misuse has been observed.
What Defenders Should Do
Affected systems: if version 1.107.0 was installed and run, treat every credential available to that host or process as potentially stolen. Isolate and investigate the system, then change passwords and rotate keys, tokens, cookies, cloud credentials, service-account material, and AI-provider API keys within the confirmed access scope.
Source control: revoke affected GitHub tokens and review repository commits, workflows, approvals, and branch activity. Give special attention to changes that appear to have been made by legitimate maintainers because compromised identities were used.
Build systems: inspect continuous integration workflows and the secrets made available to them. Determine whether malicious workflows accessed or exported additional credentials. Review connected internal systems and vendor platforms for use of stolen tokens.
Secret handling: when a credential is committed to a public repository, revoke and replace it immediately. Removing the commit is necessary but insufficient. Record the exposure as an identity incident and investigate whether the key was used before or after discovery.
The Larger Lesson
Software supply-chain security depends on identity containment as much as code review. A single valid key opened access to a platform, which exposed a privileged repository token, which then enabled theft of additional identities and publication of a poisoned release.
The sequence demonstrates why secrets must be treated as compromised once exposed. Teams cannot know who copied a public credential during the period it was available. Revocation removes its authority; deletion alone does not.
It also shows the concentration of risk in developer and AI environments. These systems often connect source code, cloud resources, model providers, and deployment workflows. Least privilege, short-lived credentials, and immediate rotation after exposure can limit how far one mistake travels.