LiteLLM 1.107.0 Supply Chain Breach: AI Credential Stealer Hit 2 Hours Before Removal — Is Your AI Stack Safe?

On 21 October 2026, the widely-used LiteLLM Python library — the open-source gateway that lets developers route queries to over 100 large language models through a single API — was poisoned at the source. A malicious release, version 1.107.0, was live on PyPI and in official Docker images for approximately two hours, silently harvesting cloud credentials, AI API keys, SSH keys, and browser secrets from every machine that installed it. If your team is building AI-powered applications and you updated your Python environment on 21 October without verifying your package pins, you need to act now.

What Is LiteLLM — and Why Does Its Compromise Matter?

LiteLLM is one of the most popular AI infrastructure packages on PyPI, used by startups, enterprises, and Indian IT shops alike to manage multi-LLM deployments, normalise API responses, and control cost routing across providers including OpenAI, Anthropic Claude, Google Gemini, AWS Bedrock, and Azure OpenAI. Because it sits directly in the data path between application code and AI providers, an LiteLLM installation typically has legitimate access to an organisation’s most sensitive tokens: provider API keys, cloud IAM credentials, database connection strings, and developer SSH keys.

That makes it an exceptionally high-value supply-chain target. When a developer runs pip install litellm — or when a CI/CD pipeline rebuilds a container — it trusts PyPI implicitly. In this attack, that trust was weaponised.

Attack Timeline: From Pipeline Compromise to Credential Theft

Time (UTC, 21 Oct 2026)	Event
~11:39	Malicious LiteLLM v1.107.0 published to PyPI; Docker images pushed to Docker Hub and GHCR
~13:23	Socket and Datadog researchers flag the release; PyPI quarantines the package
~13:30+	LiteLLM confirms compromise; Docker images removed; investigation begins
22–23 Oct	Microsoft, BleepingComputer, Help Net Security publish detailed analyses; LiteLLM urges credential rotation
Ongoing	Root cause of initial OAuth token theft still under investigation

Technical Deep Dive: The Python Startup Hook Trick

What makes this attack particularly insidious is its execution mechanism. Most PyPI supply-chain attacks embed malicious code in the package’s __init__.py, so it only fires when the library is explicitly imported. This attacker went further.

According to Datadog Security Labs and Upwind, the malware injected three Python .pth startup hook files into the LiteLLM wheel packages. Python processes .pth files during interpreter initialisation — before any user code runs and before any specific library is imported. This means:

• The credential stealer activated on every Python process started on the affected machine, not just LiteLLM-specific workloads.
• Containers rebuilt from the poisoned Docker image would carry the payload into production environments.
• On Unix/Linux systems, the RAT component could fetch additional Python payloads and execute them remotely, though Microsoft’s analysis notes this second-stage activity was not confirmed in the wild.

Stolen data was POST-ed to www.litellm.dev — a typosquatted lookalike for the legitimate litellm.ai domain — making it easy for the payload to blend into network logs for teams that do not maintain strict egress allowlists.

How the Attacker Got In: GitHub OAuth Token Theft

LiteLLM’s own post-incident disclosure (published on docs.litellm.ai) states that the malicious release actions were performed through three LiteLLM engineers’ GitHub accounts, apparently using stolen GitHub CLI OAuth tokens. The attacker used these tokens to redirect the automated release workflow to a spoofed repository (Berri-AI/litellm, distinct from the legitimate BerriAI/litellm — note the capitalisation difference). Crucially, the official v1.107.0 git tag does not contain the malicious code; only the PyPI wheels and Docker images — built by the compromised pipeline — were poisoned.

This confirms a pattern seen repeatedly in 2026: CI/CD pipeline credentials are the new perimeter. Attackers do not need to compromise source code repositories when they can seize the keys to the build system itself.

What Was Targeted? A Credential Inventory

Microsoft’s Security Blog describes the stealer targeting “authentication material across developer tools, AI applications, cloud environments, browsers, and infrastructure.” In practice, that covers:

• AI provider API keys — Anthropic Claude, OpenAI, Cohere, Google AI Studio, Mistral
• Cloud IAM credentials — AWS Access Key/Secret, GCP service account tokens, Azure client secrets
• SSH private keys from ~/.ssh/
• Browser-stored credentials and session cookies
• CI/CD secrets — environment variables, .env files
• Container registry tokens (Docker Hub, GHCR)

