LiteLLM supply chain attack traced to unrevoked master key and webhook exfiltration

LiteLLM disclosed a critical supply chain compromise on October 24, 2026, stemming from a master key leaked in May. An attacker used this access to inject malicious code into version 1.107.0 of the popular Python package, targeting developer credentials and system environments.

What happened

The incident began on May 27, 2026, when a configuration file containing a master key for the LiteLLM Agent Platform was accidentally committed to a public GitHub repository. Although the team quickly force-pushed over the commit and identified the need for revocation, the master key itself was never revoked. On October 10, 2026, an attacker operating from IP address 69.48.229.143 used this still-valid key to access the Agent Platform. From there, they extracted a GitHub CLI OAuth token that was not scoped down and was associated with the organization owner’s account.

With owner-level access, the attacker executed a series of stealthy operations. On October 10, they created short-lived branches in internal repositories to run workflows designed to harvest additional credentials. These branches were deleted within minutes, leaving little trace in standard history. By October 21, the attacker had overridden branch protections and altered the release pipeline to point to a lookalike repository. They used stolen engineer tokens to trigger and approve the release of LiteLLM version 1.107.0 to PyPI, Docker Hub, and GHCR before deleting production records to cover their tracks.

The malicious package was quarantined by PyPI and removed from container registries later that day after being reported by security researchers. LiteLLM confirmed that the attacker could have loosened release restrictions further but likely avoided doing so to evade detection. The company is now working to revoke every token associated with its internal systems and vendor platforms.

How it works

The attacker’s primary method for stealing credentials involved injecting malicious GitHub Actions workflows into throwaway branches. These workflows, named cache.yml, were configured to run on every push. They harvested secrets such as API keys for Anthropic, OpenAI, AWS Bedrock, and GitGuardian, as well as database credentials and browser session states. The stolen data was exfiltrated to attacker-controlled endpoints on webhook.site, a service that allows users to inspect incoming HTTP requests.

Once published, the compromised LiteLLM version 1.107.0 contained malware that executed automatically when Python started, even if the library was not imported. The malware included a credential harvesting module that scanned for authentication material across developer tools, cloud environments, and browsers. It also installed a Unix-oriented backdoor that fetched and executed arbitrary code from the attacker’s server every hour. This meant that simply starting Python in an affected environment could activate the malicious code, extending the risk beyond active LiteLLM deployments.

Key details

• The initial breach vector was a master key leaked on May 27, 2026, which was never revoked despite being identified as exposed.
• Attackers used webhook.site endpoints to exfiltrate stolen credentials, including API keys and database passwords.
• Malicious workflows were pushed to short-lived branches and deleted within minutes to avoid detection in repository history.
• The compromised package version 1.107.0 was published to PyPI and container registries on October 21, 2026.
• The malware executes on Python startup and includes a backdoor that communicates with litellm.dev every hour.
• Stolen credentials included access to Linear, Together AI, and secret-scanning platforms like GitGuardian.

Why it matters

This incident highlights the severe risks of inadequate key management and overly permissive CI/CD pipelines. The failure to revoke a known compromised key months after its exposure allowed the attacker to maintain persistent access. For engineering teams, this underscores the importance of treating key rotation as a critical security control rather than an optional maintenance task. It also demonstrates how relaxed release controls, even for temporary convenience, can create vulnerabilities that attackers exploit to bypass multi-person approval processes.

The use of webhook-based exfiltration shows how attackers leverage legitimate debugging tools to steal data without triggering traditional security alerts. Since the data was sent to external webhook endpoints, it bypassed internal network monitoring. Developers and security engineers must recognize that any service capable of receiving HTTP requests can be used as a data exfiltration channel. Understanding how these requests are structured and what they contain is essential for detecting and preventing such attacks.

What you can do

• Audit all CI/CD pipelines for overly broad permissions and ensure tokens are scoped to the minimum required access.
• Implement automated key rotation and immediate revocation protocols for any credentials exposed in public repositories.
• Monitor for unusual workflow executions, especially those involving short-lived branches or rapid deletions.
• Inspect outgoing HTTP requests from your build environments to detect unauthorized data exfiltration to external services.
• Verify the integrity of third-party packages by checking hashes and using lock files to prevent unexpected updates.
• Review and restrict access to release pipelines, ensuring that temporary relaxations of security controls are strictly time-bound and monitored.