Threat
Critical Bifrost AI Gateway Flaw Lets Attackers Run Commands Without Credentials
Publication date not yet evaluated · Added · 10 reports thehackernews.com
Page published · Page updated
Coverage timeline
Why it matters
CVE-2026-59822 shows that an AI gateway/MCP relay treated as a trust boundary can grant unauthenticated attackers access to every connected tool and service, making the proxy layer a critical attack surface defenders must patch and segment.
CVE-2026-59822 is a critical authentication bypass in LiteLLM's Model Context Protocol (MCP) handler, where a failed API-key validation falls back to an empty UserAPIKeyAuth() object, letting a request with a fabricated Authorization Bearer header reach underlying MCP tooling. Rated CVSS 8.8, it allows an unauthenticated remote attacker to list and execute configured MCP tools; maintainers patched it in LiteLLM 1.84.0 and CISA added it to the KEV catalog on September 2, 2026 as the first MCP-related flaw listed.
Summary
CVE-2026-59822 is a critical improper-authentication (MCP auth bypass) vulnerability in BerriAI's LiteLLM proxy, rated CVSS 8.8. It originates in the MCP authentication handler: when incoming API-key validation fails, LiteLLM's OAuth2 passthrough fallback substitutes an empty UserAPIKeyAuth() object rather than rejecting the request, allowing a fabricated Authorization Bearer header to bypass security checks and reach the underlying MCP tooling. An unauthenticated remote attacker can thereby list and execute configured MCP tools and reach connected services.[0][11]
CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 2, 2026 as part of a batch of seven additions — reported as the first MCP-related flaw to appear in the KEV. Notwithstanding the KEV listing, the current reporting states there is no evidence of public exploitation, no published proof-of-concept exploit, and no confirmed active campaigns.[0][12][15]
The vulnerability affects all LiteLLM versions prior to 1.84.0. Maintainers released the fix in version 1.84.0 on May 14, 2026, ensuring the OAuth2 passthrough fallback executes only when every targeted server is explicitly configured with auth_type=oauth2. Organizations unable to update immediately are advised to disable MCP routes or block access to /mcp/ endpoints.[0]
Disclosure timeline
| Date | Event |
|---|---|
| 2026-05-14 | Maintainers released LiteLLM v1.84.0 fixing CVE-2026-59822 by restricting the OAuth2 passthrough fallback to servers explicitly configured with auth_type=oauth2.[0] |
| 2026-09-02 | CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog as part of a seven-vulnerability batch (reported as the first MCP-related flaw in the KEV); the KEV catalog page reflects a 09-02-2026 update and CISA issued an alert on the same date.[0][12][15] |
How it works
The vulnerability resides in how LiteLLM manages authentication for upstream MCP servers. When LiteLLM attempts to validate an incoming API key, a validation failure triggers a fallback intended to support OAuth2 passthrough. Instead of rejecting the request on failed validation, the system substitutes an empty UserAPIKeyAuth() object. This fail-open logic error lets a request bearing a fabricated Authorization Bearer header bypass standard security checks and reach the underlying MCP tooling, enabling an unauthenticated caller to enumerate and execute MCP tools.[0]
The fix in v1.84.0 modifies the authentication logic so the OAuth2 passthrough fallback only executes when every targeted server is explicitly configured by an operator with auth_type=oauth2, preventing a fabricated Bearer token from silently reaching MCP tooling.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| BerriAI LiteLLM — MCP authentication handler | All versions prior to 1.84.0 (deployments exposing MCP tooling through the proxy) | Fixed in v1.84.0, released May 14, 2026; workaround is to disable MCP routes or block /mcp/ endpoints. Listed in CISA KEV as of September 2, 2026.[0][11][12] |
Key takeaways
- CVE-2026-59822 is reported as the first MCP-related vulnerability added to the CISA KEV catalog, highlighting that MCP intermediary/relay layers must be governed as security boundaries in enterprise LLM integrations.[0][12]
- A fail-open logic error — substituting an empty auth object on validation failure — turned a fallback path into a full unauthenticated bypass, illustrating the danger of fallback authentication that does not reject failed key validation.[0]
- Despite the KEV listing, current reporting states there is no evidence of public exploitation, no published PoC, and no confirmed active campaigns; the primary risk is exposure of any tools and services connected to the LiteLLM proxy.[0]
Defensive actions
- Upgrade LiteLLM to version 1.84.0 or later.: All versions prior to 1.84.0 are affected; the patch restricts the OAuth2 passthrough fallback so a fabricated Bearer token can no longer reach MCP tooling.[0]
- If immediate patching is not possible, disable MCP routes or block access to /mcp/ endpoints entirely.: This is the reporting-recommended workaround that removes the exposed MCP interface an unauthenticated attacker would abuse.[0]
- Treat the LiteLLM relay/proxy layer as a critical security boundary and validate requests at the proxy rather than relying on upstream MCP servers for authentication.: The flaw shows that relying on upstream servers to handle authentication is insufficient if the proxy does not validate the request before transmission.[0]