Loading story…
LiteLLM fixed two high-severity vulnerabilities in version 1.83.0 that could allow attackers to gain elevated access in AI gateway deployments. CVE-2026-35029 stems from missing admin authorization on the /config/update endpoint, allowing an authenticated low-privilege user to change proxy settings and environment variables. The flaw could be abused to register attacker-controlled Python handlers for remote code execution, read arbitrary server files, and overwrite UI credentials to seize privileged accounts, creating broad confidentiality, integrity, and availability risk.
The same release also addressed CVE-2026-35030, an authentication bypass affecting LiteLLM deployments that enabled JWT-based authentication. In vulnerable versions, the platform used the first 20 characters of a token as the OIDC userinfo cache key, allowing a crafted token with a matching prefix to collide with a legitimate cached session and inherit that user’s identity and permissions. The issue is not enabled by default, limiting exposure to specific configurations, but together the flaws highlight significant access-control weaknesses in LiteLLM versions prior to 1.83.0.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
LiteLLM released v1.83.7-stable with a security fix blocking arbitrary command execution via MCP stdio transport, along with hardening for proxy input validation, token lookup queries, file path resolution in skill archive extraction, and permission checks. The release also emphasized Docker image signature verification with cosign and pinned verification guidance to an immutable commit hash.
Public advisories disclosed two high-severity LiteLLM vulnerabilities: CVE-2026-35029, which lets a low-privilege authenticated user escalate privileges and potentially achieve remote code execution, and CVE-2026-35030, which allows authentication bypass in certain JWT-enabled deployments via cache key collisions.
LiteLLM released version 1.83.0 to fix two security flaws affecting earlier versions: an authorization bypass in the /config/update endpoint (CVE-2026-35029) and an OIDC userinfo cache key collision authentication bypass affecting JWT-enabled deployments (CVE-2026-35030).
BerriAI released LiteLLM v1.83.0-nightly with a fix for the broken access control flaw in the /config/update endpoint, later tracked as CVE-2026-35029. The vulnerability allowed low-privileged users to modify configuration and abuse pass-through features to exfiltrate environment variables and read files accessible to the application.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
github.com
Open sourcecvefeed.io
Open sourcecvefeed.io
Open sourcedocs.litellm.ai
Open sourceseclists.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
BerriAI disclosed and fixed **CVE-2026-59822**, an authentication bypass in LiteLLM versions prior to `1.84.0` that exposed the MCP Streamable HTTP endpoint to unauthenticated access. The flaw allowed a remote attacker to send a fabricated `Authorization` header that triggered an OAuth2 passthrough fallback path; when LiteLLM key validation failed, the application substituted an empty `UserAPIKeyAuth()` object and still allowed requests to reach MCP tooling. The vulnerability is classified under **CWE-287** and **CWE-306** and is described as network-exploitable without privileges or user interaction. The fix shipped in **LiteLLM v1.84.0**, alongside broader security hardening across authentication, authorization, and MCP-related features. Release notes for `v1.84.0` also highlight encrypted MCP credentials at rest, SSRF protections for OAuth metadata discovery follow-up fetches, hardened invite-link onboarding token handling, redaction of sensitive data, and signed Docker images that can be verified with `cosign` using a pinned public key and commit reference. Organizations running LiteLLM should upgrade to `1.84.0` or later and validate deployment artifacts as part of remediation.
Jul 9, 2026
A critical vulnerability in **LiteLLM** tracked as `CVE-2026-49468` allows attackers to bypass authentication through **Host header injection** and reach protected management endpoints. The flaw affects LiteLLM versions earlier than **`1.84.0`** and stems from a mismatch in how the authentication layer evaluates routes versus how **FastAPI** ultimately dispatches them, creating a path for unauthenticated access under specific conditions. The issue is classified as **`CWE-290`** and has been rated **CVSS 9.5**, with researchers describing it as network-exploitable with low attack complexity and no user interaction required. The vulnerability was responsibly disclosed by **Le The Thang** of **KCSC** and **Kim Ngoc Chung** of **One Mount Group**, and LiteLLM maintainers have released a fix in version **`1.84.0`** with no configuration changes required. There is no confirmed evidence of active exploitation, and **LiteLLM Cloud** customers are reportedly not affected. Self-hosted deployments may also be shielded if upstream infrastructure such as **Cloudflare**, **WAFs**, reverse proxies with strict allowlists, or host-validating load balancers normalize or reject malformed Host headers before requests reach the application.
Jun 29, 2026
CISA added **CVE-2026-42271** to its Known Exploited Vulnerabilities catalog after evidence emerged that attackers are exploiting a command injection flaw in BerriAI **LiteLLM**. The bug affects MCP server test endpoints in self-hosted LiteLLM deployments, where crafted `stdio` parameters can trigger arbitrary command execution on the proxy host. On its own, the flaw requires a valid proxy API key, but researchers reported it is being chained with **CVE-2026-48710** in **Starlette**—a Host header validation bypass known as **BadHost**—to bypass authentication and achieve unauthenticated remote code execution. The exposed attack path affects LiteLLM versions **1.74.2 through 1.83.6** when deployed with **Starlette 1.0.0 or earlier**, and researchers rated the combined chain as effectively **critical** with a CVSS score of **10.0**. Successful compromise can let attackers run OS commands, steal model provider credentials, API keys, secrets, and environment variables, and pivot into connected AI infrastructure. BerriAI patched the issue in **LiteLLM 1.83.7** by restricting the vulnerable test endpoints to the `PROXY_ADMIN` role, while defenders are being urged to upgrade LiteLLM and Starlette, limit network access to the affected endpoints, rotate stored credentials, and review logs for suspicious Host header and subprocess activity.
Jun 29, 2026