Your LiteLLM proxy needs to be on 1.83.10 by May 11

CISA put CVE-2026-42208 on the Known Exploited Vulnerabilities catalog this morning with a remediation deadline of May 11. Three days, not the usual fourteen. If you run a LiteLLM proxy anywhere your team can reach the internet, the maintenance window discussion you were planning to have next sprint is happening this weekend instead.

The fix is a one-version bump. Everything after it is the real job.

What changed

LiteLLM v1.83.7-stable shipped April 19 with a one-line class of fix: f-string interpolation in PrismaClient.get_data() got replaced with positional placeholders. The bug was a pre-auth, time-based blind SQL injection in the API-key verification path. Any bearer token that didn’t start with sk- skipped the hashing step and got dropped raw into a Postgres query against LiteLLM_VerificationToken. Reachable through POST /chat/completions. CVSS 9.3 under 4.0, 9.8 under 3.1. Versions 1.81.16 through 1.83.6 are affected. BerriAI is pointing operators at v1.83.10-stable as the current safe baseline.

Sysdig saw the first targeted exploitation on April 26, two days after GHSA-r75f-5x8p-qvmc indexed. The operator knew the schema. They went straight for LiteLLM_VerificationToken, litellm_credentials, and litellm_config WHERE param_name='environment_variables'. That is not opportunistic scanning. That is someone who read the codebase first.

What it means for your environment

If you’ve stood up LiteLLM as the AI gateway for your org, you already know it’s load-bearing in a way most internal services aren’t. One proxy fronts every model contract you have: OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, whatever else. The Postgres backing it holds the master key, every virtual key, and every provider credential. Provider creds are encrypted with NaCl SecretBox, keyed by LITELLM_SALT_KEY. The salt itself is stored in plaintext in LiteLLM_Config. An attacker with read access to litellm_credentials and LiteLLM_Config has the ciphertext and the salt that decrypts it sitting in the same database.

The deployment pattern matters here. Most production LiteLLM is self-hosted Docker or Helm behind a corporate boundary, which is the part operators tell themselves makes it fine. It does not make it fine if the boundary has a public ingress in front of it, and a lot of these proxies do, because that’s how the dev teams hitting them from CI or from a SaaS frontend wanted it.

Check three things before you do anything else:

1. Version. GET /health/readiness or check your image tag. Anything 1.81.16 through 1.83.6 is exposed.
2. Reachability. Was the proxy reachable from the internet at any point after April 24? If yes, the upgrade is not the end of the work. The upgrade is the start.
3. Logs. Hunt POST /chat/completions with Authorization: Bearer values containing UNION SELECT, pg_sleep, information_schema, FROM litellm_verificationtoken, or a trailing --. The observed exploitation came from 65.111.27.132 and 65.111.25.67 (AS200373) with user-agent Python/3.12 aiohttp/3.9.1. LiteLLM’s maintainer also published a pg_stat_statements query covering nine SQLi patterns against the verification table.

What you need to do

Upgrade first. For pip: pip install --upgrade "litellm==1.83.10" and restart. For Docker: ghcr.io/berriai/litellm-database:v1.83.10-stable, no schema migrations. Helm: bump image.tag, helm upgrade, verify with /health/readiness. This is the easy half.

If you genuinely cannot upgrade before May 11, the GHSA advisory points at disable_error_logs: true under general_settings as a stopgap, and Bishop Fox’s WAF guidance is to reject any Authorization: Bearer whose value doesn’t match ^sk-[A-Za-z0-9_-]+$. These are bridges to the upgrade, not substitutes for it.

Then comes the rotation work, and this is the part that’s going to consume your weekend if your proxy was internet-reachable. Treat it as compromised regardless of what the logs say. Rotate in this order:

• LITELLM_MASTER_KEY env var, restart, re-issue all virtual keys.
• All virtual keys via DELETE /key/delete.
• Every upstream provider credential. OpenAI keys at platform.openai.com/api-keys. Anthropic at platform.claude.com/settings/keys. Bedrock through standard IAM rotation, with a CloudTrail audit on InvokeModel.

After rotation, watch the upstream billing dashboards for 24 to 48 hours. Sysdig’s data shows a 376% increase in credential theft targeting AI services from Q4 2025 to Q1 2026, and the resale ecosystem is mature enough now that stolen keys get validated and listed within hours. One 2026 incident hit $82,000 in Gemini charges in 48 hours from a single key. The detection signal you actually want is unexpected spend, not unexpected logins.

A note for the change board conversation: the OpenAI Usage dashboard doesn’t attribute spend per-key when keys share a project. If your virtual key strategy assumed you could pinpoint which key got abused after the fact, that assumption was wrong before this CVE and it’s still wrong after it. Plan the rotation for the whole project, not just the keys you suspect.

The window

Three days is the official window. The real window is shorter, because exploitation has been live since April 26 and the people who built the schema-aware payload aren’t the only ones running it by May 11. If you can patch tonight, patch tonight. If your change process needs an emergency CAB, this is what an emergency CAB is for.

The thing to keep in mind, when this lands in front of your team and someone asks why a one-version bump turned into a weekend of credential rotation, is that the AI gateway category is in the same place reverse proxies were in 2014. One service, every secret, no segmentation between the keys it holds. The patch fixes the SQL injection. It doesn’t fix the architecture that made a SQL injection equivalent to compromising every model provider you pay.

Plan your next LiteLLM change window assuming the SLA is 72 hours, not fourteen days. The 72-hour catalog standard CSO Online reported on isn’t policy yet, but a three-day deadline issued on a Friday is the catalog telling you to pre-stage the rotation runbook now, while this one is fresh. PatchDay Alert will be tracking whether this becomes the new floor.