LiteLLM — a popular open-source gateway between applications and language model providers — has found itself at the center of a series of security incidents. According to Wiz Research, in February 2026 nearly one in ten LiteLLM servers discovered on the internet accepted sk-1234 — the example administrative key from the official installation guide. This key grants access to all model provider API keys stored on the server and, under certain conditions, to cloud IAM credentials as well. CISA has already added one of the LiteLLM vulnerabilities to the Known Exploited Vulnerabilities catalog, and Microsoft and Wiz have recorded real-world attacks involving cryptominer deployment and secret theft. Organizations using LiteLLM must immediately change the master key and update to version 1.84.0 or higher.
Scale of the default key problem
According to Wiz, in February 2026 Shodan found 3,074 publicly accessible LiteLLM gateways. Of these, 294 accepted the sk-1234 key. For 191 servers, the master key was not configured at all — they treated any request as having administrator privileges. The remaining servers used the value from the installation guide without modification. A repeat scan in August identified over 85,000 instances, but Wiz notes that most of these are likely honeypots or test systems, so these figures should not be compared directly.
In LiteLLM, the master key serves a dual purpose: it is both the administrator credential and the switch that enables authentication. Up to version 1.82.0-stable, a gateway started without a master key granted every incoming request full administrator rights. A gateway administrator has access to all provider API keys, can see all passing requests and responses, and can connect to internal tools via the Model Context Protocol (MCP). Stolen provider keys allow an attacker to run model workloads at the victim’s expense — an attack known as LLMjacking.
Vulnerability map: five CVEs and how they relate
A whole cluster of vulnerabilities has formed around LiteLLM. We have previously written about several LiteLLM vulnerabilities being added to the CISA KEV catalog. Let’s look at the full picture.
CVE-2026-59822 (CVSS 8.8, High) — MCP authentication bypass. It allows an unauthenticated attacker to open a valid MCP session using an arbitrary Bearer token, including one just a single character long. It affects versions prior to 1.84.0. According to the LiteLLM advisory, it is fixed in 1.84.0. CISA added this vulnerability to the KEV catalog on September 2 with a deadline for federal agencies of September 16. According to Wiz, exploitation was observed in their honeypots starting July 7 — requests with single-letter tokens were probing model enumeration endpoints. Wiz notes that this vulnerability “only allows access to the MCP server,” and the actual impact depends on the connected tools.
CVE-2026-42271 (CVSS 8.7, High) — command execution via test MCP endpoints. According to the GitHub advisory, it affects versions ≥1.74.2 and <1.83.7. It allows an authenticated user with a valid proxy API key to execute commands through MCP stdio test endpoints. It is fixed in 1.83.7. This vulnerability became the primary vector in real-world attacks.
CVE-2026-48710 (CVSS 6.5) — Host header validation bypass in Starlette (≤1.0.0). According to the advisory, malformed Host headers cause request.url.path to differ from the routed path, bypassing path-based security checks. It is fixed in Starlette 1.0.1. Horizon3.ai demonstrated that this vulnerability, in combination with CVE-2026-42271, enables unauthenticated command execution.
CVE-2026-59821 (CVSS 2.1, Low according to the LiteLLM CNA) — bypass of code security checks in the endpoints for creating and updating custom guardrails. It affects versions prior to 1.82.0-stable. According to the advisory, it requires a privileged account, although deployments without a configured master key treated callers as administrators. Wiz describes the same behavior as code execution with root privileges inside the gateway container — a discrepancy in severity assessment between the researchers and the maintainers.
CVE-2026-40217 (CVSS 5.9, Moderate) — sandbox escape in custom guardrails via bytecode techniques. According to the advisory, it affects versions ≥1.81.8 and <1.83.10, although the advisory text states a fix version of 1.83.11 — an internal inconsistency. By default, the proxy process in the Docker image runs as root. Exploitation requires administrator credentials for the proxy — that is, the master key.
Path to cloud credentials
One mechanism without a CVE deserves special attention. According to Wiz, LiteLLM allows the administrator to create pass-through endpoints that forward requests to arbitrary URLs. The target URL is not checked for belonging to private address ranges, localhost, or cloud metadata addresses. An administrator can route a path to the instance metadata service and obtain IAM credentials. Migrating to IMDSv2 does not block this path: LiteLLM documents that headers with the x-pass- prefix are forwarded to the target server without the prefix, which makes it possible to send the headers required by IMDSv2. Wiz notes that this feature “works as designed,” since the LiteLLM threat model considers administrators to be trusted. There is no patch, nor is one planned.
Real-world attacks: from cryptomining to database theft
LiteLLM vulnerabilities are being actively exploited. According to Wiz, their honeypots recorded exploitation of CVE-2026-42271 to deploy a cryptominer. In August, Microsoft published a description of an incident in which attackers executed commands inside the LiteLLM gateway process, extracted the master key, provider keys, and database connection string from the container environment, and then used it to access PostgreSQL and copy records from the models and virtual keys tables. Microsoft assesses with high confidence that the entry point corresponds to the CVE-2026-42271 and CVE-2026-48710 chain. The company recommends “treating AI gateways as Tier-0 secret stores.”
Indicators of compromise
According to Wiz, the cryptominer campaign used the following indicators:
- IP addresses:
185.62.1[.]8,185.84.98[.]85,94.26.106[.]29 - Download URL:
http://185.62.1.8/mon/mon.zip - Miner installation path:
/tmp/.dbus-cache/gmon - Pool domain:
pool.hashvault[.]pro
Response prioritization
Among all the issues described, CVE-2026-59822 and CVE-2026-42271 pose the greatest immediate threat — both have confirmed exploitation and affect internet-exposed MCP endpoints. The pass-through path to cloud metadata requires prior administrative access and is a post-exploitation vector rather than an independent entry point.
Recommendations
- Immediately change the master key from
sk-1234to a long random value. This does not require a version upgrade. Before rotating, check whether a separate salt key is configured — the rotation procedure differs, and a mistake can make stored credentials unreadable. - Update to version 1.84.0 or higher. This version is above the fix threshold for all of the LiteLLM vulnerabilities listed, including CVE-2026-40217, whose advisory internally disagrees between 1.83.10 and 1.83.11.
- If updating is not immediately possible, block at the reverse proxy or API gateway level:
/mcp/,POST /mcp-rest/test/connection,POST /mcp-rest/test/tools/list,POST /guardrails/test_custom_code. RestrictPOST /guardrailsandPUT /guardrails/{guardrail_id}to administrators only. - Restrict the container’s outbound network access and assign the workload the minimally necessary cloud IAM role — this is the only protection against the instance metadata route via pass-through.
- If you suspect a compromise: check the guardrails list for foreign entries, restart the process to clear code from memory, then rotate provider keys, the master key, and database credentials. Upgrading the version does not remove attacker-registered guardrails or added SSH keys.
A LiteLLM gateway exposed to the internet with the default sk-1234 key is effectively an open secrets store. Rotating the master key is a one-minute action that closes most of the attack vectors described without a version upgrade. Updating to 1.84.0 closes the rest. Organizations that discover LiteLLM running with the default configuration should assume possible compromise and rotate all associated secrets.
