LiteLLM supply chain attack steals credentials via leaked GitHub tokens

On October 21, 2026, threat actors compromised the release pipeline of LiteLLM, an open-source AI gateway library, to distribute a malicious version of its software. The attackers leveraged leaked GitHub CLI OAuth tokens, likely harvested from application logs, to bypass security controls and push poisoned artifacts to major package registries.

What happened

The incident began around 4:00 a.m. PST when the attackers published LiteLLM version 1.107.0 to the Python Package Index (PyPI), Docker Hub, and GitHub Container Registry (GHCR). This compromised version contained a credential stealer and a backdoor designed to harvest secrets from affected systems. Users who downloaded unpinned versions via pip between 11:39 a.m. and 1:23 p.m. UTC, or pulled specific Docker tags between 11:46 a.m. and 2:20 p.m. UTC, were exposed to the malware.

The malicious code employed a dual-technique approach to ensure persistence and execution. It used a Python path file named "cook.pth" to import a script called "cook.py," which deobfuscated itself to run a routine named "privcollect." This routine gathered system, browser, cloud, and AI tool secrets, exfiltrating them to a attacker-controlled domain. Additionally, on Linux and macOS machines, the malware executed "sitecustomize.py" to fetch further instructions from a GitHub repository, establishing a remote access trojan that polled for new commands every hour.

LiteLLM maintainers traced the breach to a combination of operational changes and log exposure. Although the project had recently hardened its release pipeline by signing images and using private repositories, permissions were temporarily expanded to allow two engineers to publish daily bugfixes. The attackers accessed three sets of developer GitHub CLI credentials, suspecting these tokens were embedded in response bodies logged by an internal LiteLLM deployment exposed to the internet. One token belonging to an organization owner allowed the attacker to disable branch protections and force-push malicious changes to a lookalike repository, tricking the CI/CD workflow into signing and publishing the poisoned artifacts.

Key details

• Compromised versions: LiteLLM v1.107.0 on PyPI; v1.107.0, latest, main-latest, and main-stable on Docker and GHCR.
• Impact window: PyPI users between 11:39 a.m. and 1:23 p.m. UTC; Docker users between 11:46 a.m. and 2:20 p.m. UTC on October 21, 2026.
• Malware behavior: Harvests credentials via "privcollect" and establishes a hourly beacon to a command-and-control server using GitHub as a dead drop.
• Attack vector: Leaked GitHub CLI OAuth tokens found in LiteLLM logs were used to authenticate and manipulate the release workflow.
• Post-exploitation: Stolen AWS credentials were validated within 4.5 hours, with attackers performing LLMjacking activities such as listing foundation models.
• Mitigation status: GitHub takedown the malicious repository around 1:30 p.m. UTC; LiteLLM has since revoked permissions and rotated credentials.

Background

Supply chain attacks target the dependencies and build processes of software rather than the end-user applications directly. In this case, the attackers did not need to exploit a vulnerability in the LiteLLM code itself but instead compromised the mechanism used to distribute it. By injecting malicious code into the official package, they trusted by thousands of developers, they ensured widespread distribution without raising immediate suspicion.

The use of GitHub CLI OAuth tokens highlights a common risk in modern development workflows. These tokens grant programmatic access to GitHub resources and can be highly privileged. When such tokens are inadvertently logged in plain text—often by AI coding assistants or verbose application logs—they become easy targets for attackers scanning for accessible credentials. Once obtained, these tokens can bypass multi-factor authentication if the session is still active, allowing attackers to act as legitimate developers.

Why it matters

For teams running their own software, this incident underscores the fragility of trust in open-source dependencies. Even projects with robust security practices, such as signed artifacts and immutable tags, can be compromised if human-operated workflows are weakened. The temporary expansion of release permissions, intended to improve developer velocity, created an attack surface that adversaries exploited. This serves as a reminder that convenience features in CI/CD pipelines must be carefully scoped and monitored.

Furthermore, the exposure of credentials through logging is a persistent hygiene issue. Many self-hosted applications and AI gateways log request and response bodies for debugging purposes. If these logs contain sensitive tokens or keys, any breach of the logging infrastructure—or even accidental public exposure of a debug endpoint—can lead to catastrophic compromise. Teams must assume that logs are potential secret stores and treat them with the same security rigor as database contents.

The speed at which the attackers utilized stolen credentials demonstrates the urgency of incident response. Within hours of exfiltration, the adversaries were actively enumerating cloud resources and validating access. For IT and DevOps leads, this means that detection and rotation mechanisms must be automated and immediate. Waiting for manual investigation before rotating keys allows attackers ample time to establish persistence and move laterally within cloud environments.

What you can do

• Check installed versions: Immediately verify if LiteLLM v1.107.0 or any of the affected Docker tags are present in your environment and remove them if found.
• Rotate all credentials: Assume any secrets stored on systems that ran the compromised version are exposed. Rotate API keys, cloud credentials, and GitHub tokens immediately.
• Audit logs for tokens: Review your application and AI gateway logs to ensure no OAuth tokens or secrets are being recorded in plain text. Implement log sanitization filters.
• Restrict release permissions: Avoid temporary expansions of release privileges. If necessary, use short-lived, scoped tokens and require additional approval steps for publishing to public registries.
• Pin dependency versions: Always pin specific versions of third-party libraries in your requirements files to prevent automatic installation of potentially compromised updates.
• Monitor for suspicious activity: Check cloud audit logs for unusual API calls, such as unexpected model listings or IAM enumeration, which may indicate LLMjacking attempts.