LiteLLM Master Key Leak: How an Unrevoked Secret Led to a Supply-Chain Attack

The LiteLLM master key leak demonstrates how an unrevoked credential can become the starting point for a software supply-chain compromise. A secret exposed in a public GitHub repository in May 2026 ultimately enabled an attacker to obtain organization-owner access, extract additional credentials, and manipulate the release pipeline.

The incident was particularly dangerous because the compromised package installed Python startup files that could execute during normal interpreter initialization. Consequently, starting Python in an affected environment could activate the malicious payload even if the application never explicitly imported LiteLLM.

How the LiteLLM Master Key Leak Escalated Into GitHub Owner Access

The compromise began on May 27, 2026, when a configuration file containing the master key to a LiteLLM Agent Platform deployment was committed to the public LiteLLM-Labs/lite-harness repository. The team quickly identified the mistake and removed the exposed commit from the visible history. However, the master key was never revoked.

That omission allowed the attacker to exploit a credential that should no longer have been trusted.

On October 10, the attacker used the exposed master key to access the LiteLLM Agent Platform API and retrieve a GitHub CLI OAuth token associated with an organization owner’s account. Because the token was not scoped down, it provided access to all repositories in the organization’s GitHub environment at the owner’s privilege level.

The attacker then used GitHub workflows to extract additional secrets from internal repositories. These included credentials associated with two maintainers, expanding the attacker’s access to release operations and other internal systems.

The attacker had progressed from a leaked application secret to multiple privileged identities without needing to compromise every system independently.

How Stolen GitHub Tokens Undermined the LiteLLM Release Pipeline

LiteLLM’s normal release process required branch protection, pull-request approval, passing checks, and approval from a designated account. However, the designated-account requirement had been temporarily relaxed to allow any two engineers to trigger and approve a release. The attacker overrode branch protections and exploited the relaxed approval process to publish the compromised artifacts.

However, the attacker used the organization owner’s token to override repository protections and redirect the release workflow to a lookalike repository, Berri-AI/litellm, instead of the legitimate BerriAI/litellm repository.

LiteLLM had temporarily relaxed its normal release controls to accommodate more frequent bug-fix releases, allowing two engineers to trigger and approve a release. The attacker used the organization owner’s token to redirect the release workflow, then used a second maintainer’s token to approve the production release. A third maintainer’s token was subsequently used to delete the release-run records.

On October 21, the resulting pipeline published the malicious litellm==1.107.0 package to PyPI and compromised container images to Docker Hub and GitHub Container Registry (GHCR). The compromised artifacts originated from the attacker-controlled repository, even though the official GitHub source tag for version 1.107.0 did not contain the malicious files.

This distinction matters: the incident was not simply a vulnerable source-code revision. It was a release-pipeline compromise that allowed malicious artifacts to be distributed through trusted package and container channels.

Why the Malicious LiteLLM Package Could Execute Without an Import

Microsoft Security Research identified the package’s distinctive execution mechanism: malicious files named cook.pth, cook.py, and sitecustomize.py.

The .pth file contained an executable import statement that loaded the malicious Python module during interpreter initialization. The package also included a sitecustomize.py component that provided a separate execution path on Unix-based systems.

As a result, an environment could be exposed even when its application did not explicitly import LiteLLM. Starting Python in an affected environment could activate the credential collector.

The recovered collector targeted authentication material and other sensitive information accessible to the affected process, including:

• Developer-tool and source-control credentials.
• Cloud credentials, workload identities, and environment variables.
• SSH material and selected infrastructure configuration.
• Browser-related data and authentication artifacts.
• Selected LiteLLM proxy database records when the required conditions were present.

The collector encrypted collected data and attempted to transmit it to an attacker-controlled endpoint. The separate Unix-oriented loader could retrieve and execute additional Python code, although Microsoft reported that this second-stage retrieval and execution had not been confirmed.

These findings establish the payload’s capabilities and execution design. They do not prove that every system that downloaded the package experienced successful credential theft or exfiltration.

Which LiteLLM Releases and Environments Required Investigation?

LiteLLM identified specific affected release windows and artifacts. Organizations should assess package versions, installation times, container digests, and whether Python actually started in the affected environments.

LiteLLM reported that the compromised public artifacts had been removed and that customers running its private enterprise release were not affected.

However, removing malicious artifacts from public registries does not establish that previously installed copies are clean. Nor does checking the installed LiteLLM package directory alone rule out residual startup files elsewhere in the Python environment.

How Enterprises Should Investigate the LiteLLM Supply-Chain Compromise

