16 posts tagged with "security"

We are committed to continuously improving the security of LiteLLM, for both our open-source community and enterprise customers.

With AI agents, publicly releasing a security patch can give attackers an immediate blueprint for exploiting the vulnerability, before users have had time to upgrade.

To address this, we're introducing a LiteLLM Private Registry in the coming weeks. For the most severe vulnerabilities, we'll first distribute fixes privately, giving organizations time to upgrade before publishing the patch and security advisory publicly.

Our commitment to open source remains unchanged. All security fixes will continue to be released publicly.

On October 21, our release pipeline published a compromised litellm==1.107.0 to PyPI and to our container registries. The incident post covers the affected artifacts and what to do if you ran them. We have completed our investigation into the actions taken by the threat actor, and can confidently assert the timeline and sequence of events that led to the publication of the malicious v1.107.0 release.

We posted regular status updates during our investigation yesterday reflecting the scenario to the best of our knowledge as the investigation proceeded. The investigation was ongoing, and some assumptions and beliefs in those updates were later proven to be inaccurate or incomplete. This post is the canonical source of truth.

Thank you to everyone who joined our October town hall. We covered security, stability and performance work, and the product updates from the month.

Status: Incident contained, investigation located here

Last updated: October 21, 2026 20:30 UTC

In the early morning of October 21, LiteLLM's release pipeline was compromised and pushed v1.107.0 to the docker registry and PyPi. This version contained compiled malware which steals credentials and loads remote-code execution tools. All previous versions are safe, and the impacted releases have been pulled. Enterprise Customers running the private enterprise release of LiteLLM were not impacted.

Update (20:30 UTC): We believe we have identified the attack chain which facilitated this attack. The attacker had to compromise multiple independent security controls to be successful. See How this happened below.

Update (October 23, 21:50 UTC): This post was written while our investigation was ongoing. Some our assumptions and beliefs reflected in our status updates and the text below were later discovered to be inaccurate or incomplete. We have left them in their original form as a record of our investigation, but have posted a canonical record here.

Shared agents can preserve individual identity, access, and spend controls.

When a finance agent serves multiple business units, platform teams need a consistent way to identify who initiated each request, apply the right model and tool permissions, and attribute spend. LiteLLM keeps this context available across shared-agent workflows so each business unit can operate under its own access and budget policies.

LiteLLM provides one control plane for this workflow across the Agent Gateway, Model Gateway, and MCP Gateway. Teams can share the same agent infrastructure while keeping access, credentials, spend, and audit data tied to the right caller.

Our updated SOC 2 Type 2 report is ready. You can access it through the LiteLLM Trust Center.

The update addressing this Host-header authentication bypass in the LiteLLM proxy shipped in v1.84.0, with follow-up path-handling hardening completed and backported across the maintained release lines in v1.84.3, v1.85.2, v1.86.2, and v1.83.10-stable.patch.3. The potential for bypass was limited to deployments with the three specific conditions below. The bypass was reported by Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group).

The conditions could allow unauthenticated access to protected management routes when the proxy listener was reachable with an arbitrary Host header.

No LiteLLM Cloud customers were affected. The update was deployed across all LiteLLM Cloud environments - backported to the release lines in use - ahead of this publication.

• Addressed in: v1.84.0
• Recommended: the latest release; follow-up path-handling hardening was backported in v1.84.3, v1.85.2, and v1.86.2
• Action: upgrade to v1.84.0 or later. No configuration change is required.

More info on the advisory is here: https://github.com/BerriAI/litellm/security/advisories/GHSA-4xpc-pv4p-pm3w. CVE: https://www.cve.org/CVERecord?id=CVE-2026-48710.

On May 11, 2026, security researchers at Aikido Security discovered a coordinated supply chain attack dubbed "Mini Shai-Hulud" that published malicious versions of over 170 npm packages and 2 PyPI packages, including mistralai==2.4.6.

LiteLLM is not impacted. We call Mistral's API directly over HTTP via httpx and do not import the mistralai Python SDK anywhere in the codebase.

TLDR;​

