> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# LiteLLM has SQL Injection in Proxy API key verification
- URL: https://f4n6.co.uk/security-feed/litellm-has-sql-injection-in-proxy-api-key-verification/
- Published: 2026-10-05T20:41:26.000Z
- Updated: 2026-10-05T20:41:26.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

LiteLLM's proxy contains a SQL injection in the API key verification path, tracked as CVE-2026-42208\. An unauthenticated attacker sends a crafted `Authorization` header to any LLM API route, for example `POST /chat/completions`, and reaches the vulnerable query through the proxy's error-handling path. The flaw allows reads from the proxy database and possibly writes, exposing the proxy and the upstream provider credentials it stores. CISA added CVE-2026-42208 to the Known Exploited Vulnerabilities catalog with a remediation due date of 2026-05-11, so exploitation is confirmed in the wild rather than theoretical. Any EMEA financial services firm running a LiteLLM proxy below 1.83.7 should treat this as an active exposure: the proxy is internet-facing by design, the attack needs no credentials, and the database it sits on holds the API keys for every model provider the firm has wired into it.

## 2\. Regulatory framing

| Article                                                                         | Trigger (the fact in this item)                                                                                                                                                                  | Practical impact                                                                                                                                                                            |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 19: reporting of major ICT-related incidents to competent authorities | CVE-2026-42208 is listed in CISA KEV with a 2026-05-11 due date, so exploitation is confirmed rather than suspected, and a compromised LiteLLM proxy exposes the provider credentials it manages | If a firm finds the vulnerable query was reached, the incident classification under Art. 18 must be run and a major incident reported to the competent authority on the Art. 19 timeline    |
| DORA Art. 28: ICT third-party risk — general principles                         | LiteLLM is a third-party component sitting in the request path to every configured LLM provider, and the flaw leaks the credentials for those providers                                          | The provider-credential exposure is a third-party risk event: the firm must assess which upstream providers are reachable with the leaked keys and whether contractual notification applies |
| NIS2 Art. 21(2)(d): supply chain security measures                              | The vulnerable component is an open-source proxy the firm deploys and patches itself, not a managed service                                                                                      | Firms in NIS2 scope must show they track and remediate vulnerabilities in components they integrate, which puts the 1.83.7 upgrade and the version inventory in scope                       |

## 3\. Technical analysis & attack chain

The vulnerability is a SQL injection in the database query LiteLLM's proxy runs during API key verification. The caller-supplied key value was concatenated into the query text instead of being passed as a bound parameter. The advisory credits Tencent YunDing Security Lab with discovery.

Confirmed attack chain:

1. The attacker sends a request to any LLM API route on the proxy, for example `POST /chat/completions`, with a crafted `Authorization` header. No authentication is required.
2. The proxy's error-handling path routes the unauthenticated input into the API key verification query.
3. Because the key value is interpolated into the query text, the attacker's input is interpreted as SQL.
4. The attacker reads data from the proxy's database. The advisory states the attacker may also be able to modify it.
5. The result is unauthorised access to the proxy and to the credentials it manages, which are the upstream provider API keys the proxy holds.

The mechanism matters for defenders because of where the query sits. API key verification runs before any route-level authorisation, so the injection is reachable on every LLM API route the proxy exposes, not just an administrative endpoint. The error-handling path is the delivery route, which means the attacker does not need a valid key to trigger the query; a malformed or crafted header is enough.

The fix in 1.83.7 passes the caller-supplied value to the database as a separate parameter, which removes the injection regardless of header content. The vendor workaround, setting `disable_error_logs: true` under `general_settings`, removes the path by which unauthenticated input reaches the vulnerable query. The workaround is a mitigation, not a fix: it closes the error-handling route but leaves the underlying query construction unchanged, so it should be treated as a stopgap until 1.83.7 is deployed.

Two related LiteLLM issues appear in the source material and are worth separating from this one. GHSA-3cv6-jpf6-8222 describes an authenticated SSRF and provider-credential exfiltration through unvalidated request-body routing parameters, fixed across 1.88.6 through 1.96.2\. GHSA-hx8v-g79f-8w5f describes an authenticated SSRF via an `api_base` smuggled inside the `user_config` request parameter, bypassing the `is_request_body_safe` guard, affecting versions up to and including 1.83.8 and fixed in 1.83.9\. Both require a valid virtual key, unlike CVE-2026-42208\. A firm that upgrades only to 1.83.7 to close the SQL injection remains exposed to the `user_config` SSRF until 1.83.9, and to the broader credential-exfiltration issue until 1.88.6 or later.

