When LLM Gateways Go Wrong: Findings from LiteLLM

TL;DR;

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, CVE-2026-59823) which have been resolved as of LiteLLM version 1.83.9.

The 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.

Introduction

As 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.

What are LLM Gateways?

LLM 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.

In 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.

LiteLLM

LiteLLM 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.

In 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.

Our review of LiteLLM was conducted against version 1.77.7. The sections below outline the defects we discovered in the LiteLLM gateway.

Access Control Bypass in /config Endpoint

The 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.

The Vulnerability

The 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.

1. Missing Function-Level Authorization

In secure administrative endpoints within LiteLLM (e.g., /invitation/new), the code explicitly verifies that the authenticated user possesses the PROXY_ADMIN role before proceeding.

Secure Example (/invitation/new in litellm/proxy/proxy_server.py):

@router.post(
“/invitation/new”,
tags=[“Invite Links”],
dependencies=[Depends(user_api_key_auth)],
response_model=InvitationModel,
include_in_schema=False,
)
async def new_invitation(
data: InvitationNew, user_api_key_dict: UserAPIKeyAuth = Depends(user_api_key_auth)
):
# …
# Explicit Role Check
if user_api_key_dict.user_role != LitellmUserRoles.PROXY_ADMIN:
raise HTTPException(
status_code=400,
detail={
“error”: “{}, your role={}”.format(
CommonProxyErrors.not_allowed_access.value,
user_api_key_dict.user_role,
)
},
)
# … business logic …

However, 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.

Vulnerable Code (/config/update in litellm/proxy/proxy_server.py):

@router.post(
“/config/update”,
dependencies=[Depends(user_api_key_auth)], # Only generic auth check
include_in_schema=False,
)
async def update_config(config_info: ConfigYAML):
# …
# MISSING: if user_role != PROXY_ADMIN: raise …
# …
# Proceed to update configuration
await proxy_config.save_config(new_config=config)

2. Route Allowlist Bypass via UI Token Classification

The 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.

Step 2.a: UI Login Creates Token with litellm-dashboard Team

When 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:

# litellm/proxy/proxy_server.py (login flows at lines ~7962, ~8066, ~8203)
response = await generate_key_helper_fn(
request_type=”key”,
**{
“user_role”: user_role,
“duration”: “24hr”,
“key_max_budget”: litellm.max_ui_session_budget,
“models”: [],
“aliases”: {},
“config”: {},
“spend”: 0,
“user_id”: user_id,
“team_id”: “litellm-dashboard”, # <– Key assignment
},
)

Step 2.b: Token Classification Based on Team ID

During authorization, common_checks classifies tokens as either “ui” or “api” based solely on the team_id field:

# litellm/proxy/auth/auth_checks.py (lines 224-227)
token_team = getattr(valid_token, “team_id”, None)
token_type: Literal[“ui”, “api”] = (
“ui” if token_team is not None and token_team == “litellm-dashboard” else “api”
)

Step 2.c: UI Tokens Get Permissive Route Check

If the token is classified as “ui”, the authorization logic routes to _is_ui_route() instead of the stricter _is_api_route_allowed():

# litellm/proxy/auth/auth_checks.py (lines 335-356)
def _is_allowed_route(
route: str,
token_type: Literal[“ui”, “api”],
# …
) -> bool:
if token_type == “ui” and _is_ui_route(route=route, user_obj=user_obj):
return True # <– Bypasses stricter API route checks
else:
return _is_api_route_allowed(…)

Step 2.d: Prefix Matching Allows /config/update

The ui_routes list includes /config, likely intended to allow reading configuration:

# litellm/proxy/_types.py (lines 490-510)
ui_routes = [
“/sso”,
“/sso/get/ui_settings”,
“/login”,
“/key/info”,
“/config”, # <– Likely intended for read-only config access
“/spend”,
# …
]

The _is_ui_route function uses startswith matching:

# litellm/proxy/auth/auth_checks.py (lines 247-269)
def _is_ui_route(route: str, …) -> bool:
allowed_routes = LiteLLMRoutes.ui_routes.value
if (
route is not None
and isinstance(route, str)
and any(route.startswith(allowed_route) for allowed_route in allowed_routes)
):
return True # <– /config/update matches startswith(“/config”)

Because /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.).

Impact

This 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:

• Arbitrary File Read
• Administrative Account Takeover
• Remote Code Execution via Pass-Through Endpoints

Each of these exploitation scenarios is detailed in the following sections.

Arbitrary File Read

Impact: Read any file accessible to the LiteLLM process, including configuration files, secrets, and credentials.

The /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.

Source: Environment Variable Injection

When /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:

# litellm/proxy/proxy_server.py (lines 2841-2860)
def _decrypt_and_set_db_env_variables(self, environment_variables: dict) -> dict:
“””
Decrypts a dictionary of environment variables and then sets them in the environment
“””
decrypted_env_vars = {}
for k, v in environment_variables.items():
try:
decrypted_value = decrypt_value_helper(value=v, key=k)
if decrypted_value is not None:
os.environ[k] = decrypted_value # <– Attacker-controlled value set here
decrypted_env_vars[k] = decrypted_value
except Exception as e:
verbose_proxy_logger.error(
“Error setting env variable: %s – %s”, k, str(e)
)
return decrypted_env_vars

Sink: Unvalidated File Path in `/get_image`

The `/get_image` endpoint reads `UI_LOGO_PATH` from the environment and serves the file at that path without any validation:

Proof of Concept

Step 1: Inject `UI_LOGO_PATH ` environment variable

Step 2: Retrieve file contents

GET /get_image HTTP/1.1
Host: localhost:4000

