Staging Environment: Content and features may be unstable or change without notice.

Advisory Package Curation

CVE-2026-59822

Progress 0 / 0

Advisory Summaries

github_osv/GHSA-7488-6r32-c95q

LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback ### Impact LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token. The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty `UserAPIKeyAuth()` object. This allowed requests with a fabricated `Authorization` header to reach MCP tooling without a valid LiteLLM key. An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP. ### Patches The issue is fixed in `1.84.0`. We recommend upgrading to `1.84.0` or later. ### Workarounds If upgrading is not immediately possible, disable MCP routes or block access to `/mcp/` and related MCP endpoints at your reverse proxy or API gateway. ### References * v1.84.0 https://github.com/BerriAI/litellm/releases/tag/v1.84.0

gitlab/pypi/litellm/CVE-2026-59822

LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token. The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty `UserAPIKeyAuth()` object. This allowed requests with a fabricated `Authorization` header to reach MCP tooling without a valid LiteLLM key. An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP.

pypa/litellm/PYSEC-2026-3479

LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback ### Impact LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token. The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty `UserAPIKeyAuth()` object. This allowed requests with a fabricated `Authorization` header to reach MCP tooling without a valid LiteLLM key. An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP. ### Patches The issue is fixed in `1.84.0`. We recommend upgrading to `1.84.0` or later. ### Workarounds If upgrading is not immediately possible, disable MCP routes or block access to `/mcp/` and related MCP endpoints at your reverse proxy or API gateway. ### References * v1.84.0 https://github.com/BerriAI/litellm/releases/tag/v1.84.0

pysec/PYSEC-2026-3479

LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback ### Impact LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token. The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty `UserAPIKeyAuth()` object. This allowed requests with a fabricated `Authorization` header to reach MCP tooling without a valid LiteLLM key. An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP. ### Patches The issue is fixed in `1.84.0`. We recommend upgrading to `1.84.0` or later. ### Workarounds If upgrading is not immediately possible, disable MCP routes or block access to `/mcp/` and related MCP endpoints at your reverse proxy or API gateway. ### References * v1.84.0 https://github.com/BerriAI/litellm/releases/tag/v1.84.0