Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
31 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An authenticated LiteLLM proxy user could read arbitrary local files from the proxy runtime by sending a crafted `vertex_ai_credentials` value to `/utils/transform_request`. The request-body safety blocklist rejected `vertex_credentials` but missed its alias `vertex_ai_credentials`, which let the value reach the Vertex AI credential loader and trigger a file read that is sent to an attacker-controlled URL. Impact A low-privilege authenticated user (only `internal_user_viewer`, obtainable through SSO login on many deployments) could read any file readable by the LiteLLM process. Reading files such as `/proc/self/environ` can disclose `LITELLM_MASTER_KEY` and provider API keys, so the impact can escalate to full proxy-admin control. Remediation Upgrade to `1.95.0` or later. The fix adds the missing alias to the request-body blocklist, so no configuration change is needed once you upgrade. There is no reliable configuration workaround on affected versions.
Recommended action: Upgrade to 1.95.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `/sso/debug/callback` endpoint reflected identity-provider-controlled fields into an inline ` ` block via `json.dumps`, which escapes JSON string syntax but not HTML context characters such as ` `. An IdP-returned string field containing ` ` (for example a user-editable display name) closed the script block and executed attacker JavaScript in the proxy's origin. Impact Reflected XSS on the LiteLLM proxy origin. The route required no authentication, so an attacker with an account on the configured IdP whose claims pass such strings through verbatim could complete the SSO flow themselves and deliver the resulting callback URL to a logged-in proxy admin. Scripts executing in the proxy origin can read the dashboard session cookie and act with the victim's privileges, up to full admin account takeover.
Recommended action: Upgrade to 1.85.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.102.21.100.41.104.0rc21.103.11.101.3· Vendor fix available
Issue
An authenticated user with `internal_user` privileges can escalate to `proxy_admin` and achieve remote code execution. The proxy uses one encryption key for two purposes: sealing secrets at rest and minting session tokens. An attacker exploits this by requesting a new API key with a crafted metadata field containing a forged admin credential as the "secret" value. The proxy encrypts and returns this payload. When this value is then presented as a bearer token, the proxy decrypts it, trusts the forged admin identity, and grants full administrative access, including the ability to execute arbitrary commands via the MCP stdio endpoint. Affected versions Versions later than 1.91.0 are exploitable in the default configuration. Versions 1.87.0 through 1.90.x are exploitable only if `EXPERIMENTAL_UI_LOGIN=true` was explicitly set. Mitigation Upgrade to a patched version as soon as possible. If you cannot upgrade immediately, set `EXPERIMENTAL_UI_LOGIN=false`. This…
Recommended action: Upgrade to 1.104.0rc2 (pre-release), 1.103.1, 1.102.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.93.21.94.31.89.71.90.71.96.21.91.51.95.11.92.21.88.6· Vendor fix available
Issue
Impact Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy's request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator's stored key. Any authenticated user could therefore exfiltrate the operator's upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy. Patches Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6. Workarounds Set generalsettings.allowclientsidecredentials to false so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters…
Recommended action: Upgrade to 1.96.2, 1.95.1, 1.94.3 or 6 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A server-side request forgery in LiteLLM Proxy lets an authenticated caller redirect the proxy's outbound request to a host of their choosing by smuggling an apibase inside the userconfig request body, bypassing the existing parameter guard. Details LiteLLM Proxy validates request bodies with isrequestbodysafe, which blocks the apibase and baseurl parameters but does not cover userconfig. The userconfig object is used to build the outbound router for a request, so a caller can place an apibase inside it and reach an arbitrary host. The guard only inspected the two top-level keys, so the same apibase nested inside userconfig was never checked. Exploitation requires a valid virtual key. Impact An authenticated caller can make the proxy issue server-side requests to internal or external hosts of their choosing, reaching endpoints the caller cannot otherwise access. Affected / Patched Affected: <= 1.83.8 Patched: 1.83.9 Remediation Upgrade to 1.83.9 or later (released 2026-04-17).
Recommended action: Upgrade to 1.83.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BerriAI litellm <=1.82.4 is vulnerable to Server-Side Template Injection (SSTI), which allows unauthenticated remote attackers to execute arbitrary OS commands via a crafted dotpromptcontent parameter in the /prompts/test endpoint due to use of an unsandboxed jinja2.Environment.
Recommended action: Upgrade to 1.83.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact LiteLLM's Custom Code Guardrails production create/update paths did not apply the same sandboxing and validation used by the test endpoint. A privileged user with access to create or update guardrails could submit custom Python code that executed in the LiteLLM proxy environment. In deployments without a configured master key, callers could be treated as proxy administrators, making this reachable without intended administrative authorization. This could allow arbitrary code execution in the LiteLLM proxy container and exposure of secrets available to the process. Patches The issue is fixed in 1.82.0-stable. LiteLLM recommend upgrading to 1.82.0-stable or later. Workarounds If upgrading is not immediately possible: 1. Restrict access to POST /guardrails and PUT /guardrails/{guardrailid} to trusted administrators only. 2. Ensure LITELLMMASTERKEY is configured. 3. Avoid enabling Custom Code Guardrails for untrusted users.
Recommended action: Upgrade to 1.82.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 1.84.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact LiteLLM's /health/testconnection endpoint resolved request-supplied environment and OIDC file references in litellmparams. A proxy administrator, or another privileged caller with permission to test model connections, could cause LiteLLM to read files from the local filesystem via an oidc/file/ reference. Because exploitation requires privileged proxy access, this is treated as a defense-in-depth issue rather than a cross-tenant privilege bypass. Patches The issue is fixed in 1.83.10-stable. LiteLLM recommend upgrading to 1.83.10-stable or later. Workarounds Restrict /health/testconnection access to trusted administrators only.
Recommended action: Upgrade to 1.83.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact LiteLLM Skills archive extraction did not sufficiently validate file paths from uploaded skill ZIP archives. An authenticated user with access to LiteLLM LLM API routes, or a key whose allowedroutes includes /v1/skills, anthropicroutes, or llmapiroutes, could upload a crafted skill archive containing path traversal entries. When the skill was processed for execution, those entries could be written outside the intended extraction/staging directory. This could allow arbitrary file write and may lead to code execution depending on deployment configuration and writable paths. Patches The issue is fixed in 1.83.7-stable. LiteLLM recommens upgrading to 1.83.7-stable or later. Workarounds If upgrading is not immediately possible: 1. Block POST /v1/skills at your reverse proxy or API gateway. 2. Restrict Skills API access to trusted users only.
Recommended action: Upgrade to 1.83.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/experimental/mcpserver/auth/userapikeyauthmcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.
Recommended action: Upgrade to 1.84.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes. The auth layer derived the effective route from request.url.path in litellm/proxy/auth/authutils.py::getrequestroute(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched. Most deployments are not affected. The bypass is blocked by any upstream layer that validates or normalizes Host, such as: - a CDN or WAF, such as Cloudflare - a reverse proxy with servername allowlists - a host-based load balancer LiteLLM Cloud customers are not affected. Patches Fixed in 1.84.0. Upgrade to 1.84.0 or later. No configuration change is required. Workarounds If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the Host header before forwarding (a CDN/WAF, a reverse proxy with explicit…
Recommended action: Upgrade to 1.84.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LiteLLM prior to 1.83.10 allows a user to modify their own userrole via the /user/update endpoint. While the endpoint correctly restricts users to updating only their own account, it does not restrict which fields may be changed. A user who can reach this endpoint can set their role to proxyadmin, gaining full administrative access to LiteLLM including all users, teams, keys, models, and prompt history. Users with the orgadmin role have legitimate access to this endpoint and can exploit this vulnerability without chaining any additional flaw.
Recommended action: Upgrade to 1.83.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LiteLLM prior to 1.83.14 allows an authenticated internaluser to create API keys with access to routes that their role does not permit. When generating a key, the allowedroutes field is stored without verifying that the specified routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request, enabling full privilege escalation from internaluser to proxyadmin.
Recommended action: Upgrade to 1.83.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The POST /guardrails/testcustomcode endpoint runs user-supplied Python inside a hand-rolled sandbox. The sandbox can be escaped using bytecode-level techniques, allowing arbitrary code execution in the proxy process — which runs as root in the default Docker image. Reaching the endpoint requires a proxy-admin credential in default configurations. Patches Fixed in 1.83.11. The hand-rolled sandbox has been replaced with RestrictedPython. Upgrade to 1.83.11 or later. Workarounds If upgrading is not immediately possible, block POST /guardrails/testcustomcode at your reverse proxy or API gateway. References - Patched release: v1.83.10-stable
Recommended action: Upgrade to 1.83.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Two endpoints used to preview an MCP server before saving it — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport. When called with a stdio configuration, the endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process. The endpoints were gated only by a valid proxy API key, with no role check. Any authenticated user — including holders of low-privilege internal-user keys — could therefore run arbitrary commands on the host. Patches Fixed in 1.83.7. Both test endpoints now require the PROXYADMIN role, bringing them into line with the save endpoint. Workarounds If upgrading is not immediately possible, developers should block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at their reverse proxy or API gateway.
Recommended action: Upgrade to 1.83.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted Authorization header to any LLM API route (for example POST /chat/completions) and reach this query through the proxy's error-handling path. An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages. Patches Fixed in 1.83.7. The caller-supplied value is now always passed to the database as a separate parameter. Upgrade to 1.83.7 or later. Workarounds If upgrading is not immediately possible, set disableerrorlogs: true under generalsettings. This removes the path through which unauthenticated input reaches the vulnerable query. References - Patched release: v1.83.7-stable Discovery Credit: Tencent YunDing Security Lab
Recommended action: Upgrade to 1.83.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. Proxy deployments running an affected version are in scope. Patches The issue is fixed in 1.83.7-stable. The fix switches the prompt template renderer to a sandboxed environment that blocks the attributes this attack relies on. LiteLLM recommends upgrading to 1.83.7-stable or later. Workarounds If upgrading is not immediately possible: 1. Block POST /prompts/test at your reverse proxy or API gateway. 2. Review and rotate API keys that should not have access to prompt management routes.
Recommended action: Upgrade to 1.83.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Three issues combine into a full authentication bypass chain: 1. Weak hashing: User passwords are stored as unsalted SHA-256 hashes, making them vulnerable to rainbow table attacks and trivially identifying users with identical passwords. 2. Hash exposure: Multiple API endpoints (/user/info, /user/update, /spend/users) return the password hash field in responses to any authenticated user regardless of role. Plaintext passwords could also potentially be exposed in certain scenarios. 4. Pass-the-hash: The /v2/login endpoint accepts the raw SHA-256 hash as a valid password without re-hashing, allowing direct login with a stolen An already authenticated user can retrieve another user's password hash from the API and use it to log in as that user. This enables full privilege escalation in three HTTP requests. Patches Fixed in v1.83.0. Passwords are now hashed with scrypt (random 16-byte salt, n=16384, r=8, p=1). Password hashes are stripped from all API responses. Existing SHA-256…
Recommended action: Upgrade to 1.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When JWT authentication is enabled (enablejwtauth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Patches Fixed in v1.83.0. The cache key now uses the full hash of the JWT token. Workarounds Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.
Recommended action: Upgrade to 1.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The /config/update endpoint does not enforce admin role authorization. A user who is already authenticated into the platform can then use this endpoint to do the following: - Modify proxy configuration and environment variables - Register custom pass-through endpoint handlers pointing to attacker-controlled Python code, achieving remote code execution - Read arbitrary server files by setting UILOGOPATH and fetching via /getimage - Take over other priveleged accounts by overwriting UIUSERNAME and UIPASSWORD environment variables Patches Fixed in v1.83.0. The endpoint now requires proxyadmin role. Workarounds Restrict API key distribution. There is no configuration-level workaround.
Recommended action: Upgrade to 1.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An improper authorization vulnerability exists in the main-latest version of BerriAI/litellm. When a user with the role 'internaluserviewer' logs into the application, they are provided with an overly privileged API key. This key can be used to access all the admin functionality of the application, including endpoints such as '/users/list' and '/users/getusers'. This vulnerability allows for privilege escalation within the application, enabling any account to become a PROXY ADMIN.
Recommended action: Upgrade to 1.61.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In berriai/litellm before version 1.44.12, the litellm/litellmcoreutils/litellmlogging.py file contains a vulnerability where the API key masking code only masks the first 5 characters of the key. This results in the leakage of almost the entire API key in the logs, exposing a significant amount of the secret key. The issue affects version v1.44.9.
Recommended action: Upgrade to 1.44.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Denial of Service (DoS) vulnerability exists in berriai/litellm version v1.44.5. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction, impacting all users of the service.
Recommended action: Upgrade to 1.56.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in BerriAI/litellm, as of commit 26c03c9, allows unauthenticated users to cause a Denial of Service (DoS) by exploiting the use of ast.literaleval to parse user input. This function is not safe and is prone to DoS attacks, which can crash the litellm Python server.
Recommended action: Upgrade to 1.53.1.dev1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.