CVE-2026-42208

What it actually does

CVE-2026-42208 is an unauthenticated SQL injection in LiteLLM proxy API key validation. In affected versions 1.81.16 through versions before 1.83.7, caller-controlled data from the Authorization header is interpolated into a database query during API key checks rather than safely bound as a parameter. Because the vulnerable code path can be reached through normal LLM API routes, including routes such as POST /chat/completions, an attacker can manipulate backend SQL execution without valid credentials. Successful exploitation can expose database contents, alter proxy records, create or modify access paths, and potentially retrieve or abuse credentials, tokens, or model-provider secrets managed by the LiteLLM proxy.

Why it matters to the business

A vulnerable LiteLLM deployment can allow an outside attacker to break into the AI gateway without a valid API key, steal sensitive credentials or usage data, and potentially gain control over LLM access. This can lead to unauthorized model usage costs, exposure of user prompts or operational metadata stored in the proxy database, compromise of downstream provider keys, service disruption, and broader access if stolen secrets are reused elsewhere. The risk is urgent because the vulnerability is listed in CISA KEV, has a high EPSS score, is reported as actively exploited in the wild, and has a CISA remediation due date of 2026-05-11.

How an attack unfolds

An attacker identifies an internet-accessible LiteLLM proxy running an affected version. They send a request to a normal LLM API endpoint, such as /chat/completions, with a deliberately malformed or crafted Authorization header. During proxy API key validation, the application reaches an error-handling path that constructs a database query using the supplied key value directly in the SQL text. The attacker iteratively adjusts the injected value to confirm database interaction, enumerate schema or records, and extract sensitive data. Depending on database permissions and query context, the attacker may also modify proxy records, create or alter API keys, tamper with authorization state, or retrieve provider credentials managed by the proxy. Public reporting indicates active exploitation, including activity associated with ClickFix and FakeCaptcha poisoning campaigns, so defenders should assume exposed vulnerable instances may have been probed or attacked.

How to fix it

Upgrade LiteLLM to version 1.83.7 or later. Treat all LiteLLM versions from 1.81.16 through versions before 1.83.7 as vulnerable. If immediate upgrade is not possible, restrict network access to the LiteLLM proxy to trusted clients only, block unauthenticated internet access, place the service behind strong authentication and authorization controls, and add request filtering for suspicious Authorization header patterns as a temporary compensating control. Rotate LiteLLM proxy keys, downstream LLM provider API keys, database credentials, and any secrets stored or managed by the proxy if exposure is suspected. Review database permissions used by the proxy and ensure the application account has the least privileges required. After patching, restart affected services and verify that all running containers, virtual environments, and deployment images use the patched package version rather than only updating source manifests.

How to confirm the fix worked

Confirm the installed LiteLLM package or container image is version 1.83.7 or later. Check runtime environments directly using package metadata, dependency lockfiles, container image manifests, or application startup logs. Validate that no running instances still report affected versions between 1.81.16 and 1.83.6. From an external perspective, confirm that unauthenticated access to LLM API routes is not broadly exposed and that malformed Authorization headers no longer produce SQL errors, differential database behavior, or abnormal server responses. Review deployment pipelines and base images to ensure older LiteLLM versions are not redeployed. If exploitation is suspected, validate integrity of API key records, user/team records, routing configuration, provider credentials, and audit logs against known-good baselines.

Typical attack path

