CVE-2026-42208

LiteLLM has a Proxy API that checks whether an incoming API key is valid. In vulnerable versions, it can be tricked into treating attacker-controlled text as part of a database “instruction,” letting the attacker reach into LiteLLM’s database. Think of it like a bouncer that’s supposed to check your ID—but instead reads a forged message written into the ID card itself, and that message can be used to open the vault.

This matters if you run LiteLLM (the LiteLLM proxy/AI gateway service) using versions 1.81.16 through 1.83.6. It is specifically a risk when the Proxy API is accessible to external attackers (reachable from the Internet), because the attacker does not need any login or user action to attempt the SQL injection.

This is urgent because it is listed in CISA KEV, meaning it has been confirmed as a real-world security issue that requires action. The attack is network-based and does not require authentication, so exposure can turn into compromise quickly when the Proxy API is reachable from the Internet.

1. Confirm exposure and version

   • Identify the LiteLLM version currently deployed. Check the container/image tag, installed package version, or startup/version logs.
   • Confirm whether the LiteLLM Proxy API is reachable from outside your network (for example, directly accessible over the public Internet).

2. Determine whether you are within the vulnerable range

   • Vulnerable: LiteLLM version between 1.81.16 and 1.83.6.
   • Fixed: LiteLLM 1.83.7.

3. Upgrade plan (primary remediation)

   • Upgrade LiteLLM to 1.83.7 or later as the fix.
   • After upgrading, verify at runtime that the service is truly running the upgraded version (not just the desired version in configuration).

4. Temporary risk reduction if you cannot upgrade immediately

   • Restrict network access so the Proxy API is not directly reachable from the Internet.
   • Only allow access from trusted IP ranges/VPN/bastion hosts where applicable.
   • If you cannot lock down reachability, prioritize upgrading immediately because exploitation does not require authentication.

5. Post-upgrade checks

   • Monitor LiteLLM/proxy logs for signs of repeated failed key checks or unusual Authorization header patterns.
   • Review any alerts around authentication failures, unexpected proxy behavior, or database-related errors.

6. Compliance timing

   • CISA KEV due date: 2026-05-11. Treat your upgrade/disabling decision as aligned to that deadline.

7. What to monitor after patching

   • Continued external access attempts to the Proxy API.
   • Any evidence of prior compromise (unexpected changes in service configuration, credential store anomalies, or sudden spikes in database errors). If you suspect compromise, involve incident response and rotate any credentials managed by the proxy as appropriate.

Severity is critical: the vulnerability is a SQL injection (CWE-89) in LiteLLM’s Proxy API key verification logic. The mechanism is that user-controlled input from a crafted Authorization header is improperly incorporated into a database query instead of being passed safely as a parameter. This enables unauthenticated attackers to execute arbitrary SQL against the proxy database via the proxy’s key-check/error-handling path, with potential database read and modification, leading to unauthorized access to the proxy and credentials it manages. The issue is confirmed for real-world response via CISA KEV (added 2026-05-08) with remediation due 2026-05-11, which elevates urgency beyond prediction. Fixed in LiteLLM 1.83.7. No public exploit code is recorded in the findings; however, CISA KEV listing indicates active risk requiring mitigation.