• LiteLLM does not install or import the mistralai package. We call Mistral's API the same way we call every other provider (via httpx). The compromised package is never executed in any LiteLLM environment.
• No LiteLLM user credentials were at risk from this attack. The malware runs at import mistralai time. Since LiteLLM never reaches that import, the payload never fires.
• No action is required from LiteLLM users. If you have separately installed mistralai==2.4.6 in the same environment for your own application code, you should follow Mistral AI's guidance immediately.

We recently published a security advisory for LiteLLM Proxy.

We received a report through our bug bounty program regarding a SQL injection vulnerability in LiteLLM Proxy's API key verification path, tracked as CVE-2026-42208.

The issue was reviewed by our team, fixed in a stable release, and then published as a GitHub Security Advisory.

• Affected versions: v1.81.16 through v1.83.6
• Fixed versions: v1.83.7 and later
• Recommended version: v1.83.10-stable

Stable release: https://github.com/BerriAI/litellm/releases/tag/v1.83.10-stable

Advisory: https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc

On April 15, 2026, OX Security published an advisory covering command-injection in Anthropic's MCP SDK's stdio transport (StdioServerParameters runs whatever command it's handed). This has been fixed on LiteLLM since v1.83.6-nightly.

The fix landed in commit 7b7f304 (PR #25343) and has been in every release from v1.83.6-nightly onward. v1.83.7-stable includes it.

TLDR;​

• This was not exploitable by unauthenticated users. The affected endpoints (MCP server creation and the /mcp-rest/test/* preview endpoints) all sit behind LiteLLM's auth. An attacker needed a valid LiteLLM API key, and with the patch the PROXY_ADMIN role, before they could reach this code path.
• The fix has been live since v1.83.6-nightly. The first stable release with the fix is v1.83.7-stable. Full list of patched versions below.
• If you find other vulnerabilities, please send them our way. We run a bug bounty program and pay out for P0 (supply chain) and P1 (unauthenticated proxy access) issues. See our previous security update for the current bounty table.

After the supply chain incident in March, we brought in Veria Labs to audit the LiteLLM proxy and fixed a number of vulnerability reports from independent researchers. All issues below are fixed in v1.83.0. If you are affected, particularly if you have JWT auth enabled, we recommend upgrading.

We've also launched a bug bounty program and Veria Labs is continuing to audit the proxy. More fixes will ship in upcoming versions.

The two high-severity issues (CVE-2026-35029 and GHSA-69x8-hrgq-fjj8) both require the attacker to already have a valid API key for the proxy. These are not exploitable by unauthenticated users.

The critical-severity issue (CVE-2026-35030) is an authentication bypass, but only affects deployments with enable_jwt_auth explicitly enabled, which is off by default. The default LiteLLM configuration is not affected, and no LiteLLM Cloud customers had this feature enabled.

The CI/CD v2 is now live for LiteLLM.

We are partnering with Vanta to recertify LiteLLM's compliance for SOC 2 Type 2 and ISO 27001.

Thank you to everyone who joined our town hall.

We wanted to use that time to walk through what we know, what we've done so far, and how we're improving LiteLLM's release and security processes going forward. This post is a written version of that update. Slides available here

Status: Active investigation Last updated: March 27, 2026

Update (March 30): A new clean version of LiteLLM is now available (v1.83.0). This was released by our new CI/CD v2 pipeline which added isolated environments, stronger security gates, and safer release separation for LiteLLM.

Date: March 18, 2026 Duration: Unknown Severity: High Status: Resolved

Summary​

When a custom guardrail returned the full LiteLLM request/data dictionary, the guardrail response logged by LiteLLM could include secret_fields.raw_headers, including plaintext Authorization headers containing API keys or other credentials.

This information could then propagate to logging and observability surfaces that consume guardrail metadata, including:

• Spend logs in the LiteLLM UI: visible to admins with access to spend-log data
• OpenTelemetry traces: visible to anyone with access to the relevant telemetry backend

LLM calls, proxy routing, and provider execution were not blocked by this bug. The impact was exposure of sensitive request headers in observability and logging paths.