What is Lyrie Research?

Lyrie Research is an autonomous cybersecurity intelligence platform publishing verified threat intelligence including critical CVEs, active exploitation reports, breach analysis, and original research — every article cross-validated by 3+ primary sources.

How does Lyrie.ai protect against rogue AI threats?

Lyrie.ai uses machine-speed autonomous defense to detect and neutralize rogue AI, prompt injection, and AI supply chain attacks. It responds before human analysts can react.

What cybersecurity topics does Lyrie Research cover?

Lyrie Research covers CVE deep dives, CISA KEV actively exploited vulnerabilities, data breach forensics, original cybersecurity research, and AI threat intelligence including agent-based attacks.

How often is Lyrie Research updated?

Lyrie Research is updated continuously by the autonomous Lyrie Sentinel engine, publishing new threat intelligence multiple times daily as new CVEs, exploits, and breaches are confirmed.

Is Lyrie Research free to access?

Yes, all articles on Lyrie Research are freely accessible. For active protection by the same intelligence engine, visit lyrie.ai.

The AI Gateway Is the New Perimeter: CVE-2026-42208, LiteLLM's Pre-Auth SQL Injection, and the 36-Hour Exploit Window Nobody Warned You About

← AI-Security Deep-Dive

0 sources verified·12 min read

By Lyrie.ai Cyber Research Division — Senior Analyst Desk·5/3/2026

TL;DR

CVE-2026-42208 is a critical (CVSS 9.3) pre-authentication SQL injection in LiteLLM — the open-source LLM proxy used by thousands of engineering teams to centralize access to OpenAI, Anthropic, AWS Bedrock, and Azure OpenAI. The flaw lives in the proxy's own authentication step: an attacker with no credentials sends a crafted Authorization: Bearer header, breaks out of the SQL string literal, and reads arbitrary data from the PostgreSQL backend — including every provider API key, virtual key, and runtime secret the proxy manages.

The advisory was indexed globally on April 24, 2026 at 16:17 UTC. Sysdig's Threat Research Team captured the first real-world exploitation attempt 36 hours and 7 minutes later — not a generic SQLmap spray, but a schema-aware, targeted enumeration of the three highest-value tables in LiteLLM's database. The patch (v1.83.7-stable) shipped on April 19, 2026. If you're still running anything between v1.81.16 and v1.83.6 and that proxy faces the internet, you have already been in an active exploitation window for over a week. Rotate everything immediately and read this first.

Background: Why LiteLLM Is a Crown Jewel Target

LiteLLM started life as a convenience library — a few hundred lines of Python that let developers swap between LLM providers by changing one string. By early 2026 it had grown into one of the most widely deployed AI gateway solutions in the world: 22,000+ GitHub stars, thousands of production forks, and a place in the infrastructure stacks of startups, enterprises, and government agencies building on top of commercial LLM APIs.

What makes LiteLLM architecturally useful also makes it architecturally dangerous. Its entire value proposition is centralization: one proxy that holds all your model-provider credentials, enforces spend budgets, mints virtual API keys for downstream applications, and routes traffic across providers based on policy. In a mature deployment that proxy's PostgreSQL database is a condensed map of an organization's entire AI posture — every OpenAI org key, every Anthropic workspace credential, every Bedrock IAM role ARN, and every runtime secret the proxy needs to call home.

Security professionals will immediately recognize the pattern: it's the same calculus that made password managers and secrets managers high-value targets. When you build infrastructure that exists specifically to hold secrets on behalf of other systems, you create a target that is qualitatively more valuable than any of those systems individually. Compromise the gateway once; own every model integration in the stack.

LiteLLM's open-source nature compounds the risk in a way that closed-source proxies avoid. The entire Prisma-generated database schema — table names, column names, index definitions — is publicly readable on GitHub. An attacker building an exploit doesn't need to probe blind. They already have the map.

Technical Analysis: How the Injection Works

Root Cause

In affected LiteLLM versions (≥ 1.81.16, < 1.83.7), the proxy's check_valid_token() verification function — which runs before any authentication decision is made — takes the raw Bearer value from the incoming Authorization header and concatenates it directly into a SQL SELECT against the LiteLLM_VerificationToken table:

