Your AI Gateway Is Holding All the Keys
The LiteLLM vulnerability chain is not just another proxy bug. AI gateways sit between users, models, provider keys, stored credentials, and prompt logs. Treat them like production security infrastructure.
The uncomfortable part of the LiteLLM bug is not that a proxy had vulnerabilities. Proxies have bugs. The uncomfortable part is what we have started putting behind them.
LiteLLM is an open-source gateway that gives teams one OpenAI-compatible interface for more than 100 model providers. That is useful. It also means the gateway can become the place where provider API keys, routing rules, access policies, stored credentials, and prompt traffic all meet.
According to The Hacker News, researchers at Obsidian Security disclosed a three-CVE chain where a low-privilege internal user on a LiteLLM proxy could escalate to admin and reach server-side code execution. Obsidian rated the full chain CVSS 9.9. The fix landed in v1.83.14-stable, which GitHub lists as published on May 2.
If you run LiteLLM, this is patch-now territory. But the larger lesson applies to every AI gateway, agent router, model proxy, and internal "one API for all models" service people are standing up in a hurry.
The gateway is not plumbing
Teams like gateways because they make model access manageable. One endpoint. One billing layer. One auth story. One place to swap providers without rewriting half the app.
That is exactly why the gateway matters.
If it only forwarded toy prompts to a public demo model, fine. Most production gateways do more than that. They often hold provider keys for OpenAI, Anthropic, Google, Mistral, local inference clusters, or internal fine-tuned models. They may enforce budgets, user permissions, content filters, logging rules, audit policies, and model allowlists. Some sit next to MCP tools or agent frameworks that can touch files, tickets, cloud APIs, or customer data.
So when a gateway falls over, the blast radius is not "someone can call the model for free." It can be:
- provider API keys leaked or abused;
- tenant prompts and responses exposed;
- stored credentials decrypted;
- model routing policies bypassed;
- internal tools reached through agent integrations;
- logs turned into a privacy incident.
That is production security infrastructure. Treating it like a convenience wrapper is how you get surprised.
Low privilege is still privilege
The first bug in the reported chain, CVE-2026-47101, involved authorization around virtual API keys. The short version: a regular internal user could supply an allowed_routes value when creating a key, and the proxy treated that value too generously. From there, the chain moved toward admin control and code execution.
That should make people twitchy for a boring reason. AI platforms are full of semi-trusted users.
A developer gets access so they can test a model. A contractor gets access for one project. A product team gets access through a shared workspace. A staging service gets a token. Someone creates a "temporary" virtual key for an experiment and forgets it exists.
In normal app security, we already know this pattern. Internal users are not magic. They are compromised laptops, phished accounts, stale contractors, overbroad tokens, and confused permission models. AI stacks do not get an exemption because the endpoint says /chat/completions.
If a low-privilege AI user can mint stronger keys, change routes, or reach admin-only endpoints, the trust boundary is already broken.
MCP makes this sharper
The Hacker News report notes that LiteLLM has had other rough edges this year, including a flaw in MCP preview endpoints that CISA added to the KEV catalog earlier in June.
That matters because MCP-style integrations change what a model-facing server can do. A plain chat gateway leaks text and keys when it fails. A tool-connected gateway may also become a path into files, databases, CI systems, browsers, cloud consoles, ticketing systems, or whatever else the agent can reach.
This is why I dislike the phrase "AI plumbing." Plumbing sounds boring and passive. These systems are closer to dispatchers. They decide which model gets called, which user is allowed, which tool is exposed, which secret is used, and which response gets logged.
A dispatcher with weak auth is not plumbing. It is a control plane with vibes.
What I would check today
If LiteLLM is in your stack, upgrade to v1.83.14-stable or later. Then do the less satisfying work.
Review who can create virtual keys, especially internal users and service accounts. Look for keys with routes or scopes that do not match the user who created them. Rotate provider keys if the gateway was reachable by people or services you would not fully trust with those keys directly.
Check logs for admin route access, new virtual keys, changed model routes, unusual MCP/tool calls, and unexpected subprocess execution. If the gateway stores encrypted credentials, verify where the encryption keys live and who can read them. If the same host can decrypt secrets and run arbitrary code, assume code execution means secret exposure.
Then look at architecture:
- Put the gateway behind real identity, not just a shared bearer token.
- Separate admin routes from ordinary inference traffic.
- Scope provider keys by environment, project, and model where the provider allows it.
- Keep tool access off by default and bind it to specific users or workloads.
- Log security-relevant changes without dumping sensitive prompt contents everywhere.
- Treat prompt and response logs as user data, not harmless telemetry.
None of this is exotic. It is ordinary web security, secret management, and least privilege. The difference is that AI teams are often building the gateway before the governance has caught up.
The boring rule
Do not put more trust into an AI gateway than you are willing to defend.
If it holds all your model keys, it deserves the controls you would put around a payment processor credential service. If it can call internal tools, it deserves the controls you would put around an admin console. If it logs prompts, it deserves the controls you would put around sensitive customer data.
The model is not the only new risk in the AI stack. The glue code is getting powerful too.
And glue code, historically, is where everyone gets lazy.