Loading vulnerability…
CVE-2026-42208 is a critical pre-authentication SQL injection vulnerability in BerriAI LiteLLM versions 1.81.16 through 1.83.6. During proxy API-key verification, attacker-controlled bearer-token input was incorporated into a database query through string interpolation rather than bound as a query parameter. The vulnerable lookup can be reached through the proxy error-handling flow by submitting a crafted Authorization header to an exposed LLM API route. The flaw affects PostgreSQL-backed deployments and was corrected in LiteLLM 1.83.7 by replacing the unsafe query construction with parameterized and typed database operations. The vulnerability has been observed under active exploitation and is listed in CISA's Known Exploited Vulnerabilities catalog.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (8 hidden).
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.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
134 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
LiteLLM Proxy pre-authentication SQL-injection vulnerability affecting the authentication path.
A pre-authentication SQL injection vulnerability in LiteLLM AI Gateway where the Authorization Bearer token is concatenated into a PostgreSQL query during proxy API key checks, enabling unauthenticated database access and likely secret theft.
A previously disclosed pre-auth SQL injection vulnerability in LiteLLM mentioned for background/comparison.
A LiteLLM vulnerability referenced in observed scanning or exploit attempts using a second CTF prompt template.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.