# Simplified pseudocode of the vulnerable pattern
query = f"SELECT * FROM LiteLLM_VerificationToken WHERE api_key = '{bearer_value}'"
result = db.execute(query)

This is textbook SQL injection via string interpolation. No parameterized query binding. No input sanitization. Because this code executes as part of the auth check itself — not behind a successful login — the injection is fully unauthenticated. Any HTTP client that can reach the LiteLLM proxy on port 4000 (the default) can trigger it.

The fix in v1.83.7 replaces the interpolation with a parameterized query:

result = db.execute("SELECT * FROM LiteLLM_VerificationToken WHERE api_key = $1", bearer_value)

One line change. Nine months of exposure.

Attack Surface

The injection runs in the POST /chat/completions handler but the same verification code path is reachable from any authenticated LLM API route. The attacker's Bearer value never needs to be a real key — it needs only to contain a single quote to escape the string literal and append arbitrary SQL. A classic UNION-based injection then allows selective exfiltration from any table the proxy user can read.

Three tables are the primary targets, and observed exploitation went straight to all three:

| Table | Contents |

|---|---|

| LiteLLM_VerificationToken | Virtual API keys (sk-litellm-...), including the master key |

| litellm_credentials | credential_values column holding upstream provider keys (OpenAI, Anthropic, Bedrock, Azure) |

| litellm_config | environment_variables row — the proxy's runtime env: PostgreSQL DSN, cache backends, webhook secrets, and more |

A successful read of all three gives an attacker everything needed to: (1) impersonate any downstream application using the virtual key system; (2) call any upstream LLM provider with the organization's credentials; and (3) pivot to any connected infrastructure whose secrets are stored in the proxy's environment variable config.

Why CVSS 9.3?

The score reflects the near-worst-case impact combination:

Pre-authentication: no credentials required, no rate limiting before injection, no CAPTCHA, no IP allow-list enforced at the vulnerable code layer.
Network-reachable: port 4000 is often exposed to the internet in development and staging deployments, and frequently exposed internally in enterprise networks.
Confidentiality impact HIGH: provider credentials are functionally equivalent to unlimited billing-backed access to LLM services.
Integrity impact: UNION-based injection allows writes in some configurations.
Availability: key invalidation via database modification can take the proxy offline.

The one factor keeping it at 9.3 rather than a theoretical 10.0 is that observed exploitation stopped at exfiltration — there was no confirmed key reuse or lateral movement during the capture window.

What Sysdig Observed: A Schema-Literate Attacker

The most operationally significant finding in Sysdig TRT's analysis is not the existence of exploitation — it's the precision of it.

Generic SQL injection scanners (SQLmap, ghauri, similar) probe blind: they try default table names (users, admin, accounts), common column patterns, and systematic enumeration. That behavior leaves distinctive high-volume noise in logs and typically gets blocked by WAF rule sets within minutes.

The actor observed on April 26, 2026 (source: 65.111.27.132, AS200373 / 3xK Tech GmbH) did none of that. Their first four payloads went directly to:

1. litellm_verificationtoken (lowercase test — standard PostgreSQL case folding)

2. litellm_credentials.credential_values — upstream provider keys

3. litellm_config WHERE param_name='environment_variables' — runtime secrets

4. "LiteLLM_VerificationToken" (PascalCase retry using quoted identifier)

The PascalCase retry is the tell. PostgreSQL folds unquoted identifiers to lowercase at query time; LiteLLM's Prisma ORM generates LiteLLM_VerificationToken (PascalCase) in the schema. When the lowercase probe returned no rows, the attacker immediately retried with the quoted PascalCase form — demonstrating they had either read the LiteLLM Prisma schema on GitHub or had LLM assistance to generate the correct identifier. Generic scanners do not do this.

A second source IP, 65.111.25.67 (adjacent /22, same AS), replayed the payload set 42 minutes later and then probed /key/generate and /key/info without authentication — consistent with an actor who expected the enumeration to have succeeded and was attempting to mint new keys or confirm existing ones.

The user-agent on all requests: Python/3.12 aiohttp/3.9.1. Weaponized within a scripted async Python toolchain — not a browser, not a commercial scanner.