Response:

The server returns the contents of /etc/passwd, demonstrating arbitrary file read capability.

Administrative Account Take Over

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.

The 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.

Vulnerable Authentication Flow

The `/login` endpoint reads credentials directly from environment variables:

# litellm/proxy/proxy_server.py (lines 7882-7896)
form = await request.form()
username = str(form.get(“username”))
password = str(form.get(“password”))
ui_username = os.getenv(“UI_USERNAME”, “admin”) # <– Attacker-controlled
ui_password = os.getenv(“UI_PASSWORD”, None) # <– Attacker-controlled
if ui_password is None:
ui_password = str(master_key) if master_key is not None else None

When credentials match, the user is granted full administrative privileges:

# 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
user_id = litellm_proxy_admin_name

Proof of Concept

Step 1: Inject attacker-controlled credentials

When authenticated via the UI, the user can update the administrator credentials with the following POST request:

Step 2: Log in with the injected credentials

Navigate to the LiteLLM UI login page and authenticate with:

• Username: hacker
• Password: hacker

The 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.

The next screenshot shows the UI of the dashboard, showing we are indeed logged in as the default admin user.

Remote Code Execution via Pass Through Endpoints

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.

LiteLLM 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.

Attack Chain

Step 1: Configuration Update Triggers Endpoint Initialization

When /config/update receives general_settings.pass_through_endpoints, it calls _update_general_settings() which initializes the endpoints:

# litellm/proxy/proxy_server.py (lines 2996-3003)
## PASS-THROUGH ENDPOINTS ##
if “pass_through_endpoints” in _general_settings:
general_settings[“pass_through_endpoints”] = _general_settings[
“pass_through_endpoints”
]
await initialize_pass_through_endpoints(
pass_through_endpoints=general_settings[“pass_through_endpoints”]
)

Step 2: Route Creation Invokes Module Loading

During endpoint initialization, the target is passed to create_pass_through_route(), which attempts to load it as an adapter:

# litellm/proxy/pass_through_endpoints/pass_through_endpoints.py (lines 943-947)
try:
if isinstance(target, CustomLogger):
adapter = target
else:
adapter = get_instance_fn(value=target) # <– Loads remote module

Step 3: Remote Module Download and Execution

When the target starts with `s3://` or `gcs://`, `get_instance_fn()` delegates to `_load_instance_from_remote_storage()`:

# litellm/proxy/types_utils/utils.py (lines 8-14)
def get_instance_fn(value: str, config_file_path: Optional[str] = None) -> Any:
module_name = value
instance_name = None
try:
# Check if value starts with s3:// or gcs://
if value.startswith(“s3://”) or value.startswith(“gcs://”):
return _load_instance_from_remote_storage(value, config_file_path)

This function downloads the Python file and executes it using importlib:

The call to `exec_module()` executes all top-level code in the downloaded Python file, including import-time side effects.

Proof of Concept

Malicious Adapter (hosted at s3://attacker-bucket /adapters/evil_adapter.py):

Step 1: Register the malicious pass-through endpoint

When this request is processed, LiteLLM:

1. Parses the S3 URL to extract bucket (attacker-bucket) and object key (adapters/evil_adapter.py)
2. Downloads the Python file to a temporary location
3. Calls exec_module() which executes the top-level os.makedirs() call
4. The marker directory /tmp/litellm-pwned is created, confirming code execution

The screenshot below from inside of the Docker container running LiteLLM shows that our arbitrary code was executed and our marker directory was created:

While 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.

Server-Side Request Forgery Leading to LLM Provider API key Extraction

Separately 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.

Overview

The /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.

Vulnerable Code Path

When a request contains `user_config`, the routing logic in `route_llm_request.py` creates a new router with the attacker’s configuration:

# litellm/proxy/route_llm_request.py (lines 122-127)
elif “user_config” in data:
router_config = data.pop(“user_config”)
user_router = litellm.Router(**router_config) # <– Attacker-controlled router
ret_val = getattr(user_router, f”{route_type}”)(**data)
user_router.discard()
return ret_val

No 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.

Proof of Concept

Attacker’s Server Setup:

Set 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.

Malicious Request:

When this request is processed:

1. LiteLLM creates a new router using the attacker’s model_list
2. The chat completion request is sent to http://10.10.13.37:9999 instead of the legitimate OpenAI API
3. The attacker’s server receives the full request, including any configured API keys in the proxy’s default headers

Attacker’s Listener:

Below shows the attacker’s listener that receives the original LLM provider API key which the LiteLLM user should not have access to.

Note: 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.

Miscellaneous Vulnerabilities

During our security assessment, we identified several additional vulnerabilities that, while not directly exploitable for full system compromise, represent significant security weaknesses:

Exposure of Password Hashes

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.

The 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.

Insecure Password Hashing

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.

Password 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:

• No Salt: Identical passwords produce identical hashes, enabling rainbow table attacks
• Single Hash Iteration: Fast hash computation makes brute-force attacks practical
• Weak Algorithm: Standard cryptographic hashes are not designed for password storage

These weaknesses significantly reduce the effort required for an attacker to crack exposed password hashes.

Assigned CVEs

The vulnerabilities documented in this post were disclosed to the LiteLLM maintainers through a coordinated disclosure process.

• CVE-2026-35029: Missing Authorization in /config/update endpoint
• CVE-2026-59823: Server-Side Request Forgery via user_config parameter
• GHSA-69×8-hrgq-fjj8: [duplicate] Exposure of password key material
• GHSA-69×8-hrgq-fjj8: [duplicate] Insecure password storage without salting

Conclusions

This 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.

LiteLLM 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.

The 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.