The response must address both the compromised software and the credentials that the payload could access.

1. Identify every affected artifact. Search installed environments, package caches, internal mirrors, lock files, build outputs, and container images. Compare the findings against LiteLLM’s confirmed affected versions and image digests.

2. Contain potentially affected workloads. Isolate suspect developer workstations, build agents, test systems, containers, and gateway hosts. Avoid starting Python or invoking pip within a suspected environment during evidence collection, because interpreter initialization itself could activate the malicious code.

3. Rebuild from verified artifacts. Recreate affected environments from a verified clean release. Check for residual cook.pth, cook.py, and sitecustomize.py files in Python library paths. Do not assume that removing the LiteLLM application directory clears every malicious component.

4. Rotate potentially exposed credentials. From a known-clean system, revoke and replace source-control tokens, CI/CD secrets, cloud credentials, model-provider API keys, registry credentials, SSH keys, and other secrets accessible to the affected identities. Revoke relevant sessions as well, since rotating a password or key might not invalidate every active session.

5. Strengthen software provenance controls. Pin dependencies, verify package provenance and container image signatures, and prefer immutable image digests over mutable tags. Restrict release permissions and separate build, approval, and publication privileges wherever practical.

Organizations should also consider separating release privileges and requiring independent approval to reduce the risk of a single compromised identity undermining the release process.

Where Hexnode XDR and UEM Fit Into LiteLLM Incident Response

The LiteLLM incident affected software distribution, developer environments, credentials, and CI/CD infrastructure. Hexnode XDR can support endpoint investigation and response, while Hexnode UEM supports managed-device administration and custom-script execution.

These capabilities address the endpoint side of incident response. The reviewed documentation does not establish native workflows for revoking compromised source-control credentials, repairing CI/CD pipelines, or remediating Python package and container-image compromises.

Use Hexnode XDR to investigate suspicious endpoint activity

Hexnode XDR supports Windows and macOS endpoints. Its Investigate capabilities allow administrators to examine available process and file telemetry, while documented response actions include endpoint isolation and process termination. These capabilities can support investigation when a managed endpoint may have executed the compromised package.

Security teams can use Hexnode XDR to investigate available process and file telemetry on managed endpoints, using relevant evidence to assess suspected compromise. Investigating Python-related activity depends on the available telemetry and administrator-defined queries; this does not constitute dedicated Python malware detection. If the evidence warrants containment, administrators can isolate the device while investigating the scope of exposure.

However, this is an investigation workflow, not a claim that Hexnode XDR automatically detects the LiteLLM package, identifies leaked GitHub secrets, or detects upstream release-pipeline manipulation. Linux workloads and container infrastructure also require appropriate investigation coverage beyond Hexnode XDR’s documented Windows and macOS endpoint support.

Featured resource

Introduction to Hexnode XDR

Explore how Hexnode XDR combines proactive device management with threat detection and response to help IT teams investigate incidents and strengthen endpoint security.

Download the Presentation

Use Hexnode UEM to support endpoint verification

Hexnode UEM supports custom-script execution on supported Windows endpoints and macOS devices. Administrators can deploy appropriately developed and validated scripts to collect specified endpoint information, subject to the relevant platform requirements and script limitations.

Administrators can use Hexnode UEM’s custom-script execution capability on managed Windows and macOS devices to run appropriately developed and validated scripts for endpoint evidence collection. Identifying LiteLLM-related artifacts requires custom investigation logic; Hexnode UEM does not provide a documented, dedicated LiteLLM verification feature. Scripts should use trusted operating-system tools and must not invoke a potentially affected Python interpreter during evidence collection.

Hexnode UEM supports custom-script execution on supported Windows and macOS devices. The reviewed documentation does not establish a dedicated native workflow for Python dependency management, package provenance verification, or container-image remediation. Organizations must update their deployment workflows, rebuild affected environments, and rotate compromised credentials independently.

FAQs

An Unrevoked Secret Should Never Remain a Trusted Credential

The LiteLLM master key leak became a supply-chain incident because an exposed secret remained valid, unlocked a highly privileged token, and enabled further credential extraction. Those credentials then helped undermine release controls that were designed to protect published artifacts.

The practical lesson is to treat secret exposure as an incident requiring revocation, not merely a repository cleanup task. Enterprises should combine least-privilege credentials and controlled release workflows with verified software artifacts, credential rotation, and endpoint investigation. Hexnode XDR and UEM can support the endpoint side of that response, while source-control, CI/CD, package-management, and identity teams address the compromised trust relationships directly.