# Migrating off a self-hosted LiteLLM proxy: the 2026 advisories and a config map

> Markdown mirror of https://router.one/litellm-migration for AI assistants and crawlers. Router One is a unified, OpenAI-compatible LLM API gateway.
> Last updated: 2026-10-28

LiteLLM has published several security advisories for the litellm package and its proxy in 2026, including a Critical one on October 27. If you run the proxy yourself, the first job is to check your version against them and patch. If you would rather not run and patch a proxy at all, this page maps a LiteLLM setup onto Router One, a unified LLM API gateway with one OpenAI-compatible endpoint for 30+ models: where each config.yaml setting goes, what changes in your client code, and how to check the move before you shut the proxy down. The advisory facts below are summarized from the published advisories; read each one in full before acting.

## Which LiteLLM security advisories were published in 2026?

As of 2026-10-28, LiteLLM's own advisories page rates five of its 2026 advisories for the litellm pip package Critical. The table lists those five plus the PyPI malware advisory from the GitHub Advisory Database, newest first, with the fixed releases each advisory names. The ratings are LiteLLM's: the GitHub Advisory Database rates some advisories differently (GHSA-7hp6-4w63-5g45 as High, for example). The BerriAI/litellm advisories page lists further advisories rated High, Moderate and Low, so check the full list for your version, not only this table.

| Advisory | Published | What the advisory says | Fixed in |
| --- | --- | --- | --- |
| GHSA-w4c7-34wj-hqm8 | 2026-10-27 | An unauthenticated request to an LLM route on a proxy running with an Enterprise license could make the proxy read a local file and send it to an attacker-chosen URL, exposing LITELLM_MASTER_KEY and provider keys. Open-source deployments without a license are not affected. | 1.103.10, 1.104.8, 1.105.6, 1.106.5 |
| GHSA-7hp6-4w63-5g45 | 2026-09-30 | A user with internal_user privileges can escalate to proxy_admin and run commands on the host. Exploitable in the default configuration from 1.91.0; 1.87.0 to 1.90.x only with EXPERIMENTAL_UI_LOGIN=true. | 1.100.4, 1.101.3, 1.102.2, 1.103.1, 1.104.0rc2 |
| GHSA-4xpc-pv4p-pm3w | 2026-05-28 | A Host-header parsing flaw could, under specific conditions, allow unauthenticated access to protected management routes. An upstream layer that validates or normalizes Host blocks it. | 1.84.0 |
| GHSA-r75f-5x8p-qvmc | 2026-04-20 | SQL injection in the proxy's API key check: an unauthenticated request with a crafted Authorization header to any LLM API route could read data from the proxy's database and may be able to modify it. Until you upgrade, the advisory's workaround is disable_error_logs: true under general_settings. | 1.83.7 |
| GHSA-jjhc-v7c2-5hh6 | 2026-04-03 | With JWT authentication enabled (enable_jwt_auth: true, off by default), the OIDC userinfo cache keyed tokens on their first 20 characters, so an unauthenticated attacker could craft a token that inherits a legitimate user's cached identity and permissions. Deployments without JWT/OIDC authentication are not affected. | 1.83.0 |
| GHSA-5mg7-485q-xm76 (PYSEC-2026-2) | 2026-03-25 | PyPI releases 1.82.7 and 1.82.8 contained credential-harvesting malware. Per LiteLLM's security update, the official proxy Docker image was not affected. | No patched version listed; LiteLLM names 1.82.6 or earlier, or 1.83.0 |

## Where to read each advisory

- GHSA-w4c7-34wj-hqm8: https://github.com/BerriAI/litellm/security/advisories/GHSA-w4c7-34wj-hqm8
- GHSA-7hp6-4w63-5g45: https://github.com/BerriAI/litellm/security/advisories/GHSA-7hp6-4w63-5g45
- GHSA-4xpc-pv4p-pm3w: https://github.com/BerriAI/litellm/security/advisories/GHSA-4xpc-pv4p-pm3w
- GHSA-r75f-5x8p-qvmc: https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
- GHSA-jjhc-v7c2-5hh6: https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6
- GHSA-5mg7-485q-xm76: https://github.com/advisories/GHSA-5mg7-485q-xm76
- LiteLLM's March 2026 security update: https://docs.litellm.ai/blog/security-update-march-2026
- All LiteLLM advisories: https://github.com/BerriAI/litellm/security/advisories

## What to do first if the proxy is still running

Moving traffic elsewhere does not patch a proxy that is still up, so start with the steps the advisories themselves give:

- Check the installed litellm version on every proxy host, CI runner and container image against the affected ranges, and upgrade to a fixed release.
- If 1.82.7 or 1.82.8 was ever installed or run, the advisory says to assume every credential available to that environment may have been exposed and to rotate it. LiteLLM's update also says to search site-packages for litellm_init.pth.
- For GHSA-w4c7-34wj-hqm8, the advisory's interim mitigations are to block request bodies carrying the listed callback keys at the edge and to restrict the proxy's outbound traffic to your configured model endpoints.
- For GHSA-7hp6-4w63-5g45, the advisory's interim mitigation is EXPERIMENTAL_UI_LOGIN=false, which also breaks CLI SSO and Claude Code gateway login.
- The advisories also recommend keeping the proxy off the public internet where possible.

## Where each LiteLLM setting goes on Router One

A LiteLLM proxy keeps model aliases, provider keys, retries and budgets in config.yaml and its database. On Router One most of that becomes the request itself plus settings on your API key:

