Loading story…
Wiz researchers found that 294 of 3,074 internet-facing LiteLLM gateways accepted the documented default administrator key, sk-1234, while 191 had no master-key authentication configured. An attacker with master-key access can retrieve model-provider API keys, inspect prompts and responses, access MCP-connected tools, and abuse unrestricted pass-through endpoints to query cloud instance metadata services and obtain IAM credentials.
The exposure coincides with multiple LiteLLM flaws, including actively exploited MCP authentication bypass CVE-2026-59822, which allows arbitrary Bearer tokens to create authenticated MCP sessions, and Python code execution CVE-2026-59821 through custom code guardrails in versions before 1.82.0. Organizations should upgrade to LiteLLM 1.84.0 or later, replace and rotate default master keys, remove public access to management and MCP endpoints, restrict container egress, and enforce least-privilege cloud IAM permissions.
See which actors are running it and whether you're in range.
10 events from the most recent confirmed update back to the earliest known activity.
CISA added actively exploited CVE-2026-59822 to its Known Exploited Vulnerabilities catalog.
Wiz observed probes against its honeypots using single-character Bearer tokens to exploit the LiteLLM MCP authentication bypass and query model-listing endpoints.
LiteLLM v1.84.0 released a fix for CVE-2026-59822, which allowed arbitrary Bearer tokens, including one-character tokens, to establish authenticated MCP sessions because of fallback authentication logic.
LiteLLM v1.82.0 released a fix for CVE-2026-59821, a post-authentication custom-code guardrail flaw that could execute arbitrary Python in the gateway container. The changes restricted unauthenticated users' default role, added administrator checks to guardrail endpoints, and applied sandboxing during guardrail registration.
In a scan of 3,074 publicly exposed LiteLLM instances, Wiz found 294 (9.6%) accepted the default "sk-1234" master key or did not require authentication; 191 instances required no authentication.
LiteLLM fixed CVE-2026-35029 in version 1.83.0. Before that release, the pass-through configuration-update route lacked an administrator authorization check, enabling unauthorized configuration of request forwarding that could be used to access internal services or cloud metadata when access controls failed.
Wiz demonstrated that a LiteLLM administrator could use unrestricted pass-through endpoints to query cloud instance-metadata services and retrieve IAM credentials, including by forwarding required IMDSv2 headers. Wiz reported no evidence that this capability had been exploited against a real deployment.
Wiz honeypots recorded exploitation of CVE-2026-42271 to install a cryptocurrency miner. The vulnerability allowed authenticated LiteLLM users to execute host commands through MCP test endpoints in affected releases.
LiteLLM fixed CVE-2026-40217 in version 1.83.10, with advisory text also referencing version 1.83.11. The flaw affected versions 1.81.8 through versions before 1.83.10 and enabled a proxy administrator to use bytecode techniques to escape the guardrail sandbox and execute code in the root-running proxy process.
Microsoft reported an August incident in which attackers executed commands in a LiteLLM gateway process, extracted environment secrets, and accessed the underlying PostgreSQL database to copy model and virtual-key records. Microsoft assessed with high confidence that the compromise began at an exposed LiteLLM gateway and matched the CVE-2026-42271 and CVE-2026-48710 attack chain.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Correlate live exploitation activity against the software you actually run, and see where you're exposed.
5 references tracked. Mallory keeps watching after this page renders.
cryptika.com
Open sourcecybersecuritynews.com
Open sourcethehackernews.com
Open sourcewiz.io
Open sourcedocs.litellm.ai
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.
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
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