LiteLLM allowed_routes Privilege Escalation via Key Creation - CVE-2026-47101
What happened
CVE-2026-47101 (also tracked as GHSA-qrc4-49gv-mv9m) is a privilege escalation in LiteLLM, the open-source LLM gateway and proxy that fronts many model providers behind one API and brokers agent traffic for the org. It affects all builds before 1.83.14 and carries a CVSS score of 8.8. LiteLLM assigns accounts roles - internal_user for ordinary teams, proxy_admin for full control - and lets an internal_user generate API keys, each scoped by an allowed_routes field listing the proxy routes the key may reach.
The flaw is at key creation. When an authenticated internal_user generates a key, the allowed_routes field is stored without verifying that the requested routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request - the later request satisfies the role check the key now carries. This allows full escalation from internal_user to proxy_admin, granting control over all users, teams, keys, models, and prompt history. Exploitation requires only an authenticated account with the internal_user role.
This is not an injection or a parsing bug. It is an authorization control enforced on the request path but omitted at key issuance - a mismatch between what a credential is granted and what should have been allowed that recurs across the surface covered in the pillar guide on securing LLM gateways and proxies, and a close cousin of the LiteLLM pre-auth SQL injection. The flaw is fixed in LiteLLM 1.83.14 and later, which validates that key route grants stay within the creator's permissions.
Why this is an agentic-endpoint risk
An LLM gateway is not a passive dependency. It is the chokepoint every AI agent and MCP server in the org routes model calls through, holding the keys to every provider and a running record of every prompt. LiteLLM is frequently stood up bottom-up by an application team to centralize model access and budget - the kind of high-capability surface that appears without a security review. CVE-2026-47101 turns the lowest privilege the gateway hands out, a developer's internal_user account, into full proxy_admin over that chokepoint.
The exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The malicious step is an ordinary authenticated key-creation call followed by ordinary authenticated requests: EDR sees a legitimate process, the network sees normal API traffic to your own gateway, and DLP sees nothing leave the perimeter. LLM gateways and the keys, agents, and MCP servers around them are among the eight AI artifact types adopted without review and reporting to no security tool - the same dynamic that makes AI agents and MCP servers the new shadow IT. This is the artifact layer traditional controls were never built to see: the danger is a role boundary crossed inside an application's own auth model. You cannot tell which gateways are exposed, who minted which key, or what those keys reached, without an inventory of the artifact layer and a record of every call.
How Anomity surfaces and governs it
Anomity addresses CVE-2026-47101 in three steps, and the structure matters because an issued credential's stored grant and the permission that should have backed it can diverge - and the only reliable place to close that gap is at the call.
First, inventory. Anomity inventories every LLM gateway and proxy on every managed endpoint as part of the eight AI artifact types it tracks, surfacing the exact version of LiteLLM in use so finding everything before 1.83.14 is a single query rather than a fleet sweep. It captures the surrounding metadata - the agents and MCP servers configured to route through each gateway - and classifies each gateway by the capability it brokers. Metadata only: secret values are redacted on the endpoint before anything leaves it.
Second, decide at the hook. On agents that expose a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. An agent reaching admin-only proxy routes, key-management endpoints, or model-configuration paths is checked at the call boundary, so a request that an escalated key would satisfy is still governed by your policy rather than by the gateway's compromised role check. That is the control runtime governance is built to provide: enforcement on the actual call, not on a credential the proxy has been tricked into trusting.
Third, keep the record. Every decision, and every added, changed, or removed gateway, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When responders ask which gateways ran a vulnerable build and what admin routes were reached, you answer from a record rather than a guess. None of this replaces patching - upgrade to 1.83.14 - but it closes the window before and after the fix is deployed, and it complements your Network, EDR, DLP, and GRC tooling by covering the layer those tools were never built to inventory.
You can't govern what you can't see.The Anomity principle
What to check across your fleet
- Inventory every endpoint, container image, and CI runner for LiteLLM and record its version; upgrade anything
before 1.83.14. - Until you are on 1.83.14, treat every internal_user account as capable of escalating to proxy_admin, and audit who holds those accounts.
- Review existing keys for allowed_routes that include admin-only routes the creator should never have reached, and rotate any that do not match the holder's role.
- Rotate provider credentials and review prompt-history access on any gateway that ran a vulnerable build, since proxy_admin exposes all keys and stored prompts.
- Confirm agent calls to admin-only proxy routes and key-management endpoints are evaluated at the agent hook with allow/deny/log, so the call is governed even when the gateway's role check is not.
- Verify every gateway change and governed call is written to a 90-day audit trail and routed to your SIEM, so you can reconstruct who minted which key and what it reached.
CVE-2026-47101 is a reminder that a gateway's stored authorization and the permission that should have backed it can diverge, and that the place to close that gap reliably is at the call, not in the credential. Patch to LiteLLM 1.83.14, audit existing keys and internal_user accounts, and govern admin-only routes at the hook. For the full gateway and proxy attack surface, see the pillar guide on securing LLM gateways and proxies, and the sibling advisory on the LiteLLM pre-auth SQL injection. To see Anomity inventory and govern the gateway layer across your fleet, request early access.
Frequently asked questions
Am I affected by CVE-2026-47101?
You are exposed if you run any build of LiteLLM before 1.83.14 and hand out accounts with the internal_user role - the common role for teams and developers who mint their own API keys. Any authenticated internal_user can create a key whose allowed_routes include admin-only routes and then use it to reach them, escalating to proxy_admin. No misconfiguration on your part is required; the role-based check that should block the grant is simply not applied at key creation. The fix landed in 1.83.14, which validates that a key's route grants stay within the creator's permissions. The first step is knowing which hosts run the proxy and what version each is on, which needs an inventory of the AI artifact layer.
What can an attacker do once they reach proxy_admin?
CVE-2026-47101 carries a CVSS score of 8.8 and grants full administrative control of the LiteLLM proxy. As proxy_admin an attacker can manage all users, teams, and keys - creating, rotating, or revoking credentials for anyone on the gateway - and can change which models are exposed and how. They also gain access to prompt history, which on a busy gateway routinely contains source code, customer data, and secrets that passed through requests. Because the gateway brokers every model call for the org, control of it is control of the whole agent traffic plane. Exploitation needs only one authenticated internal_user account, so an over-shared developer key or a single compromised account is enough.
Why did LiteLLM's role-based access control fail to stop this?
The role-based access controls were enforced on the request path: a call to an admin-only route is checked against the caller's role and blocked when the role is too low. The gap is at key creation. When an internal_user generates a key, the allowed_routes field is stored without verifying that the requested routes fall within the user's permissions. The key is then treated as legitimately authorized for those routes, so later requests pass the role check the key now satisfies. It is the same class of mismatch seen across the gateway surface - a control applied in one code path and forgotten in another. The 1.83.14 fix validates route grants against the creator's permissions before the key is issued.
How does Anomity help with CVE-2026-47101?
Anomity inventories LLM gateways and proxies across every managed endpoint and surfaces the installed version, so finding every LiteLLM instance before 1.83.14 is one query rather than a fleet sweep. On agents that expose a hook, it evaluates each tool call against your policy and returns allow, deny, or log before the call runs, so an agent reaching admin-only proxy routes or key-management endpoints is checked at the call boundary. Every install, version change, and decision lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. Anomity collects metadata only, with secret redaction on the endpoint, and complements - not replaces - your Network, EDR, DLP, and GRC tooling.