| LiteLLM proxy | Router One |
| --- | --- |
| Client base URL http://0.0.0.0:4000 (the proxy) | https://api.router.one/v1 (OpenAI-compatible) |
| general_settings.master_key or a virtual key | A Router One API key, one per app or environment |
| model_list → model_name (your alias) | The exact catalog ID in the model field, such as openai/gpt-5.6-sol or anthropic/claude-sonnet-5.5 |
| litellm_params.api_key per provider (os.environ/...) | Not needed: one Router One key reaches every catalog model |
| num_retries across deployments of one model | Built in: an exact model ID can retry another healthy route serving that same model |
| fallbacks to a different model | Kept in your code (catch the error, resend with the other ID), or send model="auto" to let the server choose |
| Virtual key max_budget | Per-key maxSpend cap on wallet charges, plus expiry; rateLimit and tokenLimitTpm run at platform defaults and can be raised on request |
| success_callback (Langfuse and similar) | Dashboard → Logs: model, tokens, cost, latency and status for every request |
| Claude Code pointed at the proxy | ANTHROPIC_BASE_URL=https://api.router.one with ANTHROPIC_AUTH_TOKEN set to the Router One key |

## Step 1: read your current config.yaml

List every model_name your clients send and the litellm_params.model behind it. That list becomes your alias-to-catalog-ID map. litellm_params.model takes each vendor's own ID, which is not always the catalog ID: Anthropic's claude-sonnet-5-5 in the config below is anthropic/claude-sonnet-5.5 in the Router One catalog. A typical proxy config:

`config.yaml`

```yaml
model_list:
  - model_name: gpt-main
    litellm_params:
      model: openai/gpt-5.6-sol
      api_key: os.environ/GPT_PROVIDER_KEY
  - model_name: claude-main
    litellm_params:
      model: anthropic/claude-sonnet-5-5
      api_key: os.environ/CLAUDE_PROVIDER_KEY
litellm_settings:
  num_retries: 2
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
```

## Step 2: find the catalog ID for each alias

Router One has no alias table, so each model_name maps to a catalog ID that your client sends directly. Copy IDs exactly from /models or from GET /v1/models. Most IDs carry a vendor prefix (openai/, anthropic/, google/), some have none (deepseek-v4.1-flash). The gateway accepts most official bare names as aliases but not all of them, and an unknown name returns 404, so use the full ID.

`terminal`

```bash
curl https://api.router.one/v1/models \
  -H "Authorization: Bearer $ROUTER_ONE_API_KEY"
```

## Step 3: change the base URL, key and model in the client

Clients that called the proxy through the OpenAI SDK keep the same code; only the base URL, the key and the model value change:

`app.py`

```python
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.router.one/v1",  # was http://0.0.0.0:4000
    api_key=os.environ["ROUTER_ONE_API_KEY"],  # was the LiteLLM key
)

resp = client.chat.completions.create(
    model="openai/gpt-5.6-sol",  # was the alias "gpt-main"
    messages=[{"role": "user", "content": "Reply with OK"}],
)
print(resp.choices[0].message.content)
```

## If you keep the litellm Python package as a client

Some apps call litellm.completion() in-process rather than a proxy. That works against Router One too: set api_base to the /v1 base URL and the model to openai/ plus the catalog ID. LiteLLM splits the string at the first slash only, so openai/openai/gpt-5.6-sol sends openai/gpt-5.6-sol and openai/anthropic/claude-sonnet-5.5 sends anthropic/claude-sonnet-5.5. The advisories are filed against this package: most concern the proxy server, while the malware advisory covers any install of 1.82.7 or 1.82.8, so pin a release outside the affected ranges.

## Step 4: check Logs, then retire the proxy

Send one request per migrated model and find each one in Dashboard → Logs with its model ID, tokens, cost and status. Once all traffic shows up there, stop the proxy and revoke the provider keys it held, so no copy of them is left on a host you no longer patch.

## FAQ

### Do I have to migrate because of these advisories?

No. Each advisory names fixed releases, and upgrading is the remedy it gives. Migration is an option when you would rather not run, patch and monitor a proxy yourself.

### Is the open-source LiteLLM proxy affected by GHSA-w4c7-34wj-hqm8?

Per the advisory, no: deployments without an Enterprise license are not affected, because the code path only loads with an active license. The other advisories in the table apply to the litellm package regardless of license, within their affected ranges.

### What code changes does the move need?

Three values: the base URL (https://api.router.one/v1), the API key, and the model field, which takes a catalog ID instead of your LiteLLM alias. Request and response shapes stay OpenAI Chat Completions.

### Will Router One switch to another model when one fails?

Not for an exact model ID: retries keep that same model and try another healthy route serving it. Only an explicit model="auto" lets the server choose from candidates that may span models. Cross-model fallbacks from your LiteLLM config move into your own code.

### How do I replace LiteLLM virtual-key budgets?

Create one Router One key per app, team or environment and give each its own maxSpend cap and expiry. A key's spend cap (maxSpend) limits what that key can charge to your wallet: once its cumulative wallet charges reach the cap, its wallet-billed requests return HTTP 402. Requests covered by your plan's quota draw from the account's shared plan quota and do not count toward any key's cap. Unlike a LiteLLM budget_duration, the cap does not reset on a schedule.

### How many models can I call after the move?

30+ models through the same endpoint and key. The live list is at /models and GET /v1/models.

## See also

- LiteLLM alternative: https://router.one/litellm-alternative
- Automatic fallback: https://router.one/llm-fallback
- LLM cost tracking: https://router.one/llm-cost-tracking
- OpenAI-compatible API: https://router.one/openai-compatible-api
- Canonical page: https://router.one/litellm-migration
- Models and per-model token rates: https://router.one/models (markdown: https://router.one/models.md)
- Pricing: https://router.one/pricing
- API docs (markdown): https://router.one/docs.md
- Company facts: https://router.one/facts/company.md