No patch yet for a LiteLLM flaw that turns any valid login token into an admin account

A flaw in LiteLLM's JSON Web Token login lets anyone who holds a validly signed token from your identity provider sign in as a different LiteLLM user — including an administrator whose dashboard exposes the gateway's stored API keys. Tracked as CVE-2026-93355, it affects every release up to and including 1.102.1, and as of October 3, 2026 there is no vendor advisory and no confirmed patch. If you run LiteLLM's proxy with an external identity provider, the fix available to you today is configuration: stop identifying users by their email claim.

What happened, in plain English

LiteLLM is an open-source AI gateway: a proxy that sits between your applications and the many large language model (LLM) providers behind them, so developers call one endpoint instead of a dozen. Because it brokers all that traffic, it also stores the organisation's provider API keys, its user list and its spend limits. That makes its admin account unusually valuable.

Rather than manage a second set of logins, many organisations point LiteLLM at their existing identity provider (IdP) — Okta, Entra ID, Keycloak, Auth0 — using JSON Web Tokens (JWTs). A JWT is a small, cryptographically signed packet of claims ("this is user 7a3f, their email is ana@example.com, they are in the engineering group"). The signature proves the IdP issued it and that nobody altered it in transit. It does not prove the claims inside are true.

That distinction is where the bug lives. LiteLLM takes the claim you nominate in user_id_jwt_field and uses it to find — or create — the matching user in its database. According to the advisory from OX Security, when that direct lookup misses, the authentication flow quietly falls back to matching on the token's email claim instead, and it does not check the companion email_verified claim that tells it whether the IdP ever confirmed that the person owns that mailbox.

So if an attacker can obtain any validly signed token from the trusted IdP while controlling what goes in its email field, they can put a victim's email address there. LiteLLM finds the victim's account, and the session inherits that account's role — up to proxy_admin. Think of a building where the card reader checks that your badge was printed by the real badge office, then opens whichever door matches the name you wrote on it in biro.

Are you affected? What to do now

Most LiteLLM deployments are not exposed: the flaw requires JWT authentication against an external IdP. If you authenticate only with virtual keys or the master key, it does not apply to you. And note the name: LiteLLM, the AI gateway, is unrelated to LightLLM, the inference server with its own set of unpatched advisories.

Check whether this applies