A German BSI advisory (WID-SEC-2026-1288) covers multiple LiteLLM vulnerabilities and rates the product critical, describing both SQL injection and remote code execution with the privileges of the service. The BSI entry is a summary and does not name which CVE carries the code-execution claim, so that claim is not attributed to CVE-2026-42208 here.

Confidence caveats. The SQL injection detail, the affected and fixed versions, and the workaround come from the GitHub advisory for GHSA-r75f-5x8p-qvmc, which is the vendor's own disclosure and is corroborated by the CISA KEV entry for CVE-2026-42208\. The claim that an attacker may be able to modify database contents is stated in the advisory as a possibility ("may be able to"), not as a demonstrated capability, and should be read that way. No public exploit code, no attacker infrastructure, and no in-the-wild campaign detail beyond the KEV listing are present in the source material. The KEV entry records known ransomware campaign use as unknown, so there is no basis to link this to ransomware activity.

## 4\. Mitigation & containment

P1, within 24 hours:

- Inventory every LiteLLM proxy deployment and record its version. Any instance below 1.83.7 is exposed to CVE-2026-42208 and should be treated as compromised until logs say otherwise.
- Upgrade to 1.83.7 or later. The patched release is `v1.83.7-stable` at https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable. Where the deployment pipeline pins versions, update the pin.
- If the upgrade cannot be completed inside 24 hours, set `disable_error_logs: true` under `general_settings` in the proxy configuration and restart the proxy. This closes the error-handling route into the vulnerable query. Record the instance as still vulnerable and schedule the upgrade.
- Rotate every upstream provider API key and every virtual key the proxy holds, on the assumption that a reachable injection may already have been used. Rotation is the only way to invalidate credentials an attacker may have read.
- Review proxy access logs for requests to LLM API routes with malformed or unusual `Authorization` headers, and for any request that returned a database error. The error-handling path is the delivery route, so database errors on key verification are the signal to look for.

P2, within 72 hours:

- Upgrade to 1.83.9 or later rather than stopping at 1.83.7\. Version 1.83.7 closes the SQL injection but leaves the `user_config` SSRF (GHSA-hx8v-g79f-8w5f) open, which affects versions up to and including 1.83.8.
- Set `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters.
- Block the affected routing and credential parameters at the reverse proxy or API gateway in front of LiteLLM: `api_base`, `base_url`, `model_list`, `fallbacks`, and provider credential fields.
- Restrict proxy keys to trusted callers. The SSRF issues require a valid virtual key, so key scope limits their reach even before the version upgrade lands.

P3, within 7 days:

- Upgrade to 1.88.6 or later to close the authenticated SSRF and provider-credential exfiltration described in GHSA-3cv6-jpf6-8222, which is fixed across 1.88.6, 1.89.7, 1.90.7, 1.91.5, 1.92.2, 1.93.2, 1.94.3, 1.95.1, and 1.96.2.
- Confirm the proxy database is not reachable from the internet and that its credentials are scoped to the proxy only.
- Add LiteLLM version tracking to the component inventory so future advisories can be matched against deployed versions without a manual sweep.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The sources describe the vulnerable code path and the affected versions but publish no hashes, domains, IP addresses, or file artefacts.

Behavioural indicators:

| behaviour                                                                                                           | where to observe                                     | confidence                                                             |
| ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------- |
| Requests to LLM API routes (for example POST /chat/completions) carrying malformed or crafted Authorization headers | LiteLLM proxy access logs                            | Medium, derived from the advisory's description of the attack path     |
| Database errors raised during API key verification                                                                  | LiteLLM proxy error logs and database logs           | Medium, the error-handling path is the stated delivery route           |
| Outbound requests from the proxy to hosts not in the configured provider list                                       | Egress logs and network flow data for the proxy host | Medium, relevant to the related SSRF issues rather than CVE-2026-42208 |

## 6\. Detection

The sources give no file artefacts, command lines, or hard-coded values from the vulnerability itself, so a YARA rule would have nothing genuine to match on. Detection here is log-based.

```yaml
title: LiteLLM Proxy API Key Verification Database Error
id: 8f2c1a44-7b6e-4d21-9c3a-5e0d1b7a9f10
status: experimental
description: Detects database errors raised during LiteLLM proxy API key verification, the error-handling path through which unauthenticated input reaches the CVE-2026-42208 SQL injection.
author: Adverse Trace
date: 2026-10-05
references:

  - https://github.com/advisories/GHSA-r75f-5x8p-qvmc
