LiteLLM Vulnerabilities Exposed Configuration, Credentials and Runtime Code

A configuration endpoint in LiteLLM turned a missing permission check into several paths to control of the gateway. Researchers testing version 1.77.7 found that an authenticated user with limited access could change runtime settings, read files available to the service, replace administrator login credentials and trigger Python code hosted in cloud storage. A separate issue let users redirect model requests to servers they controlled, potentially exposing provider credentials.

The findings concern LiteLLM’s gateway, which sits between applications and model providers and can hold the credentials and routing rules used to reach them. The project has addressed the reported vulnerabilities in version 1.83.9. For teams operating the gateway, the practical question is whether their deployed version contains the fixes and whether access to the service is limited to trusted users.

Why the gateway’s position matters

LLM gateways give applications a shared route to one or more model providers. They can centralize credential handling, model selection, rate limits, request logging and usage tracking. Features such as provider fallback and load balancing can make that shared layer useful across many services, but they also concentrate sensitive configuration and access to provider accounts.

LiteLLM offers both an SDK and a gateway. The assessment focused on the gateway, commonly run as a standalone service in an application stack. A weakness there can affect more than one model integration: it may expose the credentials and settings used across the service’s provider connections.

Researchers examined LiteLLM version 1.77.7. Their findings included a missing authorization check in POST /config/update, a server-side request forgery (SSRF) path through the “Clientside LLM Credentials” feature, and issues involving password hashes. The central flaw was in the configuration endpoint, where weak route checks and the absence of a function-level role check combined to expose powerful changes to low-privilege users.

How a UI session reached an administrative endpoint

/config/update is intended to change live gateway configuration, including environment variables, model lists and general settings. LiteLLM’s other administrative routes provide a useful point of comparison: the invitation endpoint, for example, checks that the caller has the PROXY_ADMIN role before continuing. The configuration update function relied on generic authentication, but did not make an equivalent role check before saving changes.

That omission alone would be serious, but the authorization flow also treated some browser sessions differently from ordinary API keys. When a user signs in through the UI, LiteLLM creates a temporary key associated with the litellm-dashboard team. Later checks classify a key as a UI token based on that team ID.

UI tokens then pass through a UI-specific route check. The allowed route list includes /config, apparently to support configuration access, and the check uses prefix matching. As a result, /config/update also matches the allowed prefix. The request can therefore pass the route check even when the user’s role would not allow the same operation through the stricter API route rules.

The result is an authorization gap across two layers: route matching admits the request, and the endpoint does not verify that the authenticated caller is an administrator. Researchers say any authenticated user with a valid UI session, including one with the baseline Internal User role, could use the endpoint to alter runtime configuration.

Configuration changes exposed local files and admin access

One configuration field, environment_variables, made the endpoint’s reach much wider. LiteLLM stores submitted values, decrypts them and places them in the service process’s environment. Since callers could control those values through the exposed endpoint, they could change settings that other parts of the gateway trusted.

The researchers used UI_LOGO_PATH to demonstrate file access. The /get_image route reads that environment variable and returns the file at the specified path. The route did not validate that the path referred to an image or was confined to a designated directory. By setting the variable to a local file path and then requesting the image route, the researchers retrieved the file contents. Their demonstration used /etc/passwd.

This matters because the LiteLLM process may be able to read configuration files, secrets and other credentials stored on the same system. The flaw did not require a separate file-reading feature: it connected user-controlled configuration to a route that served a local file.

The same environment variable mechanism could change the UI’s login credentials. The login flow reads UI_USERNAME and UI_PASSWORD from the process environment. When submitted credentials match, the flow assigns the user the Proxy Admin role. Researchers showed that a low-privilege user could set both values and then sign in as the built-in administrator.

Those paths show why a configuration update can carry consequences beyond changing model settings. The same entry point could expose local files or hand an attacker administrator access, with the latter bringing control over the gateway and access to credentials it holds.

Remote code execution through pass-through adapters

The configuration flaw also reached LiteLLM’s pass-through endpoints. These let the gateway forward requests to external services and load custom adapter modules. In the affected flow, a caller could add a pass-through endpoint whose target pointed to a Python module in S3 or Google Cloud Storage.

When LiteLLM processes a configuration update containing pass-through endpoints, it initializes them. Endpoint setup passes the target to a module-loading function. For S3 and GCS targets, that function downloads a Python file and loads it with Python’s import machinery. Loading the module executes its top-level code, including any side effects that run when the file is imported.