• Open your proxy config.yaml and look for enable_jwt_auth: True under general_settings, and for a JWT_PUBLIC_KEY_URL environment variable. If neither is set, you do not have JWT auth and this issue does not reach you.
• Check your installed version with pip show litellm, or read the image tag on your ghcr.io/berriai/litellm container. VulnCheck lists everything through 1.102.1 as affected. (OX Security's write-up says "through 1.100.1"; the two do not agree, so treat 1.102.1 as the floor.)
• In the litellm_jwtauth block, look at which claim you map users from. If user_id_jwt_field is set to email — or is unset while your tokens carry an email — you are relying on exactly the claim this flaw abuses.
• Check whether user_id_upsert is on. If it is, LiteLLM will create accounts from tokens it has not seen before, which widens who can get a foothold.
• Work out who can get a token from your IdP at all. If that IdP allows self-service sign-up, or issues tokens to guest and B2B tenants, the pool of people who could try this is much larger than your staff list.

What to do, in order

• Set user_id_jwt_field to a stable, opaque subject identifier from your IdP — the sub claim or an immutable object ID — not an email address. Emails get reassigned and, crucially, are often self-asserted.
• Make your IdP refuse to issue tokens for unverified email addresses, or strip the email claim from tokens destined for the gateway. This is the control that actually closes the fallback — and it has to be done at the IdP, because LiteLLM's documented configuration has no email-verification switch of its own.
• Add user_allowed_email_domain as defence in depth, so tokens carrying addresses outside your own domains are rejected outright.
• Put the proxy on an internal network. LiteLLM's admin endpoints should not be reachable from the public internet; the OX write-up recommends restricting it to internal VPC/VNet traffic.
• Do not pre-create privileged accounts keyed on an email address alone; bind an admin account to a confirmed subject identifier first.
• Review who currently holds proxy_admin, and rotate the provider API keys stored in the gateway if you find accounts or identity bindings you cannot account for.
• If you upgrade, 1.103.2 is the current release (October 1, 2026) — but do not assume upgrading alone fixes this; see below.

No indicators of compromise have been published by any official source, and there are no reports of exploitation. EPSS, which estimates the probability of exploitation in the wild, scored it 0.27% at the time of writing.

The expert view

The root cause is a familiar anti-pattern: treating a signed token as an authenticated identity rather than as a set of claims of varying trustworthiness. The signature is the only thing the gateway verifies cryptographically; everything inside is only as good as the IdP's own assurance process, and email_verified exists precisely to carry that assurance. Ignoring it while using email as a lookup key collapses two different trust levels into one — and because LiteLLM's documented JWT settings expose no email-verification option, an operator cannot restore that distinction from the gateway side at all. OX Security classifies it as CWE-290, authentication bypass by spoofing; VulnCheck files it as CWE-1390, weak authentication. Both descriptions fit — it is a spoofable identifier used as an authenticator.

The chain is short: obtain a legitimately signed token from the trusted issuer whose email claim names the target, let the lookup miss on the primary identifier, and let the fallback resolve to the target's account. The persistence angle matters most. Because the flow can overwrite stored identity bindings, a successful impersonation need not be a one-off session — it can rewrite which external identity a privileged local account maps to. That turns an authentication bug into a durable access problem, which is why rotating the gateway's provider keys belongs on the checklist rather than just forcing a re-login.

The defences failed in a predictable order. The IdP did its job and signed a token. LiteLLM verified the signature and then did something helpful: if we cannot find this person by ID, perhaps we know them by email. That fallback looks harmless in a single-tenant pilot and becomes a privilege boundary in production — the same shape as the MLflow and Obot MCP gateway issues we covered on September 29, where a default tuned for a developer's laptop survived into deployment.

Severity scoring is split. VulnCheck gives CVSS 4.0 of 7.6, OX Security gives CVSS 3.1 of 8.8, and at least one aggregator lists 8.1 — the gap largely reflects how each framework treats the attacker needing a valid token to begin with. Our reading is that the published numbers overstate the barrier: the privilege required is "any user your IdP will issue a token to", which in a tenant with self-service sign-up is close to none, and the prize is a credential store, not a single account.

What remains unknown is the most important part. OX's published timeline shows the issue reported to the vendor on May 18, 2026, a follow-up on July 27, 2026, and public disclosure on September 14, 2026 after roughly 120 days without a response; the CVE record was published September 28, 2026. There is no GitHub Security Advisory for CVE-2026-93355 in the GitHub Advisory Database, which carries twelve other LiteLLM advisories, and the OSV record still lists only a last-affected version, with no fixed one. LiteLLM shipped 1.103.0 and 1.103.1 on September 29, 2026, and the 1.103.0 release notes do describe gateway hardening — including per-issuer JWT key scoping and RFC 8693 token exchange for IdP JWTs — but say nothing about the email fallback or the email_verified claim. A 1.103.2 release followed on October 1, 2026; its notes list backported proxy fixes without describing them and do not mention JWT, the email fallback or this CVE. So whether the current release still contains the fallback is not confirmed either way. Until the vendor says so, treat the configuration changes above as the remediation and the upgrade as unrelated hygiene.

Official sources

• VulnCheck advisory — LiteLLM Weak JWT Authentication via Email-Based User Lookup (CVE-2026-93355)
• OX Security research — "An ordinary login token can become someone else's admin account" (Nir Zadok, Moshe Siman Tov Bustan)
• OSV record for CVE-2026-93355 — affected version ranges
• CVE-2026-93355 — CVE Program record
• LiteLLM documentation — JWT-based Auth configuration
• LiteLLM v1.103.0 release notes — gateway hardening
• LiteLLM v1.103.2 release
• litellm on PyPI — current release and date
• GitHub Advisory Database — existing LiteLLM advisories
• Coverage: nixpkgs security tracking issue #568147