LiteLLM Supply-Chain Attack: AI Gateway Security and Incident Response Guide

The short answer

If your environment installed litellm==1.82.7 or litellm==1.82.8 from PyPI during the March 24, 2026 incident window, treat the host, its CI runner, and every credential reachable from that process as potentially compromised. Do not merely upgrade LiteLLM. Isolate the machine, preserve evidence, revoke and rotate exposed credentials, inspect persistence, and rebuild from a known-good environment.

The incident matters beyond LiteLLM. It shows why AI gateways are unusually valuable supply-chain targets: one package can sit beside model-provider API keys, cloud credentials, Kubernetes tokens, SSH keys, and developer environment variables. The official LiteLLM incident report confirms the affected versions and the credential-stealing behavior; independent analysis from Snyk, GitGuardian, Trend Micro, and SecurityWeek corroborates the attack chain and impact.

What happened in the LiteLLM compromise

LiteLLM is a Python AI gateway and proxy that presents a unified interface across model providers. On March 24, attackers published two malicious PyPI releases:

• 1.82.7 contained a payload in litellm/proxy/proxy_server.py.
• 1.82.8 added litellm_init.pth, a Python startup hook that executed when the interpreter started, even without importing LiteLLM.

LiteLLM's official incident report says the packages were live from approximately 10:39 UTC for about 40 minutes before PyPI quarantined them. The project later released clean version 1.83.0 through a new CI/CD pipeline and published safe-version checksums.

Independent technical reports connect the compromise to a broader TeamPCP campaign that first abused a compromised Trivy security-scanning workflow. Stolen publishing credentials were then used to publish the malicious LiteLLM artifacts. This was not a normal dependency bug and not a hypothetical prompt-injection scenario: it was code execution through a legitimate package installation path.

Why the AI gateway role increased the blast radius

An ordinary library may have access to an application's data. An AI gateway often has access to the control plane around the application as well:

The important distinction is between possible exposure and confirmed theft. SecurityWeek's August 12 reporting cites CloudSEK's reconstructed estimate of more than 2,500 organizations and 434,000 CI/CD pipelines in the broader exposure set. That does not mean every named organization was compromised or that every credential was stolen. Teams still need to investigate their own logs and systems.

The execution path: why litellm_init.pth was dangerous

Python .pth files in site-packages can execute import statements during interpreter startup. The malicious 1.82.8 wheel used this mechanism to launch an encoded payload. Because the file was included in the wheel's own RECORD, ordinary package hash verification could confirm the artifact had not changed after publication—but it could not tell you that the publisher had uploaded a malicious artifact using legitimate credentials.

The practical consequence is easy to miss: a developer may install the package, run python, start an IDE language server, or invoke another Python tool and trigger the payload without ever importing litellm.

Gate A verification: what independent sources confirm

This topic passes the publication gate because the core claim is supported by multiple independent source pages, including an official primary source:

1. LiteLLM's official incident report identifies versions 1.82.7 and 1.82.8, the suspected Trivy connection, the affected window, the payload behavior, and safe release 1.83.0.
2. The BerriAI GitHub security issue independently documents the malicious .pth file, its startup behavior, the secret categories targeted, and the fact that 1.82.7 was also compromised.
3. Snyk's technical analysis reconstructs the attack chain, delivery mechanisms, exfiltration domain, persistence, and Kubernetes behavior.
4. Trend Micro's research corroborates the multi-stage payload and the cascade from Trivy through LiteLLM.
5. SecurityWeek provides independent reporting on the later CloudSEK exposure assessment and carefully distinguishes reconstructed exposure from confirmed compromise.

The sources agree on the affected versions and the central remediation advice. Where estimates differ, this guide uses the narrower claim and labels exposure estimates as estimates.

Incident response checklist

1. Contain before cleaning

If a host may have installed either affected version, disconnect it from unneeded networks and stop workloads that could continue using stolen credentials. Do not delete the disk immediately if your security team needs forensic evidence. Capture the package version, installation time, process list, outbound connections, and relevant CI job metadata.

For a container or ephemeral runner, preserve the image digest and logs before destroying the workload. For a developer laptop, assume local secrets may be exposed even if the LiteLLM process appeared to fail quickly.

2. Find vulnerable installations

Search dependency declarations, lockfiles, build logs, container layers, virtual environments, and CI caches. A basic inventory command is useful for triage, but it is not proof that a machine is clean:

1python -m pip show litellm 2>/dev/null || true
2python - <<'PY'
3import importlib.metadata as md
4try:
5    print("litellm", md.version("litellm"))
6except md.PackageNotFoundError:
7    print("litellm not installed in this interpreter")
8PY

For repositories, search both exact versions and unpinned installation commands. Include transitive dependencies: Snyk reports that a Cursor MCP plugin helped surface the compromise because it pulled LiteLLM indirectly.

3. Check the startup hook and indicators