Critical nuance: no confirmed follow-through was observed. No authenticated calls using exfiltrated keys, no LLM API calls against upstream providers using stolen credentials. The absence of follow-through within the capture window does not mean the actor did not have successful exfiltration — it means the Sysdig telemetry did not capture the downstream use, which could happen from a different IP, network, or time window entirely.

IOCs / Threat Intelligence

| Indicator | Type | Notes |

|---|---|---|

| 65.111.27.132 | IPv4 | Primary exploitation source, Phase 1 schema enumeration |

| 65.111.25.67 | IPv4 | Secondary source (same /22), replays + key-management probe |

| AS200373 / 3xK Tech GmbH | ASN | Both source IPs registered to this Austrian VPS provider |

| Python/3.12 aiohttp/3.9.1 | User-Agent | Consistent across all observed payloads |

| sk-litellm' prefix | Pattern | Injection entry point; single quote after prefix breaks SQL string literal |

| UNION SELECT ... FROM "LiteLLM_VerificationToken" | SQL Pattern | PascalCase-quoted identifier signals schema-aware payload |

| GHSA-r75f-5x8p-qvmc | Advisory ID | GitHub Security Advisory tracking the flaw |

| CVE-2026-42208 | CVE | NVD entry, CVSS 9.3 |

| Affected versions | Range | LiteLLM >= 1.81.16, < 1.83.7 |

| Fixed version | Version | v1.83.7-stable (released April 19, 2026) |

The Lyrie Take: The AI Gateway Attack Surface Just Became the Primary Enterprise Risk Vector

CVE-2026-42208 is a watershed moment, but not primarily because of the technical severity of an unparameterized SQL query — that's a 1990s mistake and an inexcusable one in critical infrastructure. The watershed is what this flaw and its exploitation pattern reveal about the new threat model for AI-first organizations.

AI gateways are now credential vaults. The architectural shift toward centralized LLM proxy infrastructure — LiteLLM, Portkey, Kong AI Gateway, and similar tools — has created a new class of high-value credential target that did not exist three years ago. Security programs designed around "protect the application, protect the database, protect the endpoint" have a blind spot: the middleware layer that aggregates all your AI spending power, all your provider relationships, and often your runtime environment configuration into a single addressable endpoint. Traditional vulnerability management programs are not scanning these tools with the frequency they deserve. Security teams that review web app scans weekly but look at AI gateway dependencies monthly are creating exactly the kind of gap this actor stepped through.

Open-source schema visibility eliminates the reconnaissance phase. A key observation from Sysdig's analysis: the actor went straight to the high-value tables on the first try, with correct identifier casing. In a closed-source target, discovering the table that holds credentials requires blind enumeration — time-consuming and noisy. In LiteLLM, the Prisma schema is a public document on GitHub. The attacker's "research" was reading documentation. As AI infrastructure increasingly standardizes on well-known open-source proxies, this dynamic will apply to every future SQL injection, deserialization flaw, or authentication bypass in that class of software. Defenders face a world where the adversary's knowledge of their own attack surface is effectively perfect the moment a CVE lands.

The 36-hour window is the new SLA threat model. 36 hours is not a surprising exploitation timeline for a critical pre-auth vulnerability in widely deployed infrastructure — Sysdig's own research has documented sub-24-hour exploitation for other classes. But for AI infrastructure operators who may have inherited LiteLLM deployments from ML teams who updated it on a "works, don't touch" cadence, 36 hours is catastrophic. The gap between "CVE indexed in Dependabot" and "security team triages and approves emergency patch" in a typical enterprise is 3–10 days. Every LiteLLM deployment that was internet-accessible during the April 24–May 3 window should be treated as potentially compromised.

Credential theft from AI gateways has a different blast radius. When attackers steal a database credential, they get access to a database. When they steal a LiteLLM master key or provider credential set, they get: (a) unlimited LLM API access billed to the victim organization (potentially $100K+ in a weekend depending on model and usage tier); (b) the ability to insert themselves into any prompt or response flowing through the proxy; (c) in some configurations, the ability to redirect model routing to attacker-controlled endpoints; and (d) every downstream secret stored in the proxy's environment variable config, which often includes database connection strings, S3 bucket credentials, webhook tokens, and monitoring API keys. That's not one credential compromised. That's organizational infrastructure access through a single pre-auth HTTP request.

Defender Playbook

Immediate (do today, before anything else):