For Indian enterprises routing LLM workloads through LiteLLM — especially managed service providers running multi-tenant AI gateways — the blast radius is substantial: a single compromised developer workstation or CI runner could expose credentials for dozens of downstream client environments.

What You Should Do Now: Sanjay Seth’s Expert Defensive Checklist

This is not a distant vendor problem. If you run Python-based AI workloads, act on this today.

1. Identify exposure immediately. Run pip show litellm and docker image inspect <image> on all development, CI, and production systems. Check build logs and container image histories for any pull of litellm==1.107.0 between 21 October 2026, 11:39 UTC and 13:23 UTC.
2. Rotate every credential. If a machine ran Python at any point while v1.107.0 was installed, treat all credentials it could access as compromised. Rotate API keys for all AI providers, cloud IAM keys, SSH keypairs, and container registry tokens. This is non-negotiable.
3. Pin your package versions. Add litellm==1.106.2 (the last safe release) to your requirements.txt or pyproject.toml and enforce version hashing (pip install --require-hashes) in CI pipelines.
4. Audit your egress traffic. Look for any POST requests to www.litellm.dev (note: .dev, not .ai) in firewall, proxy, or NDR logs from 21 October onward. Flag any match as a confirmed data exfiltration event.
5. Rebuild affected containers from scratch. Do not merely update the package inside an existing image. Any container built from the poisoned v1.107.0 base should be considered compromised at the filesystem level and rebuilt entirely.
6. Enable PyPI package signing verification. Adopt PyPI’s Trusted Publisher attestation model in your CI pipelines to validate that packages were built from the official repository’s workflow, not a spoofed one. This is the control that would have detected this attack.
7. Apply zero-trust to your AI supply chain. Just as you segment network access for production systems, segment your developer and CI environments behind zero-trust network policies. AI workload secrets should never be co-located with infrastructure credentials.

This is the third LiteLLM supply-chain compromise in 2026 alone (March, June, October). The pattern suggests this project — and open-source AI tooling broadly — is under sustained, targeted attack. Treat your AI dependency graph with the same rigour you apply to network perimeter controls.

Frequently Asked Questions

Am I affected if I didn’t upgrade on 21 October — I was pinned to 1.106.x?

If your requirements.txt or lockfile specifies a version below 1.107.0, and your CI pipeline respects that pin, you are likely not affected via PyPI. However, verify that no upstream container base image or transitive dependency silently pulled v1.107.0. The BleepingComputer analysis confirms that all seven 1.107.0 wheels were malicious, with no safe sub-variants.

Does this affect LiteLLM’s gateway/proxy (self-hosted) deployments?

Yes. The official Docker images for v1.107.0 were poisoned at build time, meaning self-hosted LiteLLM proxy containers built from the official image during the attack window are affected. According to Help Net Security, images on both Docker Hub and GitHub Container Registry were compromised. Any secrets passed into those containers — including your cloud provider API keys — should be rotated.

Is LiteLLM itself untrustworthy going forward?

Not necessarily. The core source code was not backdoored at the repository level — the official git tag for v1.107.0 is clean. The issue was a compromised build pipeline. LiteLLM has committed to publishing signed releases with provenance attestation going forward. Organisations deploying LiteLLM should require signed packages and monitor for future advisories. Three incidents in one year, however, does warrant a risk review of whether a single package should sit at the credential-rich centre of your AI stack.

Is there a CVE assigned to this incident?

As of the latest available reporting (23–24 October 2026), no CVE has been assigned to this specific supply-chain incident. The attack exploited compromised build pipeline credentials rather than a software vulnerability in LiteLLM’s code, which makes CVE assignment atypical. Monitor CISA’s Known Exploited Vulnerabilities catalog and LiteLLM’s official security blog for updates. The earlier June 2026 RCE chain (tracked as CVE-2026-42271) was a separate, distinct vulnerability in the LiteLLM gateway codebase.

---

AI adoption is accelerating across India’s enterprise sector, and LiteLLM sits at the nexus of that growth. An incident like this is a reminder that the AI supply chain deserves the same disciplined, layered defence that you apply to network infrastructure. If you are unsure whether your AI workloads are properly segmented, your CI/CD pipeline secrets are well-governed, or your incident response playbook covers supply-chain scenarios, reach out for a security assessment. At P J Networks, we can help you map your AI-related threat surface, review your dependency governance posture, and build a zero-trust pipeline security architecture — before the next supply-chain attack finds you. You can also explore more threat intelligence and analysis on the Sanjay Seth Insights blog.