The LiteLLM SQLi Exploit: What Forensics Reveals About LLM Gateway Compromise

Before engaging Vulnox for LLM security assessments, we consistently heard three concerns: "Our LiteLLM instance is only accessible from our corporate VPN, so SQL injection from the internet is impossible." "We have a WAF that blocks all injection attempts on the Authorization header." "We use a community-maintained Docker image that auto-updates. We assumed it was patched." Each of these assumptions contained a gap. The VPN-protected instance had a misconfigured load balancer that exposed the proxy on the public interface for 48 hours during a maintenance window. The WAF rule did not inspect the part of the header after the Bearer token. The auto-update cycle rebuilt the container every Monday morning; the fix shipped on a Thursday afternoon. In all three cases, the window of exposure was real.

The advisory for CVE-2026-42208 published on April 24, 2026, disclosed a pre-authentication SQL injection in LiteLLM's proxy API key verification step. Within 36 hours, Sysdig observed targeted exploitation. The attacker sent a single request to /chat/completions with an Authorization: Bearer header containing a SQL injection payload. They used a time-based blind technique to confirm the database type, then switched to a UNION-based extraction. The first query enumerated table names. The second extracted rows from the litellm_api_key table. The third targeted the litellm_environment_variables table. The attacker copied the response data to an external endpoint using a DNS out-of-band channel embedded in a subquery. Vulnox analysis of honeypot logs shows the attacker used two distinct IP addresses: the first for reconnaissance and extraction, the second (rotated 14 minutes later) for validation queries. The intervals suggest automated tooling with manual oversight. The extracted data included 47 API keys across OpenAI, Anthropic, and Azure OpenAI endpoints. The attacker then used one of those keys to initiate a chat completion session from a third IP, consuming tokens and enumerating available models. That activity was not detected by the organization's cloud security monitoring because the API call originated from a known IP block associated with the provider's API endpoint.

The most impactful recovery mistake is rotating only the keys visible in the LiteLLM database while forgetting the provider-side API keys that are stored as plaintext in the same row. An attacker who extracted those keys can still call OpenAI, Anthropic, or Bedrock endpoints. Vulnox observed an incident where the victim rotated the LiteLLM master key but not the three OpenAI keys. The attacker continued using those keys for 72 hours before the provider's anomaly detection flagged unusual geographic access. The most commonly missed action is checking whether the attacker used the extracted keys for any API calls. That requires reviewing cloud provider usage logs. Most teams skip this step because it falls between the security team (who manage the proxy) and the cloud team (who manage provider accounts). Another frequent mistake: not revoking and re-issuing the LiteLLM proxy's own database connection string. The SQL injection allowed reading arbitrary tables. If the attacker obtained the database credentials, they could reconnect even after the patch. We recommend generating a new database user with a fresh password and updating the LiteLLM configuration accordingly.

The first mistake: relying on disable_error_logs workaround without functional testing. One client set the configuration file flag to true but did not restart the service. The vulnerable code path continued to expose errors. The second mistake: not version-pinning the LiteLLM container image in orchestration files. Teams use the latest tag, which rebuilds on every deploy. If the fixed version ships mid-cycle, the container may pick it up, but if the tag is locked to a specific version, the fix is never applied until someone manually updates the tag. The third mistake: assuming the WAF is effective. Most SQL injection payloads targeting the Authorization header use complex encoding that bypasses signature-based rules. The WAF rule must inspect the entire header value, not just the Bearer token length. We have seen rule sets that only check the first 100 characters, while the payload extends beyond that.