AI gateways have quickly become an important part of modern software infrastructure. They sit between applications and model providers, helping teams manage LLM access, route requests, enforce budgets, and centralize API key usage.
That central role also makes them attractive targets.
CVE-2026-42208 is a critical vulnerability in LiteLLM Proxy, an AI gateway used to call LLM APIs through OpenAI-compatible or native formats. The issue affects LiteLLM versions 1.81.16 through 1.83.6 and was patched in version 1.83.7.
The vulnerability is especially serious because it can be reached before authentication succeeds. An attacker does not need a valid account, a valid API key, or user interaction. A crafted request to an LLM API route may be enough to trigger the vulnerable path.
Overview of CVE-2026-42208
LiteLLM Proxy checks API keys when requests come into routes such as:
POST /chat/completions
Authorization: Bearer <token>In the vulnerable versions, part of the database query used during proxy API key checks included caller-controlled input from the supplied key value. Instead of treating that key value strictly as data, the query construction allowed the input to become part of the query text.
That created a SQL injection vulnerability.
The public description states that an unauthenticated attacker could send a specially crafted Authorization header to an LLM API route and reach the vulnerable query through the proxy's error-handling path. Successful exploitation could allow the attacker to read data from the proxy database and may also allow modification of data.
That means the impact is not limited to a failed login or a broken request. The attacker may be able to access sensitive information stored or managed by the proxy.
Severity
CVE-2026-42208 has a CVSS 3.1 base score of 9.8, rated Critical.
The vector is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HIn plain terms, this means:
- The vulnerability can be exploited remotely over the network.
- The attack complexity is low.
- No privileges are required.
- No user interaction is required.
- The impact on confidentiality, integrity, and availability is high.
This combination is what makes the issue severe. A remotely reachable LiteLLM Proxy running an affected version could expose sensitive backend data to an unauthenticated attacker.
Affected versions
The affected LiteLLM Proxy versions are:
1.81.16 through 1.83.6The issue was patched in:
1.83.7Organizations running LiteLLM Proxy should upgrade to a fixed version immediately. Where possible, upgrade to the latest stable release rather than only the first patched version.
Why this vulnerability matters
LiteLLM Proxy is not just a simple request router. In many deployments, it acts as the central control point for LLM access.
A proxy may manage or interact with:
- virtual API keys
- model access rules
- provider credentials
- usage tracking
- team or user limits
- routing configuration
- billing-related controls
- database-backed access policies
Because of that, compromising the proxy database can have consequences beyond the LiteLLM service itself.
If an attacker can read sensitive database contents, they may be able to discover internal access keys, configuration details, or credential material. If an attacker can modify records, they may be able to change access rules, create unauthorized access paths, or interfere with the normal operation of the gateway.
This is why vulnerabilities in AI gateways should be treated as control-plane risks, not just application bugs.
Possible impact
The exact impact depends on how LiteLLM Proxy is configured, what database it uses, and what information is stored in that database. Still, the potential consequences are serious.
Unauthorized database access
The most direct risk is that an attacker could read data from the LiteLLM Proxy database. This may include information about users, teams, virtual keys, configuration, and provider-related settings.
Exposure of managed credentials
AI gateways often hold or reference credentials used to access upstream LLM providers. If those credentials are exposed, attackers may be able to make unauthorized model calls, consume paid resources, or access systems indirectly through trusted integrations.
Unauthorized access to the proxy
If the attacker can modify database records, they may be able to create or alter keys, change permissions, or otherwise gain access to the proxy in a way that bypasses intended controls.
Service disruption
Because the CVSS score includes high availability impact, the vulnerability may also create risk of service disruption. Database modification, corrupted records, or malicious changes to configuration could affect the availability of the LiteLLM Proxy service.
Broader infrastructure risk
LiteLLM Proxy may sit close to sensitive internal services. A compromise at this layer could help attackers understand the organization's AI infrastructure, internal model usage, and credential relationships.
Why the Authorization header is important
One detail that makes this vulnerability notable is the attack surface: the Authorization header.
Security teams often pay close attention to request bodies, query parameters, and uploaded files. But headers are also attacker-controlled input.
In this case, the attacker could place crafted content inside the bearer token value. Because the value was processed during API key verification, the vulnerable logic occurred early in the request lifecycle.
That makes the issue particularly dangerous. Authentication checks are supposed to decide whether a request is trusted. When the authentication check itself contains a database injection flaw, attackers may be able to reach sensitive backend behavior before they have proven who they are.
Example attack path at a high level
A simplified exploitation flow may look like this:
- The attacker identifies a LiteLLM Proxy instance.
- The attacker sends a request to an LLM API route, such as
/chat/completions. - The request includes a specially crafted
Authorizationheader. - LiteLLM Proxy attempts to validate the supplied API key.
- The vulnerable query path is reached during key checking or error handling.
- The attacker's crafted input influences the database query.
- The attacker may be able to read or modify database data.
The important point is that this does not require a valid LiteLLM API key. The malicious input is sent where an API key would normally appear.
Indicators teams should review
Organizations that ran affected versions should review logs and telemetry for suspicious requests to LiteLLM Proxy endpoints.
Areas worth checking include:
- reverse proxy logs
- LiteLLM application logs
- database query logs
- WAF or API gateway logs
- container logs
- Kubernetes ingress logs
- cloud workload telemetry
Suspicious patterns may include unusual Authorization header values, unexpected SQL-related strings, repeated unauthenticated failures, or errors from LLM API routes that were not normally accessed by those clients.
Teams should also review whether unusual database access occurred during the exposure window.
Recommended response
Upgrade immediately
The most important action is to upgrade LiteLLM Proxy to a fixed version.
Affected: 1.81.16 through 1.83.6
Fixed: 1.83.7 and later
A patched version should be deployed as soon as possible across all environments, including production, staging, development, and any test systems exposed to shared networks.
Investigate exposure
After upgrading, teams should determine whether the vulnerable instance was reachable by untrusted users or systems.
Key questions include:
- Was the LiteLLM Proxy exposed to the public internet?
- Was it accessible from a shared internal network?
- Was it behind an API gateway, VPN, or identity-aware proxy?
- Were any LLM API routes reachable without another layer of authentication?
- How long was the affected version running?
- Were there suspicious failed requests during that time?
Exposure analysis is important because patching stops future exploitation, but it does not answer whether compromise already occurred.
Review database activity
If database query logging is available, review activity from the time the vulnerable version was deployed until the upgrade was completed.
Look for unexpected queries, unusual table enumeration, suspicious reads from credential-related tables, or changes to key and user records.
Even if application logs look normal, database logs may reveal activity that did not appear clearly at the HTTP layer.
Rotate sensitive credentials
If the proxy was exposed to untrusted traffic while vulnerable, credential rotation should be strongly considered.
This may include:
- LiteLLM virtual keys
- LiteLLM master keys
- upstream LLM provider API keys
- database credentials
- service credentials used by the proxy
- cloud credentials reachable from the LiteLLM environment
The urgency of rotation depends on exposure, logging evidence, and how sensitive the stored data is. However, because the vulnerability may allow database reads, teams should not assume secrets remained safe without evidence.
Check for unauthorized changes
Teams should inspect LiteLLM Proxy configuration and database records for unexpected modifications.
This includes checking:
- newly created keys
- changed permissions
- modified user or team records
- altered model access rules
- unexpected provider configuration
- unusual routing changes
- suspicious admin-related changes
Unauthorized changes may persist after the software is upgraded, so configuration review matters.
Monitor usage and billing
After a possible AI gateway compromise, billing and usage telemetry can provide useful signals.
Watch for:
- sudden token usage spikes
- unfamiliar models being used
- activity from unusual IP addresses
- unexpected high-cost model calls
- usage outside normal operating hours
- new clients or services using the proxy
- provider-side billing anomalies
A stolen credential may not be used immediately. Continued monitoring after patching is important.
Hardening LiteLLM Proxy deployments
Beyond upgrading, organizations should review how LiteLLM Proxy is deployed.
A production AI gateway should not be treated like a simple developer tool. It often protects access to expensive and sensitive external services.
Useful hardening steps include:
- placing the proxy behind a trusted API gateway
- restricting access by network or identity
- avoiding direct public exposure where possible
- separating admin access from inference routes
- enabling strong logging
- monitoring failed authentication attempts
- limiting database permissions
- using secret managers for sensitive credentials
- rotating credentials regularly
- alerting on unusual LLM usage patterns
These controls reduce the impact of future vulnerabilities and make detection easier when something goes wrong.
Why this is a bigger AI security lesson
CVE-2026-42208 reflects a broader trend: AI infrastructure is becoming critical infrastructure.
Organizations are no longer experimenting with LLMs only in isolated prototypes. They are building internal tools, customer-facing applications, automation workflows, and developer platforms around AI gateways.
That means the gateway layer now carries real security responsibility.
A compromised AI gateway can expose credentials, increase costs, leak internal configuration, and weaken access controls across multiple applications. As companies centralize LLM access, the gateway becomes a high-value target.
Security teams should include AI gateways in the same risk category as API gateways, identity brokers, CI/CD systems, and secrets-adjacent services.
What executives and engineering leaders should take away
For leadership teams, the main concern is not the technical detail of SQL injection. The concern is that an unauthenticated attacker may be able to reach sensitive data in an AI gateway database.
The response should be practical:
- Confirm whether LiteLLM Proxy is in use.
- Identify all deployed versions.
- Upgrade affected systems.
- Review exposure and logs.
- Rotate credentials if exposure is plausible.
- Strengthen access controls around the proxy.
This should not be treated as a routine dependency update if the proxy was reachable from untrusted networks. It should be handled as a potential security incident until logs and configuration reviews suggest otherwise.
Final thoughts
CVE-2026-42208 is a critical vulnerability in LiteLLM Proxy versions 1.81.16 through 1.83.6. It allows an unauthenticated attacker to send a crafted Authorization header to an LLM API route and potentially access or modify database data through a vulnerable API key checking path.
The issue is fixed in version 1.83.7.
For affected organizations, the priority is clear: upgrade, investigate, rotate sensitive credentials where appropriate, and review the security posture of the AI gateway layer.
As AI infrastructure becomes more central to business operations, services like LiteLLM Proxy need the same level of protection as any other critical access-control system.
Reference: CVE-2026-42208 on NVD