Wiz, the cloud security research arm now owned by Google, has disclosed a cluster of security flaws in LiteLLM, one of the most widely deployed open-source gateways for routing traffic to large language models. The findings, first reported by TechRadar on October 14, 2026, describe an authentication bypass, a path to root-level remote code execution, and a default configuration that hands out administrator access to anyone who asks. One of the bugs is already listed on the federal government’s Known Exploited Vulnerabilities catalog, and Wiz says it caught real attackers probing for it through its own honeypot network.
LiteLLM sits in a strange but increasingly important spot in the AI stack. It is the proxy layer that lets a company swap between OpenAI, Anthropic, Google, and dozens of other model providers without rewriting application code, and it has become a default choice for teams building AI agents that need to call multiple models and tools. That popularity is exactly why Wiz’s report lands hard: a flaw in the gateway does not just expose one application, it can expose every model call, every API key, and every downstream system wired into the proxy.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Wiz Found in the LiteLLM AI Gateway
According to Wiz’s research, the most serious of the newly disclosed issues is tracked as CVE-2026-59822, an authentication bypass in LiteLLM’s Model Context Protocol (MCP) handling. The flaw allows an arbitrary Bearer token, not necessarily a valid one issued by the system, to stand up a fully authenticated session. In practice, that means an attacker does not need to steal a real credential. They only need to present something that looks like one, and LiteLLM’s MCP layer will treat it as legitimate.
Paired with that is CVE-2026-59821, a post-authentication vulnerability that Wiz describes as a path to root-level remote code execution through LiteLLM’s custom code guardrails feature. Guardrails are meant to be a safety mechanism, a way for teams to write custom logic that screens prompts and responses before they reach a model or a user. Wiz’s research shows that same mechanism can be turned around: once an attacker has a session, whether stolen or forged through CVE-2026-59822, the guardrail execution path becomes a way to run arbitrary code with root privileges on the host.
Chained together, those two findings describe a worst-case scenario for a gateway product: unauthenticated entry followed by full system compromise. Wiz also flagged a third issue that received no CVE number at all. When authentication is not explicitly configured on a LiteLLM deployment, the system defaults to granting PROXY_ADMIN access to any user who connects. There is no deliberate backdoor here, just a permissive default that assumes operators will lock things down themselves, an assumption that the exposure data below suggests does not hold in practice.
Wiz’s fourth finding concerns how LiteLLM handles pass-through requests to cloud provider APIs. The gateway’s pass-through endpoint lacked proper URL validation, creating a route that researchers say could be abused to steal cloud credentials tied to the host environment. For a proxy that by design sits between an application and multiple cloud-hosted model providers, often with broad IAM permissions attached so it can reach storage, logging, and secrets services, a credential-theft vector in that chokepoint is a serious finding on its own, independent of the authentication bugs.
9.6% of Scanned LiteLLM Instances Had No Real Protection
Wiz did not stop at describing the vulnerabilities in the abstract. The firm scanned 3,074 publicly accessible LiteLLM instances to see how many were actually exposed in the real world. The result: 9.6% of those instances either accepted the LiteLLM default master key, sk-1234, or required no authentication whatsoever to reach administrative functions. Security outlet Cyber Security News reported the same underlying arithmetic in a separate writeup, putting the number at 294 of the 3,074 scanned instances.
That default key, sk-1234, is meant purely as a placeholder in LiteLLM’s documentation and quick-start examples, the kind of thing a developer is supposed to replace before going anywhere near production. The fact that nearly one in ten publicly reachable instances still answers to it tells a familiar story in open-source infrastructure security: the gap between a documented best practice and what actually ships in production is wide, and at scale that gap becomes a target list. Security vendor Requesty made the exposure rate the headline of its own analysis, framing an AI gateway that still accepts a textbook-default key as a sign that LiteLLM deployments are being treated as internal developer tooling rather than as the security-critical chokepoint they have become.
What makes this number more than an academic curiosity is Wiz’s claim that it observed CVE-2026-59822 being actively exploited in the wild, detected through the company’s own honeypot infrastructure designed to attract and log attacks against exposed AI systems. That is not a theoretical proof-of-concept circulating on a security mailing list. It is evidence that real attackers are already scanning for, and hitting, exposed LiteLLM deployments. CISA has since added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog, a designation reserved for flaws with confirmed real-world exploitation, which triggers mandatory patching deadlines for US federal agencies running the affected software and is widely treated by private-sector security teams as a signal to patch immediately rather than on a routine cycle.
A Pattern of Disclosures, Not a Single Bug
The Wiz report is also notable for what it is not: an isolated incident. LiteLLM has accumulated a string of disclosed vulnerabilities through 2026, and this month’s findings sit on top of that pattern rather than standing alone. CVE-2026-42271, a command-injection vulnerability affecting LiteLLM’s MCP test endpoints, was added to CISA’s Known Exploited Vulnerabilities catalog back in June 2026, months before the Wiz disclosures. Separately, CVE-2026-42208 describes a SQL-injection vulnerability in the API-key verification path of LiteLLM Proxy, meaning the very mechanism meant to check whether a caller is allowed in was itself susceptible to injection attacks.
LiteLLM’s own security advisories, tracked in the project’s security-tagged documentation, describe a related runtime-configuration issue: an authenticated user could modify the proxy’s live configuration in ways that open the door to arbitrary file reads, administrator-account takeover, or remote code execution. The project resolved two other tracked flaws, CVE-2026-35029 and CVE-2026-59823, in version 1.83.9, with the fixes carried forward into every release after that point.
Taken together, the timeline reads less like a single incident report and more like a maturity problem common to fast-growing open-source infrastructure projects: a tool built quickly to meet urgent demand for multi-model routing, adopted widely before its security model had been stress-tested, and now facing the kind of adversarial scrutiny that only arrives once a project becomes important enough to be worth attacking. Wiz’s report was first published September 9, 2026, and the company updated it as recently as October 2, 2026, suggesting the research and exploitation picture is still evolving rather than closed.
Why an LLM Gateway Is a High-Value Target
To understand why this matters beyond the usual CVE news cycle, it helps to understand what LiteLLM actually does inside a company’s stack. An LLM gateway, sometimes called an AI gateway or LLM proxy, sits between an organization’s applications and the external (or internal) model providers those applications call. It centralizes authentication, rate limiting, logging, cost tracking, and increasingly, tool access for AI agents through protocols like MCP. Our own guide to building an LLM gateway for multiple AI models walks through exactly why teams adopt this pattern: one proxy, one point of control, many downstream models.
That centralization is the whole value proposition, and it is also the whole risk. A compromised gateway does not expose one application’s data, it potentially exposes every API key the gateway holds, every model conversation routed through it, and every tool call an AI agent makes through its MCP connections. Check Point Research, in its own independent analysis of LiteLLM, described LiteLLM as one of the most widely used LLM gateways in production today, which is precisely the kind of widespread adoption that turns a gateway-level flaw into a systemic risk rather than a contained one.
This is also why the MCP-specific nature of two of the bugs matters. MCP is the protocol that lets AI agents reach outside their own sandbox to call external tools, query databases, or trigger actions in other systems. A gateway that mishandles MCP authentication is not just leaking chat logs, it is potentially handing an attacker the same tool-calling permissions a legitimate AI agent would have. That risk connects directly to broader concerns already surfacing elsewhere in AI infrastructure, including the recent MCP credential leak that exposed roughly 82,000 files, where one in eight contained usable secrets. Different root cause, same underlying theme: the tooling layer that connects AI agents to the rest of the enterprise is being built faster than it is being secured.
LiteLLM Vulnerabilities at a Glance
| CVE / Issue | Type | Status | Source |
|---|---|---|---|
| CVE-2026-59822 | MCP authentication bypass (arbitrary Bearer token) | Actively exploited; added to CISA KEV | Wiz |
| CVE-2026-59821 | Post-auth root-level remote code execution via custom code guardrails | Disclosed by Wiz | Wiz |
| Unauthenticated admin access (no CVE) | Insecure default grants PROXY_ADMIN | Disclosed by Wiz | Wiz |
| Pass-through credential theft vector | Missing URL validation on pass-through endpoint | Disclosed by Wiz | Wiz |
| CVE-2026-42271 | Command injection in MCP test endpoints | Added to CISA KEV, June 2026 | CISA / GitLab Advisory Database |
| CVE-2026-42208 | SQL injection in API-key verification path | Disclosed | GitLab Advisory Database |
| CVE-2026-35029 and CVE-2026-59823 | Runtime configuration abuse risks | Patched in LiteLLM 1.83.9 | LiteLLM project |
Exposure Snapshot: How Many LiteLLM Instances Are at Risk
| Metric | Figure | Source |
|---|---|---|
| Publicly accessible LiteLLM instances scanned | 3,074 | Wiz |
| Share accepting default key or requiring no auth | 9.6% | Wiz |
| Instances meeting that exposure condition | 294 of 3,074 | Cyber Security News |
| Wiz report initial publish date | September 9, 2026 | Wiz |
| Wiz report last updated | October 2, 2026 | Wiz |
| Monthly US search volume for “litellm” | 22,200 (up sharply year over year) | DataForSEO |
How This Compares to Past AI Gateway Scares
This is not the first time an AI infrastructure component has landed on CISA’s exploited-vulnerabilities list, and it will not be the last. Earlier in 2026, a separate LiteLLM flaw, CVE-2026-42271, made that same list after researchers found attackers exploiting a command-injection bug in its MCP test endpoints. In September, CISA flagged CVE-2026-59822 specifically, a bug our earlier coverage detailed as the first confirmed, actively exploited flaw in production AI agent infrastructure to reach that catalog. What has changed since then is scale and context: Wiz’s 90-day honeypot telemetry now puts hard numbers behind how many real-world deployments remain exposed, and adds three more findings, including the root-RCE chain and the credential-theft pass-through bug, that were not part of the original CISA entry.
The broader pattern echoes earlier infrastructure scares in cloud computing, where a widely adopted piece of middleware, think load balancers, API gateways, or service meshes, became a magnet for vulnerability research precisely because of how many downstream systems depended on it. AI gateways are now going through that same cycle, just compressed into a shorter timeframe because AI adoption itself has moved faster than the usual multi-year infrastructure buildout. The difference this time is that the proxy in question is not just routing HTTP traffic, it is routing access to models that can read sensitive data, write code, and increasingly take actions through connected tools.
It is also worth noting that LiteLLM is not alone in facing this kind of scrutiny. Our recent comparison of cloud-native AI gateways for Kubernetes teams highlighted how quickly this product category has expanded, with commercial and open-source options competing on the same feature set: multi-model routing, cost tracking, and now, increasingly, security posture. A disclosure of this size on one of the category’s most widely used projects is likely to push buyers to scrutinize authentication defaults and MCP handling across every competing product, not just LiteLLM.
What LiteLLM and Security Researchers Are Saying
LiteLLM’s own disclosure, published in its security-tagged blog documentation, acknowledges that an authenticated user could modify the proxy’s runtime configuration in ways that enable arbitrary file reads, administrator-account takeover, or remote code execution, a description that lines up closely with the root-cause pattern Wiz describes in its own findings. The project has pointed users toward version 1.83.9 and later releases, which carry fixes for CVE-2026-35029 and CVE-2026-59823.
Check Point’s independent research team has separately characterized LiteLLM as one of the most widely used LLM gateways in production, a framing that underscores why this round of disclosures is being treated as a notable event rather than routine open-source patch news. Security outlet Cyber Security News summarized the practical risk in direct terms: the combination of flaws lets attackers execute code as root and steal cloud credentials, two outcomes that, on their own, would each qualify as a critical incident for any enterprise running exposed infrastructure.
Market and Industry Impact
The business stakes here extend well past the open-source project itself. LiteLLM has become infrastructure for a wide swath of the AI tooling ecosystem, underpinning everything from internal developer platforms to commercial products built on top of multi-model routing. A high-profile vulnerability cluster, especially one with confirmed in-the-wild exploitation and a CISA KEV listing, puts pressure on every company that has quietly wired LiteLLM into production without auditing its authentication defaults.
Enterprise security teams are likely to respond in a few predictable ways. Some will accelerate audits of their AI gateway layer entirely, treating this disclosure as the forcing function to finally inventory where LiteLLM, or any similar proxy, sits in their stack. Others will lean on managed or commercial AI gateway offerings that bundle authentication hardening and monitoring by default, a dynamic that could accelerate consolidation in the AI gateway market toward vendors who can demonstrate security rigor rather than just feature breadth. That shift would echo what happened in API security a decade ago, when a string of gateway-level breaches pushed enterprises away from self-managed, default-configuration deployments and toward vendors offering stronger guardrails out of the box.
There is also a reputational dimension specific to open-source AI infrastructure. LiteLLM’s growth has been driven in large part by its flexibility and its free, self-hostable model, the same qualities that make default-credential exposure a recurring risk. If enterprises conclude that open-source AI gateways carry higher operational risk than commercial alternatives with managed security postures, that could slow adoption of self-hosted tooling across the AI stack more broadly, not just for LiteLLM specifically.
What Security Teams Should Do Right Now
- Upgrade to LiteLLM 1.83.9 or later immediately, since that release and everything after it carries the fixes for CVE-2026-35029 and CVE-2026-59823.
- Audit every LiteLLM deployment for the default master key, sk-1234, and replace it with a unique, rotated credential if found.
- Explicitly configure authentication rather than relying on defaults, given that unconfigured instances grant PROXY_ADMIN access automatically.
- Review MCP endpoint exposure specifically, since two of the most serious flaws, CVE-2026-59822 and the related command-injection bug CVE-2026-42271, both target MCP handling.
- Check outbound pass-through configurations for proper URL validation to close the cloud-credential theft vector Wiz identified.
- Treat any internet-facing LiteLLM instance as a priority patch target, not routine maintenance, given confirmed in-the-wild exploitation and the CISA KEV listing.
Teams that already run credential vaulting alongside their AI infrastructure have an easier path here. Comparing LiteLLM’s exposure data against the broader secrets-management landscape, outlined in our look at HashiCorp Vault versus AWS Secrets Manager versus Doppler, makes the case plainly: a gateway holding static, hardcoded, or rarely rotated keys is a far bigger liability than one backed by a proper secrets manager with automated rotation. The same logic applies to AI agents that call tools through MCP, where credential hygiene covered in our guide to securing AI agent credentials directly reduces the blast radius of a gateway-level compromise like this one.
Predictions: Where This Goes From Here
- Expect additional CVEs tied to LiteLLM’s MCP implementation within the next two to three months, given the pace of disclosures already seen in 2026 and the ongoing scrutiny from multiple independent research teams.
- Commercial AI gateway vendors will likely use this disclosure in competitive positioning, emphasizing managed authentication and default-secure configurations over self-hosted open-source alternatives.
- More enterprises will start requiring security audits of AI gateway infrastructure before production deployment, treating it with the same scrutiny currently applied to API gateways and service meshes.
- CISA and similar agencies in other countries are likely to add further AI-infrastructure CVEs to their exploited-vulnerabilities catalogs as honeypot and threat-intelligence data, like Wiz’s, continues to surface active exploitation.
- Expect the exposure rate for default credentials to drop over the coming months as this disclosure gets wider press coverage, though a meaningful share of forgotten or unmonitored instances will likely remain vulnerable well into 2027.
The Bigger Picture for AI Infrastructure Security
What makes the LiteLLM disclosures significant is not any single CVE score, it is what they reveal about the state of AI infrastructure security broadly. Tools built to accelerate AI adoption, gateways, agent frameworks, MCP servers, have largely been built by small teams moving quickly to meet surging demand. Security hardening, in many cases, has been an afterthought bolted on after adoption rather than a design constraint from day one. Wiz’s honeypot data, scanning thousands of real deployments and finding live exploitation already underway, is a concrete data point for a pattern that security researchers have been warning about all year: the AI tooling layer is becoming a priority target precisely because it was not built with that level of scrutiny in mind.
For organizations running LiteLLM, or any comparable open-source AI gateway, the message from this round of disclosures is straightforward. Default configurations are not safe configurations. A proxy that routes access to models, tools, and cloud credentials deserves the same security rigor as any other piece of critical infrastructure, not the more relaxed treatment often given to developer tooling. The gap between those two postures is exactly where the 9.6% exposure figure came from, and it is exactly where the next AI infrastructure incident is likely to start.
Frequently Asked Questions
What is LiteLLM?
LiteLLM is an open-source gateway, or proxy, that lets applications call dozens of different large language model providers through a single, unified interface, handling authentication, rate limiting, and cost tracking in one layer.
What are the main vulnerabilities disclosed by Wiz?
Wiz disclosed CVE-2026-59822, an MCP authentication bypass using an arbitrary Bearer token; CVE-2026-59821, a post-authentication path to root-level remote code execution through custom code guardrails; an unauthenticated administrator access issue with no assigned CVE; and a cloud-credential theft vector tied to a pass-through endpoint lacking URL validation.
Is CVE-2026-59822 being actively exploited?
Yes. Wiz says it observed exploitation of CVE-2026-59822 in the wild through its honeypot infrastructure, and the vulnerability has been added to CISA’s Known Exploited Vulnerabilities catalog.
How many LiteLLM deployments are actually exposed?
Wiz scanned 3,074 publicly accessible LiteLLM instances and found that 9.6% accepted the default master key sk-1234 or required no authentication at all. A separate report put the raw count at 294 of the 3,074 instances scanned.
How do I fix a vulnerable LiteLLM deployment?
Upgrade to LiteLLM 1.83.9 or a later release, which includes fixes for CVE-2026-35029 and CVE-2026-59823, replace any default master key with a unique rotated credential, explicitly configure authentication rather than relying on defaults, and audit MCP and pass-through endpoint configurations.
Does this affect millions of users, as some headlines suggest?
The confirmed data from Wiz covers exposed instance counts, roughly 3,074 scanned with about 9.6% unprotected, rather than a verified figure for total affected end users. Reports describing millions of affected users are extrapolating from LiteLLM’s broad adoption rather than citing a confirmed user count.
Is LiteLLM the most widely used open-source AI gateway?
Independent research from Check Point describes LiteLLM as one of the most widely used LLM gateways in production, though available sources do not establish a definitive ranking against every competing open-source or commercial alternative.
What should enterprises do if they cannot patch immediately?
At minimum, remove any internet-facing exposure of the LiteLLM admin interface, rotate the default master key, and explicitly enforce authentication, since the unauthenticated-admin-access issue and the default-key exposure can be mitigated even before a full version upgrade is completed.
