Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
CVE-2026-59822 was newly published describing an authentication bypass in LiteLLM versions prior to 1.84.0. The flaw affects the MCP Streamable HTTP endpoint, where a fabricated Authorization header can trigger an OAuth2 passthrough fallback that allows access without a valid LiteLLM key.
BerriAI published LiteLLM version 1.84.0, whose release notes include multiple security-related changes and hardening updates affecting authentication, authorization, MCP handling, and related protections. The CVE reference states that this version fixes CVE-2026-59822.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map 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.
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`.
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
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