CVE-2026-59822 is a high-severity authentication bypass vulnerability affecting LiteLLM’s Model Context Protocol, or MCP, Streamable HTTP endpoint. The flaw can allow an unauthenticated remote attacker to establish what the application treats as an authenticated MCP session by supplying a fabricated Bearer token.
The vulnerability is particularly significant because LiteLLM is not simply another web application. It is commonly deployed as an AI gateway between applications, large language model providers, and increasingly MCP-connected tools and internal services.
According to LiteLLM’s official GitHub Security Advisory, versions earlier than 1.84.0 are affected. The vulnerable MCP authentication handler could replace a failed LiteLLM key validation with an empty UserAPIKeyAuth() object during an OAuth2 passthrough fallback. As a result, requests containing a fabricated Authorization header could reach configured MCP tooling without a valid LiteLLM API key. (GitHub)
The security impact is no longer theoretical.
In September 2026, Wiz Research disclosed that it had observed CVE-2026-59822 being exploited in its honeypot infrastructure. Wiz also reported that the vulnerability was exploitable across hundreds of Internet-facing LiteLLM deployments examined during its research. (wiz.io)
CVE-2026-59822 was subsequently added to the CISA Known Exploited Vulnerabilities catalog on September 2, 2026, with a remediation date of September 16, 2026 for organizations subject to the relevant federal requirements. (Security Intel Hub)
As of September 18, 2026, that remediation date has already passed.
For security teams running LiteLLM, CVE-2026-59822 should therefore be treated not merely as another High-severity CVE, but as an authentication vulnerability affecting a security-sensitive AI infrastructure layer with evidence of real-world exploitation.
CVE-2026-59822 at a Glance
| Attribute | Details |
|---|---|
| CVE | CVE-2026-59822 |
| Product | BerriAI LiteLLM |
| Component | MCP Streamable HTTP endpoint |
| Vulnerability | Authentication bypass |
| Primary CWE | CWE-287 Improper Authentication |
| CVSS v4.0 | 8.8 High |
| CVSS v3.1 | 8.2 High |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Affected Versions | LiteLLM < 1.84.0 |
| Patched Version | LiteLLM >= 1.84.0 |
| Real-world exploitation | Observed |
| CISA KEV | Added September 2, 2026 |
GitHub assigns CVE-2026-59822 a CVSS v4.0 score of 8.8, with the vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:NThat means exploitation can occur over the network, requires low attack complexity, requires no prior privileges, and does not require interaction from a legitimate user. (GitHub)
NVD and Red Hat also track the vulnerability as a network-accessible authentication flaw. Red Hat’s analysis emphasizes that practical exposure requires the LiteLLM proxy to actually be running with the relevant MCP HTTP authentication path exposed. (Red Hat Customer Portal)
That distinction becomes important when security scanners detect LiteLLM merely because the Python dependency is present.
What Is LiteLLM?
LiteLLM is an open-source AI gateway and proxy that provides a unified interface for interacting with many large language model providers.
Instead of every application implementing separate integrations for model providers such as OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, or Google Vertex AI, organizations can route requests through LiteLLM.
Conceptually:
Application
|
v
LiteLLM Gateway
|
+------ OpenAI
|
+------ Anthropic
|
+------ AWS Bedrock
|
+------ Vertex AI
|
+------ Other LLM ProvidersThis allows organizations to centralize functions such as routing, API-key management, budget enforcement, logging, access control, rate limiting, guardrails, and provider abstraction.
Wiz describes LiteLLM as a central AI gateway capable of holding model-provider credentials, processing prompts and responses, and connecting AI systems to external tooling through MCP. Its research found LiteLLM broadly deployed across cloud environments, making weaknesses in the gateway potentially relevant far beyond the individual application using it. (wiz.io)
The introduction of MCP makes that security boundary even more important.
What Does MCP Change?
Model Context Protocol allows AI clients and agents to connect to external data sources and tools using a standardized interface.
Instead of an LLM only producing text, an MCP-enabled agent may interact with capabilities such as:
LLM / AI Agent
|
v
LiteLLM
|
v
MCP Gateway
|
+---- Database tools
|
+---- Git repositories
|
+---- Internal APIs
|
+---- SaaS applications
|
+---- Cloud services
|
+---- File or knowledge systemsThis creates an important distinction between traditional AI API security and agent security.
A compromised model API may expose inference capability.
A compromised tool gateway may expose actions.
If an MCP server provides tools capable of accessing databases, modifying repositories, invoking internal APIs, or interacting with cloud resources, authentication protecting those tools becomes a highly sensitive security boundary.
CVE-2026-59822 attacks exactly that boundary.
The Root Cause of CVE-2026-59822
LiteLLM’s MCP authentication handler needed to support two different authentication scenarios.
One was normal LiteLLM authentication.
A client provides a valid LiteLLM API key:
Authorization: Bearer <LiteLLM-key>LiteLLM verifies that key and associates the request with the corresponding user, team, permissions, or policy.
The second scenario involved OAuth2 passthrough.
Some upstream MCP services authenticate users independently using OAuth2. In that architecture, a Bearer token may not be a LiteLLM API key at all. It may instead be a token intended for an upstream provider such as an MCP service.
Supporting that architecture is reasonable.
The problem was how LiteLLM decided when authentication failure should become OAuth2 passthrough.
According to the official LiteLLM advisory, the vulnerable handler could catch failed LiteLLM key validation and replace that failure with an empty UserAPIKeyAuth() object. (GitHub)
The logic can be simplified conceptually as:
try:
auth = validate_litellm_api_key(token)
except AuthenticationError:
if oauth2_headers_exist:
auth = UserAPIKeyAuth()This pseudocode is intentionally simplified, but it illustrates the core trust failure.
A failed LiteLLM credential effectively became a signal that the request might instead contain an OAuth2 credential.
That introduces ambiguity.
The system cannot safely infer:
LiteLLM authentication failed
=
This must be a legitimate upstream OAuth2 tokenbecause authentication failure could simply mean:
The attacker supplied an invalid token.The authentication path therefore failed open.
Why an Arbitrary Bearer Token Could Work
The official security advisory states that an unauthenticated attacker could establish an authenticated MCP session using an arbitrary Bearer token. (GitHub)
The attack does not require stealing a legitimate LiteLLM API key first.
Instead, the attacker can submit an invalid credential.
The vulnerable state transition looks roughly like this:
Incoming MCP request
|
v
Authorization header exists
|
v
Validate as LiteLLM key
|
X
Validation fails
|
v
OAuth2 passthrough fallback
|
v
Empty UserAPIKeyAuth()
|
v
Request continuesThe problem is not that the attacker’s Bearer token itself suddenly becomes valid.
The problem is that the failed validation result is replaced with an object the downstream code treats as sufficiently authenticated.
That difference matters when explaining CVE-2026-59822 accurately.
This Is a Classic Fail-Open Authentication Bug
The safest authentication architecture normally behaves like this:
Credential
|
v
Validate
|
+---- Valid ----> Continue
|
+---- Invalid --> RejectThe vulnerable LiteLLM behavior introduced another branch:
Credential
|
v
Validate
|
+---- Valid --------------------> Continue
|
+---- Invalid
|
v
Maybe OAuth2?
|
v
Continue anywayThe patched design is more restrictive.
The application now checks whether the targeted MCP servers are actually configured to use OAuth2 before allowing this passthrough behavior.
This converts the trust decision from:
"The token failed LiteLLM authentication,
so perhaps it belongs upstream."to something closer to:
"This MCP target is explicitly configured by
the operator to use OAuth2, therefore OAuth2
passthrough is allowed here."That is a much stronger security boundary.
LiteLLM’s Fix Tightened OAuth2 Fallback Gating
The relevant LiteLLM patch was associated with PR #26463, described as:
“fix(mcp): tighten public-route detection and OAuth2 fallback gating.”
The fix changed the OAuth2 fallback so it would only be used when the target MCP server configuration indicates OAuth2 should actually be used.
The root-cause analysis associated with the patch explains that the corrected implementation checks the target servers rather than merely treating an authentication error as sufficient evidence of OAuth2 intent. (GitHub)
Conceptually:
try:
auth = validate_litellm_api_key(token)
except AuthenticationError:
if target_mcp_servers_are_oauth2():
auth = UserAPIKeyAuth()
else:
raiseAgain, this is explanatory pseudocode rather than copied source code.
The important security property is that OAuth2 fallback is now based on trusted configuration, rather than the attacker’s ability to trigger a failed authentication attempt.
The .well-known Authentication Problem
The same LiteLLM MCP authentication work also addressed another route-classification weakness.
The vulnerable code used a broad condition that effectively searched for .well-known in the complete request URL.
Conceptually:
if ".well-known" in str(request.url):
allow_public_route()The intent was presumably to allow legitimate /.well-known/... endpoints needed by protocol discovery.
The security issue is that a URL contains more than its path.
Depending on the request and framework representation, attacker-controlled content may appear in the query string and other URL components.
The patch instead tightened the check toward the actual URL path:
request.url.path.startswith("/.well-known/")The root-cause documentation and LiteLLM fix both identify this public-route classification weakness alongside the OAuth2 fallback problem. (GitHub)
The broader lesson is important:
Public endpoint exemptions should be matched structurally, not through broad substring searches over attacker-controlled input.
Why CVE-2026-59822 Is More Serious Than a Normal API Auth Bypass
An ordinary authentication bypass may expose an API.
An MCP authentication bypass can expose a collection of capabilities.
LiteLLM’s official advisory explicitly states that successful exploitation may allow an attacker to list and call configured MCP tools and access connected services exposed through MCP. (GitHub)
Suppose an organization exposes MCP tools equivalent to:
search_documents
read_database
query_customer_data
create_issue
update_ticket
search_repository
execute_internal_workflowCrossing the MCP authentication boundary could expose some or all of those capabilities, depending on the deployment.
This does not mean CVE-2026-59822 automatically grants remote code execution or cloud administrator privileges.
The CVE itself is an authentication bypass.
The final blast radius depends heavily on the tools behind the gateway and the credentials those tools possess.
That distinction is critical.
CVE-2026-59822 Is Not an RCE by Itself
Several LiteLLM vulnerabilities have been disclosed during 2026, making it easy to confuse them.
CVE-2026-59822 is the MCP authentication bypass.
Wiz’s research separately discusses CVE-2026-59821, which affected LiteLLM Custom Code Guardrails and could produce code-execution consequences under its corresponding prerequisites. (wiz.io)
Security teams should therefore avoid headlines such as:
“CVE-2026-59822 Gives Attackers Remote Code Execution”
unless discussing a separately demonstrated exploit chain.
A more accurate statement is:
CVE-2026-59822 can bypass authentication protecting LiteLLM MCP tools. The downstream impact depends on the capabilities exposed by those tools.
This distinction makes the technical analysis both more credible and more useful.
Real-World Exploitation Has Been Observed
The most important development since the original vulnerability disclosure is evidence of real-world exploitation.
Wiz Research reported that CVE-2026-59822 was exploited against its AI infrastructure honeypots.
Its honeypot research observed requests involving extremely weak Bearer values, demonstrating how little sophistication may be needed to probe vulnerable authentication behavior. (wiz.io)
Wiz’s broader LiteLLM research states that CVE-2026-59822 was confirmed exploitable across hundreds of Internet-facing instances examined during its work and that activity exploiting the issue was observed in the wild. (wiz.io)
That materially changes vulnerability prioritization.
Before confirmed exploitation, defenders might prioritize the issue based primarily on CVSS and exposure.
After exploitation is observed, the question becomes:
Was our infrastructure exposed while this vulnerability was reachable?
That requires both remediation and retrospective investigation.
CISA Added CVE-2026-59822 to KEV
CVE-2026-59822 was added to the CISA Known Exploited Vulnerabilities catalog on September 2, 2026.
The listed remediation date was September 16, 2026. (Security Intel Hub)
Inclusion in the KEV catalog reflects evidence of exploitation rather than simply theoretical exploitability.
This does not mean every vulnerable LiteLLM instance has been compromised.
It does mean defenders should avoid treating CVE-2026-59822 as a low-priority backlog item solely because their normal vulnerability workflow contains other Critical-rated vulnerabilities.
Exposure matters.
Confirmed exploitation matters.
And the privilege of the MCP-connected systems matters.
CVSS 8.8 Versus Practical Risk
GitHub scores CVE-2026-59822 at 8.8 High under CVSS v4.0. (GitHub)
Red Hat and NVD also track a CVSS v3.1 score of 8.2 High. (Red Hat Customer Portal)
Those scores describe the vulnerability itself.
They do not completely describe the organization’s MCP environment.
Consider two deployments.
Deployment A
LiteLLM exposes an MCP tool capable only of retrieving publicly available documentation.
An authentication bypass is still undesirable, but the data and privilege available behind it may be limited.
Deployment B
LiteLLM exposes tools connected to:
production databases
source repositories
internal APIs
cloud automation
ticketing systems
private knowledge basesThe same vulnerability may have much greater consequences.
This is why CVSS should be combined with architecture-specific exposure analysis.
MCP Turns Identity Into Capability
Traditional application security often frames authorization around resources.
For example:
Can Alice read customer record 123?Agent security adds another dimension:
Can Alice call tool X?and potentially:
Can tool X perform action Y using service account Z?That creates a delegation chain:
User
|
v
AI Gateway
|
v
Agent
|
v
MCP Tool
|
v
Backend ServiceIf authentication fails at the gateway, every downstream service may still see perfectly legitimate requests.
For example, an attacker reaches an MCP tool without authentication.
The MCP tool then queries a production database using its legitimate database service account.
The database does not necessarily know that the original caller was unauthorized.
It only sees:
Trusted MCP Service -> Database QueryThis is one reason agent infrastructure needs strong identity propagation and auditability.
Public LiteLLM Exposure Is Already a Security Concern
Wiz’s LiteLLM research scanned 3,074 publicly accessible deployments and reported that 9.6% accepted the default sk-1234 master key or required no authentication at the time of testing. (wiz.io)
This statistic should not be confused with CVE-2026-59822 vulnerability prevalence.
It describes a separate deployment-security problem.
But it demonstrates that weak authentication and Internet exposure already exist in part of the LiteLLM ecosystem.
That matters because real attackers typically do not distinguish neatly between:
application vulnerability
configuration error
default credential
weak IAM
network exposureThey combine whatever works.
Which LiteLLM Versions Are Affected?
The official GitHub advisory gives a simple version boundary:
Affected:
LiteLLM < 1.84.0
Patched:
LiteLLM >= 1.84.0(GitHub)
LiteLLM’s official release documentation confirms version 1.84.0 and provides deployment examples for both Python and containers. (GitHub)
At the time of writing, LiteLLM has continued releasing newer versions, so organizations should generally move to an appropriately tested current supported release rather than assuming 1.84.0 is the latest available version. GitHub’s current releases page shows subsequent releases well beyond 1.84.0. (GitHub)
For vulnerability remediation specifically, however, 1.84.0 is the security boundary relevant to CVE-2026-59822.
How to Check Your LiteLLM Version
Python deployments can inspect the installed package:
python -m pip show litellmor:
pip show litellmAnother option:
python -m pip freeze | grep -i litellmContainerized environments should inspect the actual image running in production rather than relying solely on repository dependency files.
This distinction matters in Kubernetes and other orchestrated environments where an old pod or task may remain active even after configuration has changed.
The security question is:
What version is actually serving requests?
not:
What version does our current source tree specify?
Package Presence Does Not Automatically Mean Exploitability
Red Hat provides a useful example.
Some Red Hat products may include LiteLLM as a Python dependency but are not affected under their default configurations because they do not launch the LiteLLM proxy or expose its MCP HTTP authentication path. (Red Hat Customer Portal)
Therefore:
LiteLLM dependency detecteddoes not automatically equal:
CVE-2026-59822 remotely exploitableFor exploitation to matter, the relevant code path must actually be reachable.
Security teams should verify:
- LiteLLM proxy is running.
- The version is older than 1.84.0.
- MCP Streamable HTTP functionality is enabled.
- The endpoint is reachable by the attacker population being assessed.
- Relevant MCP tooling is configured behind it.
Those conditions give far better prioritization than dependency scanning alone.
How to Identify Exposed MCP Attack Surface
Begin with architecture.
Determine where LiteLLM is deployed and which interfaces it exposes.
Inspect ingress rules, reverse proxies, load balancers, API gateways, Kubernetes Services, and firewall policies.
Then identify MCP configuration.
For example, defenders may search configuration repositories for MCP-related settings:
grep -Rni "mcp" /path/to/config/The goal is not merely to answer:
Do we use LiteLLM?The real questions are:
Do we expose MCP?
Who can reach it?
Which tools are registered?
What can those tools do?
What credentials do those tools use?This turns a CVE ticket into an attack-path assessment.
Detection Opportunities for CVE-2026-59822
Because active exploitation has been reported, upgrading the package should not automatically close the incident.
Security teams should review historical activity for the period when vulnerable endpoints were reachable.
Useful telemetry includes LiteLLM application logs, ingress logs, reverse proxy logs, WAF telemetry, MCP audit records, API gateway logs, and downstream service logs.
Particularly interesting activity includes unexpected MCP requests originating from unknown addresses and successful MCP operations that cannot be mapped to legitimate authenticated users.
MCP methods associated with tool discovery and invocation deserve particular attention.
Conceptually:
Unknown source
|
v
MCP request
|
v
Tool enumeration
|
v
Tool invocation
|
v
Backend service accessWiz’s analysis recommends examining anomalous MCP activity and Bearer-token behavior when evaluating potential exploitation. (wiz.io)
Correlate Authentication With Tool Execution
One of the strongest detection strategies is to correlate identity events with MCP capability use.
Suppose your MCP logs show:
tool_call = search_customer_database
status = successThat event should ideally correlate with:
user identity
API key
team
session
source
authorization decisionIf a successful MCP tool call exists without a corresponding valid authenticated identity, the event deserves investigation.
This is particularly relevant to CVE-2026-59822 because the vulnerability creates precisely that mismatch:
Authentication state:
Invalid or absent
Application execution state:
Allowed to continueDetection systems should look for inconsistencies between those states.
Do Not Stop at LiteLLM Logs
MCP can delegate actions into downstream systems.
If CVE-2026-59822 exploitation is suspected, investigation may therefore need to extend beyond LiteLLM.
Relevant sources may include database audit logs, cloud control-plane logs, Git provider events, SaaS logs, Kubernetes audit records, secret-manager activity, service-account activity, and network telemetry.
Consider:
Attacker
|
v
CVE-2026-59822
|
v
MCP Tool
|
v
Production DatabaseThe database may record only the MCP service identity.
Therefore a seemingly legitimate database query may actually have originated from an unauthorized MCP request.
This is why agent-security investigations increasingly require cross-system identity correlation.
How to Fix CVE-2026-59822
The primary remediation is straightforward:
Upgrade LiteLLM to version 1.84.0 or later.
The official GitHub Security Advisory explicitly recommends upgrading to 1.84.0 or newer. (GitHub)
LiteLLM’s release documentation provides the corresponding package and container examples. (GitHub)
For Python environments:
python -m pip install --upgrade "litellm>=1.84.0"After updating, confirm the runtime version:
python -m pip show litellmThen restart or redeploy the proxy so that running processes use the patched code.
Temporary Mitigation When Immediate Upgrade Is Impossible
LiteLLM’s advisory also provides a workaround.
If upgrading cannot be performed immediately, administrators should disable MCP routes or block /mcp/ and related MCP endpoints at the reverse proxy or API gateway. (GitHub)
Conceptually:
Internet
|
v
Reverse Proxy
|
X
Block MCP routes
|
v
LiteLLMThis can remove the reachable attack surface while teams prepare a controlled upgrade.
If an organization does not use MCP at all, disabling the feature is preferable to exposing unused functionality.
Restrict MCP From the Public Internet
Patching CVE-2026-59822 solves the known vulnerability.
It does not eliminate the broader risk of exposing powerful tool gateways directly to untrusted networks.
A stronger architecture might resemble:
Internet
|
v
Edge Gateway
|
v
Authentication / Authorization
|
v
Private Application Network
|
v
LiteLLM
|
v
Restricted MCP Network
|
v
MCP ServersMultiple security boundaries help ensure that failure in one component does not automatically expose every connected tool.
Apply Least Privilege to Every MCP Tool
The best way to reduce the blast radius of future MCP vulnerabilities is to assume the gateway could eventually fail.
An MCP database connector should not automatically use database administrator credentials.
A repository integration should not automatically receive organization-wide administration.
A cloud tool should not automatically inherit broad account-level permissions.
Prefer:
MCP Database Tool
|
v
Read-only database rolerather than:
MCP Database Tool
|
v
Database administratorLikewise:
MCP Git Tool
|
v
Selected repositoriesrather than:
MCP Git Tool
|
v
Entire organizationLeast privilege turns an authentication bypass from an unrestricted infrastructure compromise into a narrower security incident.
AI Gateways Should Be Treated as Tier-1 Infrastructure
One of the most important implications of CVE-2026-59822 is architectural.
AI gateways were initially treated by many organizations as application infrastructure.
That assumption is becoming outdated.
A gateway such as LiteLLM can potentially mediate:
LLM API keys
cloud identities
application identities
prompt and response traffic
MCP services
internal APIs
tool permissions
model routing
cost controls
security guardrailsWiz argues that AI gateways should increasingly be considered critical infrastructure because they occupy a highly privileged position between applications, model providers, tools, and cloud resources. (wiz.io)
CVE-2026-59822 reinforces that argument.
The vulnerability itself is not an exotic AI jailbreak.
It is an authentication failure.
But it occurs at an infrastructure layer capable of delegating actions into other systems.
The Broader MCP Security Lesson
Much of the current MCP security discussion centers on prompt injection, malicious tool descriptions, poisoned MCP servers, tool shadowing, context manipulation, and agent decision-making.
Those risks are important.
CVE-2026-59822 demonstrates something more fundamental:
MCP still depends on traditional authentication and authorization working correctly.
An organization can build sophisticated prompt-injection defenses and still lose control of its MCP infrastructure if attackers can bypass the gateway’s authentication entirely.
A mature MCP security architecture therefore requires several layers:
Authentication
|
v
Authorization
|
v
MCP Server Access Control
|
v
Tool-Level Permissions
|
v
Input Validation
|
v
Credential Isolation
|
v
Network Segmentation
|
v
Audit and DetectionAgent-level security cannot replace identity security.
Authentication Fallbacks Need Explicit Trust Boundaries
CVE-2026-59822 also offers a broader software-engineering lesson.
Many modern services support multiple authentication methods:
API keys
OAuth2
JWTs
service accounts
mTLS
session tokens
signed requestsProblems emerge when the implementation effectively behaves like:
Try authentication method A.
If it fails, maybe this was method B.
Continue.A safer model is:
Determine authentication mechanism
from trusted configuration
|
v
Validate that mechanism
|
+---- Valid ---> Continue
|
+---- Invalid -> RejectThe authentication mechanism itself should ideally be selected independently of whether an attacker can intentionally cause another mechanism to fail.
Route Exceptions Are Security Controls
The .well-known issue fixed alongside CVE-2026-59822 illustrates another common application-security mistake.
Applications frequently have public routes:
/health
/.well-known/...
/oauth/callbackThose endpoints may legitimately bypass normal authentication.
But route matching must be exact enough to describe the intended security boundary.
Weak:
if ".well-known" in full_url:
public = TrueBetter:
if request.url.path.startswith("/.well-known/"):
public = TrueAuthentication exceptions are effectively security policy.
They should therefore be implemented as structured policy rather than informal string matching.
Incident Response Checklist for CVE-2026-59822
Organizations that operated vulnerable LiteLLM deployments should answer five questions.
First, determine whether a version earlier than 1.84.0 was actually running.
Second, determine whether MCP routes were enabled and reachable.
Third, identify unusual MCP requests during the vulnerable period.
Fourth, inventory every tool and backend service reachable through the affected MCP gateway.
Fifth, correlate suspicious MCP sessions with activity in those downstream systems.
If unauthorized access cannot be ruled out, credentials available to affected MCP tools may need to be reviewed or rotated according to the organization’s incident-response policy.
The key is not to assume:
Patched today
=
No compromise yesterdaybecause Wiz has already documented exploitation activity. (wiz.io)
Frequently Asked Questions
What is CVE-2026-59822?
CVE-2026-59822 is an authentication bypass affecting LiteLLM’s MCP Streamable HTTP endpoint.
A fabricated Authorization header could trigger an OAuth2 fallback path in which failed LiteLLM key validation was replaced by an empty authentication object, allowing the request to proceed into MCP functionality. (GitHub)
Which versions are vulnerable?
LiteLLM versions earlier than 1.84.0 are affected.
Version 1.84.0 contains the fix. (GitHub)
What is the CVSS score?
GitHub assigns CVE-2026-59822 a CVSS v4.0 score of 8.8 High. (GitHub)
Red Hat and NVD track CVSS v3.1 at 8.2 High. (Red Hat Customer Portal)
Does exploitation require authentication?
No.
The vulnerability is specifically an authentication bypass and is remotely reachable under affected deployment conditions.
Is CVE-2026-59822 actively exploited?
There is documented evidence of exploitation.
Wiz reported observing exploitation in honeypot infrastructure, and CVE-2026-59822 was added to CISA’s Known Exploited Vulnerabilities catalog on September 2, 2026. (wiz.io)
Can CVE-2026-59822 give attackers RCE?
The CVE itself should not be described as an RCE vulnerability.
It provides unauthorized access to MCP functionality.
If the exposed MCP tools themselves provide dangerous capabilities, those capabilities may increase downstream impact.
LiteLLM has had separate vulnerabilities involving code execution, including CVE-2026-59821, but those should not be conflated with CVE-2026-59822. (wiz.io)
Can attackers call MCP tools?
Yes.
The official LiteLLM advisory states that exploitation could allow attackers to list and call configured MCP tools and access connected services exposed through MCP. (GitHub)
Does every installation containing LiteLLM need emergency remediation?
Exposure should be verified.
Red Hat notes that some products contain LiteLLM only as a client dependency and do not expose the vulnerable LiteLLM proxy MCP authentication path in default configurations. (Red Hat Customer Portal)
A vulnerable package version therefore needs to be evaluated together with actual runtime configuration and endpoint exposure.
How should CVE-2026-59822 be fixed?
Upgrade LiteLLM to 1.84.0 or later.
If immediate upgrading is impossible, LiteLLM recommends disabling MCP routes or blocking /mcp/ and related MCP endpoints through a reverse proxy or API gateway. (GitHub)
Final Assessment
CVE-2026-59822 is one of the more instructive AI infrastructure vulnerabilities of 2026 because it combines a traditional authentication flaw with a modern agentic attack surface.
At the code level, the vulnerability originated from authentication fallback logic.
A failed LiteLLM credential could enter an OAuth2 passthrough branch and receive an empty UserAPIKeyAuth() object instead of being rejected. That allowed arbitrary Bearer tokens to cross a security boundary protecting MCP functionality. (GitHub)
LiteLLM 1.84.0 fixed the issue by tightening OAuth2 fallback behavior and related MCP routing checks. (GitHub)
But the larger story is what existed behind that authentication boundary.
MCP transforms AI infrastructure from a system that merely produces model output into a system capable of reaching tools, data sources, APIs, and operational services.
Consequently:
Authentication bypass
|
v
MCP access
|
v
Tool access
|
v
Downstream capabilityThe security impact increasingly depends on that final capability.
Wiz’s observation of exploitation activity and the subsequent addition of CVE-2026-59822 to CISA’s Known Exploited Vulnerabilities catalog mean organizations should not treat this as a purely academic MCP security flaw. (wiz.io)
For defenders, the immediate actions are clear: identify vulnerable LiteLLM proxy deployments, verify whether MCP routes were exposed, upgrade to version 1.84.0 or later, investigate historical MCP activity, and assess the permissions available to connected tools.
For AI security architects, the longer-term lesson is even more important.
The AI gateway is becoming an identity and capability gateway.
As agents gain access to databases, repositories, APIs, cloud services, and automation systems, the authentication layer protecting those tools must be treated with the same seriousness as any other privileged infrastructure control plane.
And CVE-2026-59822 demonstrates what happens when that boundary fails.
Key Sources
The primary vulnerability description is the LiteLLM / GitHub Security Advisory GHSA-7488-6r32-c95q, which documents the affected versions, authentication bypass mechanism, MCP impact, patched version, and workaround. GitHub Security Advisory for CVE-2026-59822
The LiteLLM project documentation provides the v1.84.0 release information and deployment details for the patched release. LiteLLM v1.84.0 release documentation
Wiz Research’s Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise provides the most useful current analysis of Internet-facing LiteLLM exposure, CVE-2026-59822 exploitation, and the broader cloud-security implications. Wiz Research LiteLLM vulnerability analysis
Wiz’s Attacks on AI Infrastructure: 90-Day Honeypot Telemetry provides the supporting evidence around real-world exploitation activity observed against AI infrastructure. Wiz AI infrastructure honeypot research
Red Hat’s CVE analysis is useful for understanding an important deployment nuance: having LiteLLM installed as a dependency does not necessarily mean the vulnerable proxy/MCP path is reachable. Red Hat CVE-2026-59822 analysis
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew