Skip to content
בס״ד
Cyber Replay logo CYBER REPLAY
Book a Call
Incident Response 10 min read Published Aug 23, 2026 Updated Aug 23, 2026

LiteLLM Supply Chain Compromise: How the AI Package Breach Worked and What to Do Now

The LiteLLM PyPI compromise shipped credential-harvesting malware in versions 1.82.7 and 1.82.8. Here is the attack, IOCs, and an 8-step response guide.

By CyberReplay Security Team

TL;DR: Two malicious LiteLLM versions (1.82.7 and 1.82.8) on PyPI harvested cloud keys, Kubernetes tokens, and LLM provider credentials from any Python process that loaded them. If you installed LiteLLM during the attack window, treat it as a full credential compromise and rotate everything in priority order.

Table of contents

Quick answer

The LiteLLM breach was a LiteLLM supply chain attack in which an attacker used stolen long-lived publishing credentials to push two malicious versions of the litellm package to PyPI: 1.82.7 and 1.82.8. Version 1.82.7 fired when litellm.proxy was imported. Version 1.82.8 fired on any Python startup through a .pth file. Both versions exfiltrated cloud keys, kubeconfigs, service account tokens, environment variables, and shell history to an attacker-controlled endpoint. If you ran either version, rotate every credential the host could read.

When this matters

This matters for any team that builds AI features. LiteLLM is a popular open source LLM gateway, and it is pulled in directly and transitively by AI agent frameworks, MCP servers, and LLM orchestration tools. Google ADK Python was a confirmed transitive vector through its eval and extensions extras. If your dependency graph includes anything in the AI tooling ecosystem, you should assume exposure until you verify the resolved version. A single short-lived import is enough to lose every secret the process could read, which is why this incident is a forcing function for AI package security across the board.

How the LiteLLM supply chain attack worked

The attacker did not exploit a code vulnerability in LiteLLM itself. They stole long-lived publishing credentials and used them to publish malicious versions directly to PyPI. According to LiteLLM’s security update and the GitHub advisory GHSA-5mg7-485q-xm76, the malicious code was hidden inside a double-base64 payload embedded in a .pth file, which let it execute at Python startup before most static scanners would flag it.

Version 1.82.7 activated when a victim imported litellm.proxy. Version 1.82.8 was broader: it fired on any Python startup because .pth files are processed by the Python interpreter at launch. That means running a test suite, a linter, or even pip in an environment with 1.82.8 installed was enough to trigger the harvester.

The payload read cloud credentials, Kubernetes kubeconfigs and service account tokens, CI/CD publish tokens, LLM provider API keys, application secrets in .env files, developer SSH keys, and shell history. It then attempted cluster-wide lateral movement in Kubernetes and exfiltrated the data to an attacker endpoint. OpenSSF Package Analysis flagged 1.82.8, which helped surface the compromise.

Indicators of compromise

Sweep for these IOCs across every environment that ran LiteLLM during the attack window:

  • Kubernetes pods named node-setup or sysmon
  • Evidence of cluster-wide lateral movement or unexpected pod creation
  • Outbound connections to the attacker-controlled exfiltration endpoint
  • Access to cloud keys, kubeconfigs, service account tokens, environment variables, and shell history by an unexpected process
  • Double-base64 encoded payloads inside .pth files in site-packages
kubectl get pods -A | grep -E 'node-setup|sysmon'
find / -name '*.pth' -exec grep -l 'base64' {} \;

If any IOC is present, treat the environment as compromised and begin credential rotation immediately.

The complete guide to responding to the LiteLLM compromise

Step 1: Confirm exposure. Identify every environment that installed LiteLLM between the publish of 1.82.7 and the release of the clean 1.83.0. Check direct installs and transitive pulls.

pip show litellm

Outcome: a complete inventory of affected hosts, containers, and CI runners.

Step 2: Sweep for IOCs. Run the pod and .pth checks above across every environment, including CI runners and developer workstations. Look for node-setup and sysmon pods and any .pth file containing base64 payloads.

Outcome: confirmed or ruled-out compromise per environment.

Step 3: Rotate credentials in priority order. The harvester took everything the process could read, so rotate in this order:

  1. Cloud root and IAM admin credentials
  2. Kubernetes service account tokens and cluster admin kubeconfigs
  3. CI/CD publish tokens and deploy keys
  4. LLM provider API keys routed through LiteLLM (OpenAI, Anthropic, Google, and others)
  5. Application secrets in .env files and secret managers
  6. Developer SSH keys and shell history artifacts

Outcome: stolen credentials invalidated before they can be reused.

Step 4: Pin a verified clean version. Version 1.82.6 and earlier are clean. Version 1.83.0 and later are published through LiteLLM’s new CI/CD pipeline with isolated environments and stronger security gates. Reinstall with checksum verification. A clean reinstall without --require-hashes does not prove integrity.

pip install --require-hashes 'litellm>=1.83.0'

Outcome: a known-good dependency pinned in every environment, with cryptographic proof of integrity.

Step 5: Fix the root cause in CI/CD. The root cause was stolen long-lived publishing credentials. Replace them with short-lived, scoped credentials or OIDC federation where supported. Enforce isolated build environments, separate publish-time secrets from build-time secrets, and require multi-party approval for releases.

Outcome: a publishing pipeline where a single stolen credential can no longer push malicious packages to PyPI.

Step 6: Enforce allowlists and provenance. Maintain an explicit allowlist of approved packages and versions. Require provenance attestations for high-risk dependencies and verify them at install time. Tools such as Snyk, Mend, and Endor Labs can automate dependency risk scoring and provenance checks.

For any package adoption or version bump, require the release to be at least 14 days old before routine use. If an urgent exception is needed, document it as a break-glass approval with validation and a rollback plan.

