LiteLLM Proxy Hit by Critical SQL Injection — CVE-2026-42208 (CVSS 9.3)

LiteLLM proxy users are dealing with a critical SQL injection flaw that can let unauthenticated attackers read and modify the proxy database. The issue is tracked as CVE-2026-42208 and carries a CVSS score of 9.3, which places it in the highest severity range.

According to the advisory and reporting from The Hacker News, the weakness affects the LiteLLM proxy component, which is used as an LLM gateway in front of model providers. Attackers do not need a valid account to trigger the bug. They can send specially crafted Authorization headers to any LLM API route, and the proxy can be tricked into building unsafe database queries.

SQL injection is a long-standing web security problem. It happens when application input is inserted into a database query without proper validation or parameterization, allowing an attacker to change what the database does. In this case, the exposure is especially serious because the vulnerable path sits in a proxy that may handle requests for multiple model providers and teams.

LiteLLM is commonly used to centralize access to LLMs, route requests, manage keys, and provide a single API layer across different providers. That makes the proxy convenient for organizations that want provider-agnostic routing, logging, or policy controls, but it also turns the proxy into a high-value target. If the database behind that proxy is exposed to injection, an attacker may be able to pull stored configuration data, alter routing or authentication records, or tamper with the metadata the proxy relies on.

The bug matters because proxy software tends to sit in the middle of a lot of traffic. A flaw there can affect more than one application or workflow at once, especially when teams use it as the standard path for model access. In security terms, that expands the blast radius beyond a single endpoint or user account.

LiteLLM is one of several tools that has gained traction as organizations try to manage access to multiple LLM providers from one control point. That convenience has also made it part of the security perimeter, which means weaknesses in the proxy can become weaknesses in the broader AI stack. For teams using it in production, the issue is not just whether the model calls work, but whether the middleware handling those calls can be trusted.

SQL injection remains one of the most studied web application flaws because it can turn ordinary request handling into database access. Modern frameworks often reduce the risk, but custom parsing, header handling, and query construction can still introduce gaps. Here, the fact that the attack can be triggered through an Authorization header makes the issue stand out, since that field is normally associated with authentication rather than user-supplied content that reaches database logic.

The disclosure comes as more organizations put LLM proxies in front of internal and external model traffic. Those systems are often deployed to simplify provider switching and centralize policy enforcement, but they also become a single point where request handling, secrets, and database-backed configuration meet. In LiteLLM’s case, the vulnerable proxy layer is the part doing that work, and the attack vector is available through ordinary API routes that many deployments expose by design.