Thank you to everyone who joined our September town hall. We covered security updates, stability updates, and new features in the product, including OCR running on Rust by default and test coverage past the 80% target we set in August.
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.
Thank you to everyone who joined our August town hall. We used it to share this month's security and stability work and our latest product updates: 79 security fixes, 375 bug fixes, and 142 feature commits, a new Director of Security, a public status dashboard, and Auto-Router results from production.
Thank you to everyone who joined our July town hall. We used it to share this month's security and stability work and our latest product updates: 38 security fixes, 317 bug fixes, and 140 feature commits, headlined by new Rust benchmarks and the launch of Autorouter V2.
Thank you to everyone who joined our June town hall.
Three numbers capture the month: 24 security fixes, 94 bug fixes, and 78 feature commits. The sections below break each one down, alongside our public commitment to zero reported regressions and the gradual migration of the LiteLLM gateway to Rust.
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.
v1.84.0v1.84.3, v1.85.2, and v1.86.2v1.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.
Thank you to everyone who joined our May town hall.
We covered security hardening, release versioning changes, new product launches (MCP toolsets, on-behalf-of OAuth), performance wins, and our biggest bet yet, the LiteLLM Agent Platform.
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.
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.import mistralai time. Since LiteLLM never reaches that import, the payload never fires.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.
v1.81.16 through v1.83.6v1.83.7 and laterv1.83.10-stableStable 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.
/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.v1.83.6-nightly. The first stable release with the fix is v1.83.7-stable. Full list of patched versions below.
Akto now runs natively inside the LiteLLM proxy as a chained guardrail.
Thank you to everyone who joined our April town hall.
We used the session to share our CI/CD v2 improvements, product stability work, and what we are prioritizing next across reliability and product roadmap.
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
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:
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.