Outcome: a dependency baseline where new packages and versions are vetted before they reach production.

Step 7: Map your dependency graph. Build and maintain a full dependency graph so a future compromise can be scoped in minutes, not days. Record which services pull LiteLLM directly and transitively, and which environments ran affected versions. Google ADK Python was a confirmed transitive vector through its eval and extensions extras, and Google released pinned fixes. Your graph should catch the next equivalent.

Outcome: scoping time for the next incident reduced from days to minutes.

Step 8: Align with standards and frameworks. Map your hardening work to recognized frameworks so it survives audits and budget cycles.

Outcome: controls that map to audit-ready frameworks and stay funded across budget cycles.

Common mistakes

  1. Assuming no import means no compromise. Version 1.82.8 fires on Python startup via a .pth file. Running pip or a test runner is enough.
  2. Rotating only the credentials you remember. The harvester took everything the process could read. Rotate in the full priority order above.
  3. Trusting that the official Docker image was hit. It was not. The official LiteLLM Proxy Docker image pins dependencies in requirements.txt. Custom images with unpinned pip install litellm are the exposed surface.
  4. Reinstalling without checksum verification. A clean reinstall without --require-hashes does not prove integrity.
  5. Skipping Kubernetes inspection. The payload attempted cluster-wide lateral movement. If you skip the pod sweep, you may leave attacker workloads in place.
  6. Pinning the scanner but not the publishing credentials. The root cause was stolen long-lived publishing credentials. If you only fix the scanner, the next credential theft repeats the attack.

Next steps

Start with the IOC sweep and credential rotation, then move to the hardening controls. If you need external validation - scoping exposure across CI/CD, containers, and AI agent runtimes, or building a repeatable hardening program - a managed security service provider or incident response retainer can compress days of work into a focused engagement. You can also request a free security assessment to get started, or get direct help if you suspect active compromise at CyberReplay’s incident response page.

FAQ

Do I need to rotate credentials if I only imported litellm once?

Yes, if the version was 1.82.7 or 1.82.8. The 1.82.7 payload fired on import of litellm.proxy, and 1.82.8 fired on any Python startup via a .pth file. A single run is enough for the harvester to exfiltrate everything the process could read. Rotate every credential the host could access, starting with cloud root and IAM admin. Containment does not stop at rotation: also revoke active sessions, force token re-issuance for service accounts, and review access logs for the attack window to catch any follow-on access before credentials were rotated.

Was the official LiteLLM Proxy Docker image affected?

No. LiteLLM confirmed the official Proxy Docker image was not impacted because it pins dependencies in requirements.txt and does not rely on the compromised PyPI packages. Custom images that ran an unpinned pip install litellm during the attack window are exposed. Check your image build history and base layers.

How do I know if a transitive dependency pulled in the bad version?

Run pip show litellm in every environment, including those where you did not install LiteLLM directly. Check the resolved version and lockfile timestamp. Common transitive vectors include AI agent frameworks, MCP servers, and LLM orchestration tools. Google ADK Python was a confirmed vector through its eval and extensions extras, and Google released pinned fixes.

Is LiteLLM safe to use again?

Version 1.82.6 and earlier are clean. Version 1.83.0 and later are published through LiteLLM’s new CI/CD pipeline with isolated environments and stronger security gates. LiteLLM rotated all credentials, moved maintainer accounts, and engaged Google’s Mandiant for forensic analysis. No malicious code was pushed to main. Use 1.83.0 or later, verify SHA-256 checksums, and keep it pinned.

References

Get your free security assessment

If this LiteLLM breach and LiteLLM PyPI compromise is a live priority for your team, schedule your assessment for a focused review. We will map the biggest gaps, assign the first actions, and turn the article into a practical 30-day plan. You can also explore CyberReplay’s cybersecurity services or read more on the CyberReplay blog.

Definitions

  • LiteLLM: An open source LLM gateway and proxy that unifies access to multiple LLM providers (OpenAI, Anthropic, Google, and others) through a single API. It is widely used in AI agent frameworks, MCP servers, and LLM orchestration tools, and is distributed as the litellm package on PyPI.
  • Supply chain attack: An attack where an adversary compromises a trusted software distribution channel, such as PyPI, npm, or a CI/CD publish pipeline, to deliver malicious code to downstream users as if it were a legitimate update.
  • PyPI: The Python Package Index, the official repository for Python packages. Tools such as pip install packages from PyPI by default, which makes it a high-value target for package supply chain attacks.
  • .pth file: A Python path configuration file placed in a site-packages directory. The Python interpreter processes .pth files at startup, and malicious import lines inside them can execute arbitrary code before application code runs. In the LiteLLM compromise, version 1.82.8 used a .pth file to trigger the harvester on any Python startup.
  • Indicator of compromise (IOC): An artifact, such as a pod name, file path, domain, or encoded payload, that signals a system may have been attacked. In this incident, IOCs include node-setup and sysmon Kubernetes pods and double-base64 payloads inside .pth files.
  • Transitive dependency: A dependency that is pulled in indirectly because another package requires it. LiteLLM was a transitive vector in projects such as Google ADK Python, where installing an extra like eval or extensions resolved the malicious version without the user naming LiteLLM directly.
  • Provenance attestation: Cryptographically signed metadata that documents how a package was built, by whom, and from what source. Verifying provenance at install time helps confirm a package came from the expected, untampered build pipeline.
  • Credential harvesting: Malware behavior that collects secrets from a host, such as cloud keys, Kubernetes tokens, API keys, SSH keys, environment variables, and shell history, and exfiltrates them to an attacker-controlled endpoint. Both malicious LiteLLM versions performed credential harvesting.