1. Discover an exposed LiteLLM proxy service or AI gateway endpoint.
2. Confirm that LLM-compatible API routes such as /chat/completions are reachable over the network.
3. Send unauthenticated requests with crafted Authorization header values designed to alter backend SQL behavior.
4. Trigger the vulnerable proxy API key validation and error-handling path.
5. Use SQL injection techniques to confirm exploitability through SQL errors, timing behavior, or response differences.
6. Enumerate database metadata, API key records, user or team records, proxy configuration, and stored credentials where accessible.
7. Optionally modify database records to create unauthorized access, alter existing API keys, or disrupt service.
8. Use stolen provider credentials or proxy access for unauthorized LLM usage, data theft, persistence, or further compromise.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse-proxy logs, WAF events, LiteLLM application logs, database audit logs, and cloud/container runtime logs covering at least the period since publication and any earlier exposure window for affected versions. Focus on unauthenticated or failed-authentication requests to LLM API routes with unusual Authorization header values, especially values containing SQL metacharacters, comments, encoded quotes, UNION/SELECT-like syntax, boolean probes, or time-delay functions. Look for application responses containing SQL/database error messages during API key validation. In database logs, look for malformed queries involving API key lookup tables or authentication checks, unexpected SELECTs against metadata tables, and any INSERT/UPDATE/DELETE activity around proxy API keys, users, teams, credentials, or routing configuration from the application account at times correlated with suspicious HTTP requests. Investigate spikes in 400/401/403/500 responses on LLM routes, repeated malformed Authorization headers from a single source, and abnormal provider usage or token consumption after suspicious requests. Because exploitation may be blind or error-free, absence of SQL errors does not prove absence of compromise; correlate network, application, database, and provider-billing telemetry.

• POST /chat/completions
• /chat/completions
• Authorization: Bearer '
• Authorization: Bearer "
• Authorization: Bearer %27
• Authorization: Bearer %22
• Authorization: Bearer `
• Authorization: Bearer ')
• Authorization: Bearer ")
• Authorization: Bearer '--
• Authorization: Bearer --
• Authorization: Bearer #
• Authorization: Bearer /*
• Authorization: Bearer */
• Authorization: Bearer ' OR '1'='1
• Authorization: Bearer " OR "1"="1
• Authorization: Bearer OR 1=1
• Authorization: Bearer UNION SELECT
• Authorization: Bearer union select
• Authorization: Bearer SELECT FROM
• Authorization: Bearer information_schema
• Authorization: Bearer sqlite_master
• Authorization: Bearer pg_sleep
• Authorization: Bearer SLEEP(
• Authorization: Bearer BENCHMARK(
• Authorization: Bearer WAITFOR DELAY
• sqlalchemy.exc
• sqlite3.OperationalError
• psycopg2.errors.SyntaxError
• psycopg2.errors.UndefinedTable
• pymysql.err.ProgrammingError
• You have an error in your SQL syntax
• syntax error at or near
• unterminated quoted string
• no such column
• no such table
• database query used during proxy API key checks
• LiteLLM

What your security team should do

• Immediately inventory all LiteLLM proxy deployments, including containers, developer-hosted gateways, staging systems, and AI gateway services exposed through reverse proxies.
• Prioritize upgrade to LiteLLM 1.83.7 or later for all affected instances because the issue is CISA KEV-listed, actively exploited, and has a high EPSS score.
• Restrict public access to LiteLLM API routes until patching and validation are complete.
• Rotate LiteLLM API keys, downstream model-provider keys, database credentials, and other secrets stored in or accessible to the proxy if the service was internet-accessible while vulnerable.
• Search web, proxy, WAF, application, and database logs for suspicious Authorization headers, SQL error messages, high volumes of failed authentication, and requests to LLM routes from unfamiliar sources.
• Review database contents for unauthorized API keys, unexpected user/team changes, modified routing settings, or unusual credential access.
• Add temporary WAF or reverse-proxy detections for SQL injection metacharacters and keywords in Authorization headers, while recognizing this is not a substitute for patching.
• Monitor for unauthorized LLM usage, abnormal token consumption, unexpected model calls, and provider billing anomalies after remediation.
• Preserve relevant logs and database snapshots before rotation or cleanup if incident response or legal review may be required.
• Track threat reporting related to ClickFix and FakeCaptcha poisoning campaigns for infrastructure, payload patterns, and post-exploitation behavior associated with LiteLLM targeting.