LiteLLM Supply Chain Attack Linked to Suspected GitHub Token Exposure in AI Gateway Logs
LiteLLM has disclosed a new software supply chain attack in which threat actors compromised its release infrastructure to distribute a malicious version of the widely used open-source AI gateway. The incident, discovered on October 21, 2026, involved the publication of poisoned Python packages and Docker images containing credential-stealing malware and a persistent backdoor. Investigators suspect that GitHub authentication tokens inadvertently exposed through AI gateway logs may have provided the attackers with the access needed to manipulate the project's software release process.
The attack is particularly concerning because LiteLLM serves as an integration layer between applications and multiple large language model providers. Organizations use the platform to manage AI requests, credentials, routing, and model access across different services. Compromising its distribution pipeline therefore creates opportunities to reach developers, cloud environments, and enterprise AI infrastructure through software that users ordinarily trust.
According to LiteLLM's investigation, the attackers bypassed several security controls introduced after an earlier supply chain incident in March 2026. The latest compromise demonstrates how stolen developer credentials can undermine protected repositories, signed artifacts, and automated publishing workflows when privileged access is not sufficiently isolated.
How Attackers Compromised LiteLLM's Release Pipeline
The malicious release was published on October 21 asLiteLLM version 1.107.0, affecting the Python Package Index (PyPI), Docker Hub, and GitHub Container Registry. The compromised Docker images were distributed under several tags, includinglatest,main-latest, andmain-stable, potentially exposing organizations that automatically downloaded updated images without pinning a verified version.
LiteLLM identified two principal exposure windows. Users who installed an unpinned Python package between 11:39 and 13:23 UTC may have received the compromised release, while affected Docker images were available between 11:46 and 14:20 UTC. Although these publication windows were relatively short, automated build pipelines and container deployment systems can retrieve new dependencies within minutes, making even brief compromises potentially consequential.
The attackers reportedly gained access to three sets of developer GitHub CLI credentials. One credential belonged to a GitHub organization owner and was used to disable branch protections and force-push malicious changes. The attackers then manipulated a publishing workflow to reference a lookalike repository,Berri-AI/litellm, rather than the legitimateBerriAI/litellmproject. This allowed malicious artifacts to pass through the release process and be distributed as apparently legitimate software.
The incident followed a temporary expansion of release permissions on October 19, when LiteLLM authorized two internal engineers to publish daily maintenance updates. Investigators believe this operational change created an opportunity for the attackers to exploit credentials that had already been exposed or obtained.
The case illustrates an important limitation of software signing and protected release pipelines: these mechanisms establish stronger guarantees about how artifacts are produced and distributed, but they cannot independently prevent malicious releases when attackers control the credentials and workflows authorized to produce them.<Cite ref="turn338568view0"/>
AI Gateway Logs May Have Exposed Developer Credentials
LiteLLM's investigation identified a potentially significant connection between its internal AI infrastructure and the stolen GitHub credentials. The maintainers discovered situations in which Anthropic's Claude Code could include a user's GitHub CLI OAuth token in a response body. When those responses were recorded by LiteLLM, the sensitive tokens could subsequently appear in gateway logs.
Investigators also found an unexpected user account within an internal LiteLLM deployment that had become accessible from the public internet. The project's current hypothesis is that attackers gained access to this deployment, extracted GitHub credentials from its logs, and used those credentials to compromise the software publishing pipeline. However, LiteLLM has not conclusively established the initial access mechanism or confirmed precisely how the deployment became publicly exposed.
The distinction between confirmed findings and the suspected attack path is important. The use of compromised GitHub credentials to manipulate the release process is documented, while the theory that those credentials originated from AI gateway logs remains under investigation. LiteLLM has suggested that access to the exposed deployment may have involved a recently patched vulnerability, but the available evidence does not yet establish that sequence definitively.
The suspected mechanism nevertheless reveals a broader security concern surrounding AI development environments. Coding assistants and AI gateways routinely process command outputs, debugging information, configuration data, and other technical material that may contain sensitive credentials. If those values are reproduced in model responses and retained in centralized logs, systems intended to improve developer productivity can unintentionally become repositories of privileged authentication material.
This risk is not unique to Claude Code or LiteLLM. Any AI-enabled workflow that handles developer credentials, cloud secrets, or operational diagnostics requires careful controls over what information enters model contexts, what appears in responses, and how long those responses are retained. Redaction, access restrictions, and secure logging practices are therefore increasingly important parts of enterprise AI security.
Malicious Packages Combined Credential Theft With Persistent Remote Access
Security researchers examining the poisoned release identified two complementary mechanisms designed to execute malicious Python code. The first relied on a.pthfile namedcook.pth, which caused the Python interpreter to import a malicious module during initialization. That module,cook.py, contained obfuscated code responsible for collecting sensitive information from the affected environment.
The credential-stealing component targeted secrets associated with operating systems, browsers, development tools, cloud services, and AI applications. The collected information was transmitted to an attacker-controlled endpoint atlitellm[.]dev/healthcheck, a domain designed to resemble a legitimate service associated with the project.
A second mechanism usedsitecustomize.py, a Python initialization feature that can execute automatically when the interpreter starts. On Linux and macOS, the malicious code attempted to retrieve instructions from a GitHub-hosted file and download additional Python code from an attacker-controlled server. Researchers found that the backdoor was designed to operate as a background process, periodically checking for updated instructions and executing remotely supplied payloads.
The combination of credential theft and remote code execution made the poisoned release particularly dangerous. Even if the malicious package was subsequently removed, credentials captured during its execution could remain usable, while the backdoor could potentially provide continued access to compromised environments.
Researchers at Wiz reported evidence that stolen credentials were being tested approximately four and a half hours after exfiltration. The observed activity included validation of AWS credentials obtained from CI runners and Kubernetes nodes, followed by attempts to enumerate cloud resources and available foundation models. Some requests were consistent withLLMjacking, a technique in which attackers abuse stolen cloud credentials to access AI services and consume computational resources at the victim's expense.
The findings indicate that the campaign extended beyond distributing malicious packages. Attackers were actively investigating how stolen credentials could be used to access additional infrastructure, potentially expanding the consequences of the original supply chain compromise.<Cite ref="turn338568view0"/>
What Organizations Should Do After the Compromise
Organizations using LiteLLM should immediately determine whether version 1.107.0 was installed or whether affected container images were pulled during the identified exposure windows. This investigation should include developer workstations, CI/CD pipelines, container registries, Kubernetes deployments, and automated dependency management systems.
Any environment that executed the compromised release should be treated as potentially exposed. Security teams should remove the malicious package, isolate affected systems where appropriate, investigate suspicious Python initialization files, and review evidence of unauthorized outbound connections. Because the malware was designed to collect credentials, remediation must extend beyond simply reinstalling a clean version.
Affected organizations should rotate credentials accessible to compromised processes, including GitHub tokens, cloud authentication material, API keys, and AI provider secrets. They should also examine cloud audit logs for unusual identity validation requests, unexpected model enumeration, and unauthorized access attempts. Rebuilding compromised environments from trusted images may be necessary when the integrity of the system cannot be established.
The incident also reinforces the importance of verifying software artifacts rather than assuming that an apparently legitimate repository or signed release guarantees safety. Organizations can reduce exposure by pinning dependencies, restricting automated updates to trusted versions, monitoring package integrity, and separating publishing credentials from ordinary development environments.
For companies deploying AI gateways internally, an additional priority is preventing secrets from being captured in request and response logs. Sensitive values should be redacted before storage, logging permissions should follow least-privilege principles, and publicly accessible management interfaces should be avoided unless explicitly required and adequately secured.
The latest LiteLLM compromise demonstrates how traditional software supply chain risks are intersecting with the growing complexity of AI development infrastructure. An authentication token potentially exposed through an AI gateway may have enabled attackers to take control of a trusted publishing workflow, distribute malicious packages, and obtain credentials from downstream environments.
The central lesson is that securing AI infrastructure requires protecting not only models and APIs, but also the developer identities, logs, automation pipelines, and software distribution systems surrounding them. A single exposed credential can transform a localized security weakness into a supply chain incident affecting organizations far beyond the original target.
Incident Timeline: How the LiteLLM Compromise Unfolded
October 19, 2026: LiteLLM temporarily expands publishing permissions for two engineers to support daily maintenance releases, potentially increasing the exposure of privileged credentials.
Before October 21: Attackers obtain GitHub credentials associated with three developers, including an organization owner. The exact method of credential theft remains under investigation.
October 21, 11:39 UTC: Malicious LiteLLM version 1.107.0 becomes available through PyPI.
October 21, 11:46 UTC: Compromised Docker images appear in public container registries, including images distributed through commonly used update tags.
October 21, 13:23 UTC: The identified exposure window for the malicious PyPI package ends.
October 21, 14:20 UTC: The identified exposure window for compromised Docker images ends.
Following the compromise: Researchers identify credential-stealing malware, persistent backdoor functionality, and attempts to use stolen cloud credentials.
The timeline highlights how a relatively short distribution window can create lasting security consequences when malicious dependencies execute inside development pipelines and cloud environments. Although the precise initial access mechanism remains unconfirmed, the incident demonstrates how compromised publishing credentials can rapidly turn trusted software distribution channels into attack infrastructure.