LiteLLM Vulnerability Explained: What Happened, Which Versions Were Affected, and How to Respond

If you are searching for the “LiteLLM vulnerability,” the most important issue to understand is not a routine software bug. It is a critical supply chain compromise that affected the litellm package on PyPI on March 24, 2026. According to LiteLLM’s own incident report, the compromised versions were 1.82.7 and 1.82.8, both were removed from PyPI, and the official LiteLLM Proxy Docker image and LiteLLM Cloud were not impacted. GitHub’s reviewed advisory classifies the incident as critical and notes that the malicious package event itself does not have a conventional “patched version” in the way ordinary vulnerabilities do.

That distinction matters. A normal vulnerability usually means a defect in application logic that can be fixed in a later release. In this case, the package artifacts themselves were malicious. That means developers, CI runners, containers, and production systems could all be compromised simply by installing or upgrading to the bad releases from PyPI. Security research from Datadog and Snyk also ties the event to a broader TeamPCP campaign involving stolen publishing credentials and upstream CI/CD compromise.

What happened in the LiteLLM supply chain attack?

LiteLLM says the malicious packages were published during a limited exposure window on March 24, 2026 from 10:39 UTC to 16:00 UTC. During that time, anyone who installed or upgraded litellm from PyPI could have pulled a compromised release. The company’s incident report says the issue likely originated from a compromised dependency in its CI/CD security scanning workflow, and the GitHub issue tracking the incident says the malicious PyPI uploads were not produced through the official GitHub release pipeline.

The two affected versions were:

• litellm==1.82.7
• litellm==1.82.8

If your environment stayed on 1.82.6 or earlier, used the official ghcr.io/berriai/litellm Docker image, or used LiteLLM Cloud, LiteLLM says those deployment paths were not affected by the compromised PyPI releases.

Why this LiteLLM vulnerability is especially dangerous

The March 2026 LiteLLM incident is severe because the malicious code did not rely only on a normal import path. LiteLLM’s public issue trail and GitHub’s advisory say the compromised releases included code designed to harvest sensitive credentials and files and exfiltrate them to a remote API. Community and vendor analysis also found that version 1.82.8 included a malicious .pth startup hook, which is particularly dangerous because Python can execute .pth files automatically during interpreter startup. In practical terms, that means code execution could happen even before an application explicitly imported LiteLLM.

This is why the blast radius is much larger than “an app bug in a proxy.” LiteLLM commonly sits in environments that already hold valuable secrets: OpenAI keys, Anthropic keys, cloud credentials, database passwords, Kubernetes tokens, CI secrets, and SSH material. If the compromised package ran on a developer machine or in a CI pipeline, defenders should assume those secrets may have been exposed. GitHub’s advisory explicitly says anyone who installed and ran the malicious package should assume credentials available to the environment may have been exposed and should revoke or rotate them.

Who was affected?

The likely affected groups include developer laptops, ephemeral CI/CD runners, Docker build environments, agent infrastructure, and production hosts that installed or upgraded litellm from PyPI during the affected time window. The risk is not limited to direct installs. LiteLLM’s incident guidance warns that transitive dependencies and unpinned upgrade flows may also have pulled the compromised versions automatically.

That means teams should not ask only, “Did we use LiteLLM directly?” They should also ask, “Did any build, framework, or internal tool install LiteLLM on our behalf?” In supply chain incidents, the transitive path is often where organizations miss their true exposure. This is one reason the incident received immediate attention from downstream projects and security vendors tracking dependency compromise.

What should you do right now?

If litellm==1.82.7 or litellm==1.82.8 touched any environment you control, the safest assumption is host compromise plus secret exposure. The response should be decisive.

1. Identify every affected environment. Check every machine, build job, image, and environment that installed either compromised version.
2. Rotate all secrets. Rotate API keys, cloud credentials, database passwords, SSH keys, and cluster tokens that may have been present on those systems.
3. Audit logs and telemetry. Review logs, build artifacts, and network telemetry for signs of exfiltration.
4. Inspect Python environments. Look for suspicious files such as litellm_init.pth and rebuild compromised images from a clean base.
5. Pin to a known-safe version. Use 1.82.6 or another later verified-safe release once your organization has validated it internally.

These actions align with LiteLLM’s own incident guidance and GitHub’s advisory language.

Was this the only recent LiteLLM security issue?

No. Just days earlier, LiteLLM disclosed a separate incident involving guardrail logging and secret exposure. In that issue, when a custom guardrail returned the full request or data dictionary, LiteLLM could log secret_fields.raw_headers, including plaintext Authorization headers. The company says the issue was resolved and recommends upgrading to 1.82.3 or later, reviewing spend logs and OpenTelemetry traces, and rotating credentials if sensitive headers may have been logged.

This matters because people searching “LiteLLM vulnerability” may be seeing multiple incidents blended together. The March 2026 PyPI compromise is the critical supply chain event. The guardrail logging issue is a separate secret-exposure bug. They are related only in the sense that both can leak credentials, but they are different classes of security problem with different remediation paths.

LiteLLM’s earlier vulnerability history

The supply chain compromise is the most urgent current issue, but it is not the first confirmed LiteLLM security advisory.

• CVE-2025-0628: A privilege-escalation flaw in which an internal_user_viewer could receive an overly privileged API key and access admin functionality. Versions before 1.61.15 were affected.
• CVE-2025-45809: SQL injection through the key parameter on the /key/block and /key/unblock endpoints. Versions before 1.81.0 were affected.
• CVE-2024-9606: API key masking in logs was insufficient before 1.44.12.
• CVE-2024-8984: An unauthenticated denial-of-service issue patched in 1.56.2.
• A reviewed RCE advisory tied to unsafe post_call_rules callback handling in older LiteLLM versions.

Final take

The headline is simple: the most serious current “LiteLLM vulnerability” is actually a PyPI supply chain attack involving malicious versions 1.82.7 and 1.82.8. If those versions were installed anywhere in your estate, treat the incident as a likely credential exposure event, rebuild affected environments, and rotate secrets immediately. The separate guardrail logging incident and earlier CVEs add context, but the March 24, 2026 package compromise is the issue security teams should prioritize first.