On affected Python environments, inspect site-packages for litellm_init.pth. Also review the indicators published by LiteLLM and GitGuardian, including connections to models.litellm.cloud, checkmarx.zone, and the typosquatted scanner domain reported in the research. Check for suspicious sysmon files and user services, unusual tpcp.tar.gz archives, and unexpected Python child-process loops.

1python - <<'PY'
2import sysconfig
3from pathlib import Path
4site = Path(sysconfig.get_paths()["purelib"])
5path = site / "litellm_init.pth"
6print(f"checking {path}")
7print("FOUND: inspect and quarantine this environment" if path.exists() else "not found in this interpreter's site-packages")
8PY

Do not treat a missing .pth file as clearance. Version 1.82.7 used a different injection location, and a package may have executed before it was removed.

4. Rotate credentials by trust boundary

Rotate credentials in priority order: cloud access keys and instance roles, CI/CD tokens, package publishing credentials, model-provider keys, SSH keys, GitHub/GitLab tokens, Kubernetes service-account tokens, database passwords, and application secrets. Revoke sessions and refresh tokens where supported. Rotate from a separate known-clean workstation.

Use access logs to determine whether credentials were used. A credential that shows no suspicious use should still be rotated if it was reachable from a compromised interpreter; lack of evidence is not evidence of non-access.

5. Rebuild instead of patching in place

After evidence collection and credential rotation, rebuild the environment from a clean base image or fresh virtual environment. Pin dependencies with hashes where practical, verify the package and publisher provenance, and avoid reusing caches from the incident window. The official LiteLLM report identifies 1.83.0 as a clean release, but teams should still follow current project advisories and verify the version they deploy.

What AI engineering teams should change

The lasting lesson is not “never use LiteLLM.” It is to reduce the privileges and trust concentrated in AI infrastructure.

• Run gateways with dedicated, least-privilege identities rather than developer credentials.
• Keep model-provider keys out of general-purpose build runners when possible.
• Pin security actions and dependencies by immutable commit or digest.
• Require isolated release environments and protected publishing credentials.
• Monitor outbound traffic from Python build jobs and AI gateways.
• Scan transitive dependencies, not just direct requirements.txt entries.
• Treat .pth, import hooks, shell startup files, and post-install scripts as high-signal review points.
• Test restore and credential-revocation procedures before the next incident.

This is closely related to the broader agent-security problem discussed in the CoreBreak AI agent authorization guide and the StepSecurity Dev Machine Guard guide. For teams operating an AI gateway behind a routing layer, the Google Cloud API Gateway model-routing guide provides a useful comparison point for separating provider access from application workloads.

Common mistakes during response

“We upgraded, so we are safe.”

An upgrade removes the vulnerable package from the active environment; it does not rotate secrets already read or remove persistence already created.

“The package hash matched.”

A valid hash proves integrity relative to the published artifact. It does not prove that the artifact was benign when it was published.

“Only production matters.”

Developer machines, CI runners, preview deployments, and MCP-related virtual environments can hold the same credentials as production systems—or credentials that can reach production.

“The exposure number means we were hacked.”

Population-level estimates are useful for prioritization, not attribution. Confirm your own installation history, outbound telemetry, credential use, and persistence indicators.

FAQ

Which LiteLLM versions were compromised?

The official LiteLLM report and independent analyses identify 1.82.7 and 1.82.8 as compromised PyPI releases. Version 1.82.7 used code injected into the proxy path; 1.82.8 additionally used a Python startup hook.

Do official LiteLLM Docker users need to respond?

LiteLLM says its official Proxy Docker image was not impacted because that deployment path pins dependencies and does not rely on the compromised PyPI packages. Still verify your image provenance and any separate pip install steps in your build.

Is this an AI-specific vulnerability?

The initial compromise was a software supply-chain attack, not a model vulnerability. It is AI-specific in its consequences because LiteLLM commonly sits beside model keys, cloud identity, and agent infrastructure.

Should teams stop using LiteLLM?

Not automatically. Teams should follow the project's incident updates, use a verified safe release, isolate the gateway, minimize privileges, and operate a tested dependency and credential-rotation process.

Conclusion

The LiteLLM compromise is a useful warning for every team building AI applications: an AI gateway is part of the security perimeter, even when it looks like a convenience library. The correct response is a full supply-chain incident workflow—contain, investigate, rotate, rebuild, and then reduce privilege. That approach is more durable than relying on package removal, a version bump, or a single scanner to tell you the environment is clean.

Sources and visual credit

• LiteLLM official security update
• BerriAI LiteLLM security issue #24512
• Snyk technical analysis
• GitGuardian incident-response guidance
• Trend Micro research
• SecurityWeek reporting on CloudSEK's exposure assessment

The Mermaid attack-chain diagram is original and created for this article; it uses no external image asset.

Visual: Security control path

This original threat-to-control diagram turns the security guidance in this article into a concrete sequence of gates.

Visual reading: security is layered. Blocking unsafe actions before execution is important, but allowed actions still need sandboxing, logging, and output validation.