Pre-auth SQL Injection in BerriAI LiteLLM proxy API key verification

This repository is a self-contained lab and detection package for CVE-2026-42208, a pre-authentication time-based SQL injection in BerriAI LiteLLM. It is part of the Nuclei ecosystem, and the main exploit artifact is nuclei/CVE-2026-42208.yaml. That template sends two POST requests to /v1/chat/completions: a baseline request with an invalid Bearer token and an injected request using the payload `' OR (SELECT pg_sleep(6)) IS NOT NULL --`. It declares the target vulnerable only if both responses are HTTP 401 and the second response is at least 5.5 seconds slower than the first, reducing false positives from slow networks or upstream 5xx errors. The repository also includes operational Bash scripts and Docker Compose to stand up a vulnerable LiteLLM instance (v1.83.6-nightly on localhost:8010) and a patched comparison instance (v1.83.7-stable on localhost:8011), each backed by separate PostgreSQL 15 containers. scripts/01-setup.sh starts the lab, polls /health/liveliness, and calls /key/generate with the lab master key to ensure at least one verification-token row exists so pg_sleep() is evaluated. scripts/02-exploit.sh is a PoC runner that measures baseline versus injected response times against both instances and prints whether SQL injection is confirmed. scripts/99-teardown.sh removes containers and data. Overall purpose: reproduce, validate, and detect the LiteLLM vulnerability safely in a lab. Main exploit capability: unauthenticated timing-based confirmation of SQL injection in LiteLLM’s Bearer-token authentication path against PostgreSQL-backed deployments. The documentation states the underlying flaw could enable broader database compromise, but the included code focuses on detection/confirmation rather than full post-exploitation.

This repository is a small proof-of-concept and local reproduction setup for a critical SQL injection vulnerability in BerriAI LiteLLM Proxy (GHSA-r75f-5x8p-qvmc). The repo contains four files: a README describing the bug and attack path, a Docker Compose environment that launches vulnerable LiteLLM and PostgreSQL, a LiteLLM YAML config, and a Python PoC script. The main exploit logic is in poc_litellm_sqli.py. It is a Python requests-based script that targets a LiteLLM Proxy HTTP service. It first checks target availability via GET /health, then sends POST requests to /chat/completions with crafted Authorization: Bearer tokens. The exploit intentionally uses a non-'sk-' token so the normal authentication assertion fails and the raw token is propagated into the failure callback chain, eventually reaching a SQL query that interpolates attacker-controlled input. The payload generated by make_payload() is a PostgreSQL time-based blind SQLi string using pg_sleep(): ' OR (SELECT 1 FROM (SELECT pg_sleep(N)) t) IS NOT NULL--. The script measures baseline timing, compares it to the injected request, and declares the target vulnerable if the response delay exceeds a threshold. Capabilities: the PoC demonstrates unauthenticated web-based SQL injection verification against vulnerable LiteLLM instances. It does not include automated exfiltration, shell access, persistence, or post-exploitation modules. However, the README explicitly notes the likely impact as database read access via blind injection, potentially exposing API keys, credentials, and proxy-managed provider secrets. Repository structure and purpose: docker-compose.yaml provisions PostgreSQL 16 and LiteLLM v1.83.3-stable on ports 5432 and 4000 respectively, with a DATABASE_URL and master key configured for local testing. litellm_config.yaml defines a minimal model configuration and references environment variables for the master key and database URL. README.md documents affected versions (>=1.81.16, <1.83.7), the vulnerable code path, example commands, and expected output. Overall, this is a legitimate PoC/reproduction repository intended to validate and demonstrate the LiteLLM Proxy SQL injection issue rather than a full exploitation toolkit.