Exposed Master Key Triggers LiteLLM Supply Chain Attack, Distributing Info-Stealer Malware

Exposed Master Key Sets Stage for Multi-Month Attack

LiteLLM traced last week's supply chain attack to an exposed master key accidentally committed to a public GitHub repository on May 27, 20261

1

. The configuration file containing the master key belonged to an open source tool used internally by the AI gateway provider to orchestrate AI agents. While LiteLLM's developers quickly spotted the error and removed the exposed commit, they failed to revoke the master key itself—a critical oversight that would enable the entire attack chain2

2

.

On October 10, 2026, a threat actor operating from IP address 69.48.229.143 used this unrevoked key to gain access to LiteLLM's Agent Platform and extracted a GitHub CLI OAuth token2

2

. The stolen GitHub tokens proved especially dangerous because they are "post-2fa," meaning they don't trigger GitHub's sudo mode authentication flows typically required to perform high-impact repository actions1

1

. This gave the attacker owner-level access to all repositories in LiteLLM's GitHub organization without raising immediate suspicion.

Hijacked Release Pipeline Distributes Malicious Package

Between October 10 and October 12, the attacker authored commits into throwaway branches on internal repositories to run workflows designed to steal additional GitHub CLI OAuth tokens associated with two engineers with maintainer privileges2

2

. On October 21, 2026, the attacker overrode branch protection and altered the release pipeline, setting the source to a lookalike repository "Berri-AI/litellm" rather than the legitimate "BerriAI/litellm"2

2

.

LiteLLM version 1.107.0 was published to PyPI at 11:39 UTC and remained available until 1:23 p.m. UTC when PyPI quarantined the compromised package3

3

. During this window of less than two hours, the malicious package received approximately 49,000 downloads1

1

. Docker Hub and GHCR images were also published, with tags v1.107.0, latest, main-latest, and main-stable pointing to compromised image indexes from 11:46 UTC until removal3

3

.

Info-Stealer Malware Targets Cloud and AI Credentials

The compromised PyPI package and Docker images contained sophisticated info-stealer malware designed to harvest sensitive credentials across multiple platforms4

4

. The attacker modified only the installation package, placing three malicious files—cook.pth, cook.py, and sitecustomize.py—in the environment's Python library directory3

3

. These files executed automatically every time Python was launched in the environment, even when users ran Python or pip to investigate an affected installation.

The credential stealer targeted browser credentials and cookies from Chrome, Firefox, Edge, and Safari, along with AWS credentials, Google Cloud Platform service account keys and application default credentials, and Microsoft Azure tokens1

1

. It also swiped API keys for OpenAI, Anthropic, Cohere, and other LLM providers, plus SSH private keys, GPG keys, and shell history files4

4

. The stolen data was encrypted using AES-256-CBC, with the encryption key wrapped using an RSA-4096 public key, before being exfiltrated via HTTP POST to litellm.dev/healthcheck3

3

.

Remote Access Trojan Enables Ongoing Control

Beyond credential theft, the malicious package included a remote access trojan capable of executing arbitrary code on infected machines5

5

. The sitecustomize.py file spawned a background daemon that polled the attacker's infrastructure every hour for new commands to execute4

4

. This daemon acquired a lock at /tmp/remote_code_loader.lock to prevent multiple instances, then entered an infinite loop fetching the attacker's current command-and-control domain from a GitHub repository and executing Python payloads from the specified domain5

5

.

Wiz researchers observed abuse of stolen credentials starting approximately 4.5 hours post-exfiltration, with the attacker validating AWS instance role credentials captured from compromised CI runners and Kubernetes nodes between 4:20 p.m. and 5:01 p.m. UTC5

5

. Each credential was checked with AWS Security Token Service calls, followed by attempts to list foundation models—consistent with LLMjacking attacks targeting AI infrastructure.

Widespread Impact Across AI Development Ecosystem

LiteLLM is a massively popular project with 61,800 GitHub stars and 92 million monthly downloads on PyPI, used by high-profile companies including NVIDIA, Netflix, AT&T, and Okta3

3

. The AI gateway provides a common interface for LLM providers including OpenAI, Anthropic, and Google Gemini, receiving about 23 million weekly downloads4

4

. This widespread adoption means compromised installations could run alongside LLM provider API keys, cloud credentials, and database connection strings, exposing vast amounts of sensitive data.

Multiple application security companies detected the attack within six minutes of publishing the malicious version3

3

. Security researchers from Aikido, Wiz, and Socket published extensive threat-hunting and mitigation instructions for affected organizations. The most recent safe version is 1.106.2, and LiteLLM developers are revoking every token associated with every internal system and vendor platform in response to the breach1

1

.

Second Major Breach Raises Security Concerns

This marks the second major security incident for LiteLLM in 2026. The project previously suffered a breach in March when the TeamPCP hacking group published malicious versions on PyPI after breaching Aqua Security's Trivy vulnerability scanner used in LiteLLM's CI/CD pipeline3

3

. That earlier compromise potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines worldwide, according to CloudSEK.

LiteLLM maintainers acknowledged that the incident provided "a strong illustration of the risks associated with failing to rotate a potentially exposed key"1

1

. Post-incident analysis revealed that Claude Code embedded GitHub CLI OAuth tokens into response bodies in specific situations, and when response bodies were logged, these tokens appeared in LiteLLM logs5

5

. Organizations using version 1.107.0 should immediately stop affected deployments, investigate environments without launching the Python interpreter, isolate infected systems, rebuild from clean backups, and rotate all exposed secrets.