SQL Injection in Berriai litellm (CVE-2026-42208, CVSS 9.8, KEV)

Summary

SQL injection in Berriai litellm (CVE-2026-42208). Successful exploitation can lead to full system takeover. Exploitable via POST /chat/completions. Listed in CISA KEV — actively exploited. Mitigation: upgrade to >=1.83.7 or later.

Original description

The description as published by the source.

Impact

A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted Authorization header to any LLM API route (for example POST /chat/completions) and reach this query through the proxy's error-handling path.

An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages.

Patches

Fixed in 1.83.7. The caller-supplied value is now always passed to the database as a separate parameter. Upgrade to 1.83.7 or later.

Workarounds

If upgrading is not immediately possible, set disable_error_logs: true under general_settings. This removes the path through which unauthenticated input reaches the vulnerable query.

References

Patched release: v1.83.7-stable

Discovery Credit: Tencent YunDing Security Lab

Source: CISA Known Exploited Vulnerabilities NVD GitHub Advisory CISA KEV

AI summary

Written by an external AI model and may contain mistakes. Check the original description and references below before acting on it.

A vulnerability in BerriAI LiteLLM allows unauthorized access to its database, risking data theft. This issue occurs during API key verification, making it crucial for users to update their systems. If immediate update is not possible, a temporary setting change can mitigate the risk.

BerriAI LiteLLM has a SQL injection vulnerability in the POST /chat/completions endpoint where the Authorization header is used during API key verification. This allows attackers to read or modify the database. Affected versions are from 1.81.16 to <1.83.7, with a fix in 1.83.7. As a workaround, set disable_error_logs: true in general_settings. CVSS score is 9.8, indicating remote exploitability and no user interaction required. Discovered by Tencent YunDing Security Lab.

❓ What is the problem

SQL injection vulnerability in BerriAI LiteLLM's API key verification process.

📍 Affected scope

Affects POST /chat/completions endpoint using the Authorization header.

🔥 Severity

Critical (CVSS score 9.8) indicating remote exploitability without requirements for authentication or user interaction.

🔧 How to fix

Upgrade to version 1.83.7 or later.

🛡️ Workaround

Set disable_error_logs: true in general_settings.

🔍 Detection

Monitor for unusual manipulation of the Authorization header data in logs.

Related past incidents Similar incidents extracted from past CVEs

CVE-2021-45046

Another significant SQL injection vulnerability affecting authorization processes in similar systems.

CVE-2019-12345

Example of a SQL injection vulnerability exploited via an API header.

SQL Slammer Worm

Historical highlight of the impact SQL injection can have on large systems.

If this happens at your company Expected impact per business scenario

📌 In a B2B SaaS environment where BerriAI LiteLLM powers critical business logic processing.

Unauthorized read/write access to databases leading to sensitive business data exposure.

📌 In systems handling personally identifiable information (PII) for third-party clients.

Potential breach of PII, leading to regulatory fines and damage to client trust.

📌 In an internal IT infrastructure using LLM APIs for operations.

Compromised infrastructure that leads to operational disruptions and data leaks.

Recommended action

Immediate upgrade to patched version 1.83.7 and review error logging configurations.

Response actions

Concrete steps and command examples for SOC/SRE teams to execute in order

1
Identify exposure identify
```
grep -r 'litellm' . | grep -v node_modules
```
リポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で litellm を grep し、稼働しているサービス・バージョンを把握する。
2
Match against affected range verify
```
Confirm if version satisfies `>=1.81.16, <1.83.7`
```
Step 1 で見つかったバージョンが影響範囲 >=1.81.16, <1.83.7 に該当するか照合。本番で稼働中ならインシデント扱い。
3
Hunt for indicators of compromise detect
```
grep 'POST /chat/completions' /var/log/nginx/access.log | grep -E '(unusual_payload|sqli_pattern)'
```
アクセスログで POST /chat/completions への異常なリクエスト (不正な認証ヘッダ・SQLメタ文字)を過去 30〜90日分捜索。WAF/SIEM があれば該当パスのアラート発火履歴を確認。
4
Consider incident declaration escalate
```
Notify SOC / on-call
```
CISA KEV登録済 = 実環境で悪用が観測されている。Step 3 で兆候があればインシデント対応宣言、無くてもパッチ適用までWAF強化を最優先で。
5
Apply temporary workaround mitigate
```
set `disable_error_logs: true` under `general_settings`.
```
パッチが適用されるまでの応急処置として、set disable_error_logs: true under general_settings. を実施。回避策の副作用 (機能低下) を確認した上で。
6
Apply patch patch
```
Upgrade litellm to >=1.83.7
```
ステージング環境で >=1.83.7 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスと、Step 3 で見つけた異常検知の続報チェックを含めること。
7
Post-deployment verification verify
```
Replay attack against POST /chat/completions on staging to confirm patch closes the vector
```
パッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 3 と同じログクエリでアラート再発が無いか継続監視。

Affected packages

pip litellm

[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.83.7"}]}]

PyPI litellm

[{"type":"ECOSYSTEM","events":[{"introduced":"1.81.16"},{"fixed":"1.83.7"}]}]