← Back to blog AdvisoryHigh

LiteLLM /user/update Self-Promotion to proxy_admin - CVE-2026-47102

Anomity Research Anomity Threat Research · May 21, 2026 · 6 min read

LLM Gateways & Proxies·High·CVE-2026-47102·May 21, 2026

Affected LiteLLM before 1.83.10; fixed in 1.83.10

What happened

CVE-2026-47102 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.10 and carries a CVSS score of 8.8. LiteLLM assigns accounts roles, including org_admin for users who administer a single organization on the gateway and proxy_admin for full control of the whole proxy. The /user/update endpoint lets a user edit their own account record.

The flaw is a missing field-level restriction. /user/update correctly limits a caller to updating only their own account, but it does not restrict which fields may be changed. So a user can set their own user_role to proxy_admin. Users with the org_admin role have legitimate access to this endpoint and can self-promote without chaining any additional flaw. That single call grants full administrative access to LiteLLM, including all users, teams, keys, models, and prompt history. The control checks the row a user may touch but never the columns, and user_role is one of the columns left open.

This is not an injection or a parsing bug. It is an authorization control scoped to the wrong dimension: it bounds which record may be edited but not which fields within it, a mismatch that recurs across the gateway surface covered in the pillar guide on securing LLM gateways and proxies. It was disclosed alongside the related LiteLLM allowed_routes privilege escalation and sits beside the LiteLLM pre-auth SQL injection in the same cluster. The flaw is fixed in LiteLLM 1.83.10 and later, which restricts the fields a user may modify on their own record.

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, exactly the kind of high-capability surface that appears without a security review. CVE-2026-47102 turns a routine delegated role, the org_admin a team lead is given to manage their own organization, into full proxy_admin over that chokepoint with one self-update call.

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 request to /user/update against the caller's own account: 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, not a known-bad binary or a malicious packet.

How Anomity surfaces and governs it

Anomity addresses CVE-2026-47102 in three steps. The lesson is that a request scoped to the right record can still touch the wrong field, and the only reliable place to catch that is at the call itself.

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.10 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 the keys those agents carry, 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 /user/update, user-management paths, or model-configuration endpoints is checked at the call boundary, so a self-promotion request that the gateway would otherwise accept is still governed by your policy rather than by the gateway's incomplete field check. That is precisely the control runtime governance is built to provide: enforcement on the actual call, not on a role the proxy has been tricked into granting, which is the exact gap CVE-2026-47102 leaves open.

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, which accounts held org_admin, and which calls touched user_role, you answer from a record rather than a guess. None of this replaces patching, upgrade to 1.83.10, but it closes the window before and after the fix is deployed, and it complements your Network, EDR, DLP, and GRC tooling.

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.10, which restricts the fields a user may modify on their own record.
Until you are on 1.83.10, treat every account with the org_admin role as capable of self-promoting to proxy_admin via /user/update, and audit who holds those accounts.
Review the user table for accounts whose user_role is proxy_admin but should not be, and reset any that an org_admin could have set on themselves.
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 /user/update and other admin and user-management endpoints are evaluated at the agent hook with allow/deny/log, so the call is governed even when the gateway's field 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 held org_admin and which requests touched user_role.

CVE-2026-47102 is a reminder that scoping a request to the right record is not the same as scoping it to the right fields, and that the place to close that gap reliably is at the call, not in the role a credential carries. Patch to LiteLLM 1.83.10, audit org_admin accounts and any unexpected proxy_admin promotions, and govern admin endpoints at the hook. For the full gateway and proxy attack surface this finding sits within, see the pillar guide on securing LLM gateways and proxies, the co-disclosed LiteLLM allowed_routes privilege escalation, and the sibling 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-47102?

You are exposed if you run any build of LiteLLM before 1.83.10 and hand out accounts with the org_admin role, common for team leads who manage their own organization on the gateway. The /user/update endpoint correctly limits a user to editing only their own record, but it does not restrict which fields they may change. An org_admin can call it against their own account and set user_role to proxy_admin, gaining full administrative control with no second flaw to chain. The fix landed in LiteLLM 1.83.10, which restricts the fields a user may modify. 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-47102 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 org_admin account that already has legitimate access to /user/update, so a single over-shared or compromised account is enough.

Why did LiteLLM's role-based access control fail to stop this?

The access check on /user/update was scoped to the wrong dimension. It correctly verified the row, an org_admin may only update their own account, but it never validated the columns, so any field on that record was fair game, including user_role. Restricting which row a user may edit means nothing if the user can promote that same row to proxy_admin. It is the same shape of mismatch seen across the gateway surface, a control applied along one axis and forgotten along another, as in the sibling allowed_routes escalation. The 1.83.10 fix closes it by restricting the fields a user may modify on their own record, keeping privileged fields like user_role out of reach.

How does Anomity help with CVE-2026-47102?

Anomity inventories LLM gateways and proxies across every managed endpoint and surfaces the installed version, so finding every LiteLLM instance before 1.83.10 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 the /user/update endpoint or other admin paths 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.