logsource:
  product: litellm
  service: proxy
detection:
  keywords:

    - 'litellm.proxy'
    - 'API key'
  error_terms:

    - 'sqlalchemy.exc'
    - 'OperationalError'
    - 'ProgrammingError'
    - 'syntax error'
  condition: keywords and error_terms
falsepositives:

  - Legitimate database outages or schema migrations producing the same exception classes
level: medium

```

```yaml
title: LiteLLM Proxy Request With Suspicious Authorization Header
id: 3d9b6e02-1c47-4a88-b5f2-6a7c0e9d2b31
status: experimental
description: Detects requests to LiteLLM LLM API routes whose Authorization header contains SQL metacharacters, consistent with attempts to reach the CVE-2026-42208 injection through the proxy error-handling path.
author: Adverse Trace
date: 2026-10-05
references:

  - https://github.com/advisories/GHSA-r75f-5x8p-qvmc
logsource:
  category: webserver
detection:
  selection_route:
    cs-uri-stem|endswith:

      - '/chat/completions'
      - '/completions'
      - '/embeddings'
  selection_header:
    cs-authorization|contains:

      - "'"
      - '--'
      - '/*'
      - 'UNION'
      - 'SELECT'
  condition: selection_route and selection_header
falsepositives:

  - Malformed client integrations sending non-key values in the Authorization header
level: medium

```

Both rules are behavioural and will need tuning against the firm's own proxy traffic before they are promoted out of experimental. The header rule in particular will fire on any client that puts a non-key string in `Authorization`.

## 7\. Sources

- GitHub Security Advisories, "LiteLLM has SQL Injection in Proxy API key verification" (GHSA-r75f-5x8p-qvmc), https://github.com/advisories/GHSA-r75f-5x8p-qvmc, published 2026-04-24
- CISA Known Exploited Vulnerabilities, CVE-2026-42208, BerriAI LiteLLM SQL Injection Vulnerability, https://nvd.nist.gov/vuln/detail/CVE-2026-42208, remediation due date 2026-05-11
- GitHub Security Advisories, "LiteLLM: Authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters" (GHSA-3cv6-jpf6-8222), https://github.com/advisories/GHSA-3cv6-jpf6-8222
- GitHub Security Advisories, "LiteLLM Proxy has server-side request forgery via the `user_config` request parameter" (GHSA-hx8v-g79f-8w5f), https://github.com/advisories/GHSA-hx8v-g79f-8w5f
- GitHub Security Advisories, "LiteLLM: MCP Proxy Has Improper Authentication" (GHSA-4jcj-7x88-m979), https://github.com/advisories/GHSA-4jcj-7x88-m979
- BSI Germany, "\[UPDATE\] \[kritisch\] LiteLLM: Mehrere Schwachstellen" (WID-SEC-2026-1288), https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-1288
- BerriAI, LiteLLM release v1.83.7-stable, https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable

## 8\. Adverse Trace position

CVE-2026-42208 is a confirmed-exploited, unauthenticated SQL injection in a component that sits in front of every LLM provider a firm has configured, and the CISA KEV listing with a 2026-05-11 due date removes any argument for treating it as a theoretical finding. The exposure is not the proxy itself but the credential store behind it: a successful read hands the attacker the upstream provider keys, which are usable outside the firm's perimeter and are not covered by the proxy's own controls. We assess the practical risk to EMEA financial services clients as high where a LiteLLM proxy is internet-facing and below 1.83.7, and lower where the proxy is internal-only and key rotation has already been performed. We will track the KEV remediation deadline against client inventories, and we will re-issue this advisory if a public exploit or campaign infrastructure tied to CVE-2026-42208 appears. Clients running LiteLLM should confirm their deployed version to us this week so we can tell them whether the 1.83.7 upgrade is sufficient or whether the 1.88.6 floor applies to their configuration.

---

[Read the original source →](https://github.com/advisories/GHSA-r75f-5x8p-qvmc?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*