Why this one matters
LiteLLM sits in an uncomfortable place. It is often the small proxy between internal applications and paid model providers. That makes CVE-2026-42208 more than a normal web bug. If the proxy was reachable from an untrusted network, the useful question is not whether someone could log in. The vulnerable path runs before authentication.
The GitHub advisory describes a SQL injection flaw in LiteLLM Proxy API key verification. A caller supplied value from the Authorization: Bearer header reached a database query as query text rather than as a separate parameter. The affected package range is >=1.81.16, <1.83.7; LiteLLM fixed the issue in 1.83.7 and now recommends 1.83.10-stable.
Sysdig reported targeted exploitation attempts 36 hours and 7 minutes after the advisory entered the global GitHub Advisory Database. The attempt they documented was not broad scanner noise. It used UNION payloads aimed at LiteLLM table names such as LiteLLM_VerificationToken, litellm_credentials, and litellm_config. That matters because those tables are where a proxy deployment may hold virtual API keys, upstream provider credentials, webhooks, and configuration secrets.
This is T1190, Exploit Public-Facing Application, but the operational work looks like credential incident response.
Patch, then assume the past still happened
Upgrading closes the known vulnerable path. It does not prove the database was not read yesterday.
For exposed LiteLLM proxies, make the first pass boring and mechanical:
- Find every LiteLLM Proxy instance, including test stacks, internal demos, and shared engineering gateways.
- Check the running version and upgrade anything in the affected range to
1.83.7or later, preferably1.83.10-stable. - If an immediate upgrade is blocked, apply the documented workaround by setting
general_settings.disable_error_logs: trueuntil the upgrade is complete. - Restrict the proxy to trusted networks. A model gateway should not be world reachable unless there is a very specific business reason.
- Preserve database and reverse-proxy logs before rotation work overwrites useful evidence.
The workaround is not a replacement for patching. It removes the path described in the advisory, but it does not cover every future bug in a service that brokers expensive provider access.
What to rotate
The safest response is to treat a reachable vulnerable proxy as a secrets exposure until logs show otherwise. Start with the credentials LiteLLM can actually use.
Rotate LiteLLM virtual keys first. If an attacker extracted a virtual key, they may be able to call the proxy even after the SQL injection is patched. Revoke old keys rather than leaving them valid during a long grace period.
Next, rotate upstream provider credentials stored behind the proxy. That usually means OpenAI, Anthropic, Bedrock, Azure OpenAI, or other provider tokens depending on the deployment. Do not stop at the provider named in the most visible application. LiteLLM's value is routing; one proxy can hold credentials for several backends.
Then check supporting secrets. Sysdig's write-up calls out possible access to proxy environment values, PostgreSQL DSNs, webhook URLs, and cache configuration. If the LiteLLM database stored those values, include them in the rotation list.
Finally, review billing and usage. Provider-side logs can show whether stolen keys were used after the suspected window. Look for unusual model choices, unfamiliar source networks, large completions, strange time-of-day patterns, and failed calls immediately before successful ones. Failed calls often show attackers testing what a key can do.
What to hunt for
The advisory gives defenders a concrete trigger point: malicious Authorization: Bearer values sent to LLM API routes such as POST /chat/completions.
In reverse-proxy and application logs, search for bearer headers or authentication errors containing SQL syntax. Useful strings include single quotes in token values, UNION SELECT, information_schema, table names from the Sysdig report, and repeated requests to normal LLM routes with malformed credentials.
On PostgreSQL, use LiteLLM's query-history helper if query logging was enabled. If it was not enabled, do not pretend there is certainty. Fall back to proxy logs, provider audit logs, database connection logs, and any EDR telemetry on the host.
Treat hits against LiteLLM_VerificationToken, litellm_credentials, or litellm_config as high value. A blocked or failed query still proves targeting. A successful query may not leave a clean application-level error.
Boundary for this guide
This post does not embed a CloudSigma rule. The current public signal is strong enough for a practical guide, but the useful detection is environment-specific: HTTP edge logs, LiteLLM application logs, PostgreSQL query history, and provider billing trails. A single portable Sigma rule would either miss too much or promise too much.
For now, the control is straightforward. Patch LiteLLM, restrict exposure, rotate the keys the proxy could reach, and verify provider usage after the likely exploitation window. If that sounds heavy for a proxy, that is the point. A gateway that holds model-provider credentials is part of the secrets estate, not a harmless developer convenience.