1. Identify every LiteLLM deployment in your environment. Include Docker Compose stacks, k8s Helm deployments, bare-metal pip installations, and any CI/CD pipelines that spin up a proxy for testing. Use pip show litellm on accessible hosts. Check container image tags in docker-compose.yml and Kubernetes manifests.

2. Patch to v1.83.7-stable or later. This is the only complete fix. No WAF rule fully compensates for a pre-auth injection that runs inside the auth handler itself.

3. Rotate all credentials stored in LiteLLM. Any deployment running a vulnerable version between April 19 (when the maintainer-side advisory published) and patch application should be treated as compromised. Rotate: OpenAI organization API keys, Anthropic workspace keys, AWS Bedrock IAM credentials, Azure OpenAI service keys, and the LiteLLM master key. Also rotate any secrets stored in the proxy's environment variable configuration.

4. Review audit logs for the IOC signatures. Check for Authorization: Bearer sk-litellm' patterns in web access logs. Check for Python/3.12 aiohttp/3.9.1 user-agent in logs from the April 24 – present window. Check for traffic from 65.111.27.132 and 65.111.25.67. Check for unusual downstream LLM API spend spikes.

Short-term (this week):

5. Network-segment LiteLLM proxies off the public internet. Production LiteLLM instances should never be directly internet-facing. Put them behind an internal load balancer, authenticate the network layer via mTLS or VPN, and enforce IP allowlisting for the LiteLLM admin interface. Port 4000 should be invisible to anything outside your application tier.

6. Enable LiteLLM's built-in auth hardening options. Set general_settings.master_key_hash rather than storing the master key in plaintext. Enable general_settings.disable_admin_ui in production. Set max_budget and budget_duration on all virtual keys to limit blast radius from key theft. See the LiteLLM security hardening docs post from April 2026.

7. Deploy a WAF rule as defense-in-depth. While not a substitute for patching, a WAF rule blocking UNION-based SQL keywords in HTTP headers will catch unsophisticated variants and buy time. ModSecurity CRS rule 942100 covers UNION SELECT patterns.

8. Add LiteLLM to your critical dependency monitoring. Subscribe to github.com/BerriAI/litellm/security/advisories notifications. Add the package to your SCA scanner's alert list with "critical = patch within 24 hours" policy.

Ongoing:

9. Treat your AI gateway like a PAM system. Privileged Access Management tooling exists for databases and SSH; the same philosophy applies to anything that aggregates credentials. Audit access to the LiteLLM admin UI. Log all /key/generate and /key/info API calls. Alert on any virtual key creation outside normal working hours or from unexpected source IPs.

10. Consider a dedicated AI infrastructure security review. If your organization is running LiteLLM, Portkey, or similar proxies in production, those deserve a dedicated penetration test and threat model review — separate from your standard web app scope. The attack surface is distinct: authentication flows, credential storage patterns, upstream key reuse, and prompt injection into the proxy's routing logic all require specialized review methodology.

Sources

1. Sysdig TRT, "CVE-2026-42208: Targeted SQL injection against LiteLLM's authentication path discovered 36 hours following vulnerability disclosure" — sysdig.com/blog/cve-2026-42208 (April 28, 2026)

2. GitHub Security Advisory GHSA-r75f-5x8p-qvmc — github.com/BerriAI/litellm/security/advisories (April 20/24, 2026)

3. Vulert, "LiteLLM CVE-2026-42208 SQL Injection Exploited" — vulert.com/blog/litellm-cve-2026-42208-sql-injection (April 29, 2026)

4. The Hacker News, "LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure" — thehackernews.com (April 30, 2026)

5. BleepingComputer, "Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw" — bleepingcomputer.com (April 29, 2026)

6. Rescana, "CVE-2026-42208: Critical Pre-Auth SQL Injection in LiteLLM Actively Exploited" — rescana.com (April 30, 2026)

7. LiteLLM Security Hardening Blog, "Security Update: Vulnerability Disclosures and Ongoing Hardening" — docs.litellm.ai/blog/security-hardening-april-2026 (April 2026)

8. NVD CVE-2026-42208 — nvd.nist.gov/vuln/detail/CVE-2026-42208

Lyrie.ai Cyber Research Division — Senior Analyst Desk