The researchers’ proof of concept used a small adapter that created a marker directory when loaded. Registering the endpoint caused LiteLLM to download and execute the module; the resulting directory inside the running container confirmed that the code had run.

The demonstrated action was benign, but the execution context was the LiteLLM process. A more harmful module could run commands or access data available to that process. That turns the gateway into a potential foothold on the system and network where it runs. The researchers describe the possible impact as remote code execution, with access to LiteLLM data and the surrounding deployment environment.

The chain depended on a user being able to update configuration and on the gateway accepting a remote module target. Restricting who can change live settings is therefore central to breaking this path. Teams should also scrutinize any feature that downloads and executes adapters: the source, integrity and permissions of those modules affect the risk even when the route is used as designed.

A separate request path could expose provider keys

The SSRF finding followed a different route and did not depend on the configuration endpoint’s missing role check. LiteLLM’s “Clientside LLM Credentials” feature accepts a user_config parameter on chat completions and other model routes. When that parameter is present, the request-handling code builds a new router from the supplied settings.

Researchers found that the configuration could include a model list with a caller-chosen api_base. LiteLLM then sent the request to that destination instead of the expected model provider. Their demonstration directed a request to a server they controlled and captured the incoming call, including an API key supplied in the gateway’s default headers.

The feature has a setting, configurable_clientside_auth_params, that limits direct api_base and api_key values in request bodies. But the researchers found that user_config takes a separate code path, bypassing those restrictions. The key issue is that user-supplied router configuration was not validated before LiteLLM used it to route the request.

Redirecting model traffic to a caller-controlled destination can expose secrets attached by the gateway. It can also be used to probe destinations reachable from the gateway’s network. In this case, the risk comes from the server making a request based on user-controlled routing settings, rather than from a user directly receiving a provider credential through a normal response.

Password handling added to the findings

The assessment also identified exposure of password hashes through API routes. Authenticated users could retrieve hashes associated with other accounts, even though the information was intended to be limited to administrators. The earlier UI-token authorization issue could give a low-privilege user access to this data.

Exposed hashes give an attacker material for offline guessing, where attempts can be made without repeatedly contacting the service. The researchers also reported that LiteLLM generated password hashes with a single pass of a standard hash function and no salt. That design makes identical passwords produce identical hashes and makes each guess relatively cheap to calculate. Password-specific algorithms such as bcrypt, scrypt and Argon2 are designed to make large-scale guessing more costly.

LiteLLM acknowledged these password findings when they were reported. The researchers said both appeared to be duplicates tracked under GHSA-69x8-hrgq-fjj8. They also listed that advisory against both password-hash exposure and insecure password storage, so the report does not present them as distinct advisory records.

What operators should take from the disclosure

The reported vulnerabilities were disclosed to LiteLLM maintainers, and the article says the issues were resolved as of version 1.83.9. The assessment itself covered version 1.77.7. The first operational step for teams is to check which version they run and move to a release containing the fixes. Deployments should also review who can reach the gateway and which users can establish UI sessions.

For engineering teams, the findings point to a few specific control boundaries. Administrative operations need explicit permission checks at the endpoint, even when a shared authentication layer also filters routes. Route allowlists should match complete paths or use carefully defined boundaries; prefix checks can unintentionally admit write operations alongside read routes. User-controlled configuration should be validated before it can change process environment, file paths or request destinations.

Dynamic module loading calls for its own controls. A gateway that downloads Python code and imports it is granting that code the permissions of the gateway process. Teams using pass-through adapters should understand where those files come from and what the service account can access. Likewise, routing features that accept per-request configuration need clear limits on destinations and on which credentials can accompany forwarded requests.

The broader lesson is practical rather than novel: a gateway’s abstraction layer does not make its underlying security boundaries less important. LiteLLM’s configuration endpoint joined authorization, environment settings, file serving and module loading in a way that let one permission gap reach several sensitive capabilities. The separate SSRF path shows that model routing deserves the same scrutiny as administrative controls. Version status, endpoint permissions and user-controlled destinations are the details operators should verify first.

The findings were assigned CVE-2026-35029 for missing authorization in /config/update and CVE-2026-59823 for SSRF through user_config. The password-related findings were associated with GHSA-69x8-hrgq-fjj8 as duplicate reports.