LiteLLM Proxy SQL Injection
Pre-Authentication Database Access in the AI Gateway Credential Broker
LiteLLM Proxy versions 1.81.16 through 1.83.6 contain a pre-authentication SQL injection in the API key verification path. The proxy concatenated caller-supplied Authorization header values directly into SQL query text rather than binding them as parameters. An unauthenticated attacker can read and potentially modify the proxy's database — which stores credentials for every LLM provider, tenant, and billing configuration managed through the gateway. Fixed in 1.83.7.
Technical Breakdown
LiteLLM Proxy — SQL Injection in API Key Verification
The API key verification logic in LiteLLM Proxy built SQL queries by string-concatenating attacker-controlled Authorization header values directly into query text. This injection sink sits at an unauthenticated trust boundary — the error-handling path triggered before any credential is validated. Affected versions: 1.81.16 ≤ version < 1.83.7.
disable_error_logs: true under general_settings
Root Cause
Classic SQL injection from missing parameter binding. The key verification function assembled query text using string concatenation rather than prepared statements, placing attacker-controlled input directly into the SQL execution path at the earliest possible trust boundary — before any authentication check completes.
Vulnerable Path
The injection triggers through the error-handling code path reached when processing any LLM API route — such as POST /chat/completions. A malformed Authorization header value is sufficient to reach the vulnerable query without any prior authentication.
Why Gateways Are High-Value
LiteLLM Proxy acts as a centralized credential broker — it stores API keys for every LLM provider, manages tenant authentication, and controls billing. A single database read from this proxy can yield credentials that span OpenAI, Anthropic, Azure, and others, along with all configured user and tenant tokens.
Temporary Mitigation
If an immediate upgrade to 1.83.7 is not possible, setting disable_error_logs: true under general_settings in the proxy configuration disrupts the specific error-handling path that reaches the vulnerable query. This is a partial workaround, not a fix — upgrade as soon as possible.
Attack Chain
Identify an Exposed Proxy
Attacker identifies a LiteLLM Proxy instance running an affected version (1.81.16–1.83.6) reachable on the network. LiteLLM deployments are often exposed to internal networks or, in misconfigured environments, to the internet — their LLM API routes are designed to be called by applications, making them predictably accessible.
Version detection is possible via response headers or error messages before any payload is sent.
Craft the SQL Injection Payload
The attacker crafts an Authorization header containing SQL injection syntax. Because the proxy concatenates this value directly into a query string during key verification, the payload is interpreted as SQL rather than a literal token value. Standard SQLi techniques — UNION-based reads, blind boolean inference, error-based extraction — all apply.
The injection point is pre-authentication, so no valid API key is needed to trigger it.
Reach the Vulnerable Query via Error Handling
The request is sent to an LLM API route such as POST /chat/completions. The malformed Authorization header triggers the error-handling path where the unsanitized SQL query is executed. This path is reached before any authentication decision is made.
The error-handling code path is the specific injection sink — disabling error logs is the only workaround short of upgrading.
Extract Credentials from the Proxy Database
With arbitrary SQL read access, the attacker queries the proxy's credential and key tables. LiteLLM Proxy stores LLM provider API keys, tenant tokens, user credentials, and routing configuration in its database. A single successful extraction yields credentials for every model provider the gateway manages.
Database write access may also be achievable, enabling the attacker to insert backdoor API keys or modify routing to redirect traffic.
Leverage Stolen Credentials Across Providers
Extracted LLM provider keys are immediately usable against OpenAI, Anthropic, Azure OpenAI, and other providers configured in the gateway. The attacker gains full API access under the victim's billing accounts, can exfiltrate prompt history and model outputs, and may be able to inject responses into tenant applications that route through the compromised proxy.
Blast radius is proportional to how many providers and tenants the proxy manages — gateway compromise is a multiplier attack.
Impact
An AI gateway sits at the center of an organization's model infrastructure. Compromise is not scoped to a single application — it propagates to every tenant, provider, and application that routes through the proxy.
Credential Theft
- LLM provider API keys (OpenAI, Anthropic, Azure, etc.)
- Tenant and user authentication tokens
- Internal service-to-service secrets
- Database connection strings if stored in config
Financial & Operational
- Unauthorized API usage billed to victim accounts
- Rate limit exhaustion blocking legitimate traffic
- Quota depletion across all configured providers
- Billing fraud across multiple tenant accounts
Data & Integrity
- Access to prompt history and model outputs
- Potential database modification via SQL writes
- Backdoor API key insertion for persistent access
- Routing manipulation to redirect tenant traffic
Defensive Tutorial
Upgrade to LiteLLM Proxy 1.83.7 or later
ImmediateRun pip install --upgrade litellm or pull the updated container image. Verify the deployed version before re-enabling external traffic. This is the only complete fix — all other actions are containment measures.
Apply the error-log workaround if upgrade is delayed
ImmediateIf an immediate upgrade is blocked by change-control processes, add disable_error_logs: true under general_settings in your LiteLLM config. This disrupts the specific error-handling path that reaches the vulnerable query. Treat this as a 24-hour bridge, not a permanent fix.
Inspect access logs for malformed Authorization headers
ImmediateSearch proxy and reverse-proxy access logs for requests to LLM API routes containing unusual Authorization header values — particularly those with SQL metacharacters (', --, UNION, SELECT). Unexpected 4xx or 5xx responses against auth endpoints are also indicators.
Review database logs for suspicious queries
ImmediateEnable or review database query logs for unusual reads against credential, key, user, tenant, and routing tables. Look for UNION-based queries, unexpected column selections, or high-frequency requests from the proxy's database user. If your database lacks query logging, enable it now.
Rotate all LLM provider keys and proxy credentials
UrgentIf exploitation cannot be ruled out — or if the proxy was accessible from untrusted networks while running an affected version — rotate all credentials stored in the proxy database immediately. This includes LLM provider API keys, tenant tokens, and any internal service secrets. Notify downstream tenants if applicable.
Place the proxy behind network controls and a WAF
ImportantLiteLLM Proxy should never be directly internet-facing without an authenticated API gateway or reverse proxy in front of it. Implement network-level access controls restricting the proxy port to known application servers. Add a WAF rule to block requests with SQL injection patterns in Authorization headers as a defense-in-depth measure.
Apply minimum-privilege database permissions
ImportantThe proxy's database account should only have SELECT and INSERT permissions on the tables it needs for normal operation. Remove DELETE, UPDATE, and DDL privileges. If the injected query can only read, the write-based attack paths (backdoor key insertion, routing modification) are blocked even if the injection itself succeeds.
Encrypt credential tables at rest with externally managed keys
ImportantLLM provider credentials and tenant tokens stored in the proxy database should be encrypted at the application layer — not just at-rest disk encryption. Use an external key management service (AWS KMS, GCP KMS, HashiCorp Vault) so that raw database reads via SQL injection return ciphertext that is useless without access to the KMS.
Treat AI gateways as tier-zero infrastructure
ImportantAI gateways are credential brokers that hold keys to multiple external services, manage multi-tenant access, and control billing. They warrant the same security posture as identity providers and secret stores — mandatory code review for all authentication paths, penetration testing, and formal change management for upgrades. This is not a dev-tier service.
Separate request routing from secret custody
ImportantWhere possible, decouple the credential storage concern from the request routing concern. Use short-lived credentials injected at runtime from an external vault rather than long-lived keys stored in the proxy's database. An attacker who exfiltrates a short-lived token gets a limited-TTL window; an attacker who exfiltrates a permanent key gets indefinite access.
References
- GitHub Security Advisory GHSA-r75f-5x8p-qvmc — LiteLLM Proxy SQL Injection in API Key Verification
- CVE Program CVE-2026-42208 — LiteLLM Proxy Pre-Authentication SQL Injection
- CWE Reference CWE-89 — Improper Neutralization of Special Elements used in an SQL Command