- OX Security reports that LiteLLM trusts an unverified email claim in login tokens, letting an attacker take over an existing account, including an admin, with one request (CWE-290).
- The proxy holds a company's upstream AI provider keys, so the takeover reaches everything behind it. OX says the flaw was unfixed in LiteLLM 1.100.1.
- Teams should require verified emails at the identity provider, bind accounts to stable subject IDs, and avoid unlinked admin accounts.
A name tag is not an ID card. Anyone can print a name on a sticker. OX Security says many identity providers issue an email claim in a login token before, or without ever, verifying it. LiteLLM, a gateway companies use to manage access to AI models, trusts that claim anyway. OX says the result is an account takeover.
What OX found
According to OX Research, an attacker can hold a genuine signed token for their own identity and still be treated by LiteLLM as a different, existing user. That user can be the proxy administrator. OX classes the flaw as CWE-290, authentication bypass by spoofing. The attacker needs no victim interaction and no stolen password.
The attacker needs a signed token from an identity provider the proxy trusts. That token carries the victim's email address, and the address does not have to be verified. OX says several common identity provider flows produce such tokens without any misconfiguration.
How the flaw works
LiteLLM first tries to match a token to a user by a user ID or SSO ID. SSO is single sign-on, where one trusted provider vouches for the login. A first-time identity always misses that lookup. The proxy then falls back to the email claim in the token.
That fallback trusts the email outright. OX found no check for whether the email is verified, and says the field does not appear anywhere in the relevant file, handle_jwt.py. The fallback is plain case-insensitive matching.
A match does two things. It returns the victim's account as the signed-in caller. It also queues a background write that overwrites the victim's stored SSO ID with the attacker's own. From then on, the attacker's token matches directly. No email trick is needed again.
That is the heart of the problem. A one-time spoofed claim becomes standing access. In OX's proof of concept, the first call ran with full admin context. A follow-up query showed the victim's account permanently rebound to the attacker.
Why the target matters
LiteLLM is an open-source gateway that lets organizations call over 100 AI model APIs through one interface. OX says it sits as the single chokepoint for an organization's AI use. Because of that position, the proxy stores the organization's actual keys for each configured model provider. It also keeps every user's usage and spend records, plus the virtual keys and budgets that control who may call what.
So the admin account is not one more login. It is the key cabinet. The lesson here is that central control points concentrate risk. A gateway that centralises provider keys also gives an attacker one place to collect them. The flaw does not require AI to exploit. It is an old identity mistake in a newer, more valuable place.
Disclosure and status
OX says it reported the issue on May 18, 2026. It followed up on July 27 and received no response. On September 14 it recorded no vendor reply after about 120 days and moved to public disclosure.
This account comes entirely from OX, a security vendor that also promotes its own products in the same post. WebPulse found no response from LiteLLM's maintainers in the source material, so their side is unheard.
OX says the bug is still present, unchanged, in LiteLLM 1.100.1, the current release when it published on September 29. WebPulse has not checked later releases. Check the project's release notes before relying on that. WebPulse has not independently tested the flaw.
OX also scores the issue with a CVSS vector that lists low privileges required and high impact on confidentiality, integrity and availability. The low-privilege entry fits the source's description: the attacker holds an ordinary account at a trusted identity provider.
What to ask your team
OX recommends three controls while no patch exists. First, require a verified email before any token reaches the proxy. Enforce it at the identity provider, or strip the email claim upstream when it is not marked verified. Second, tie accounts to a stable, unique subject ID rather than email. Third, avoid creating admin accounts by email ahead of a first SSO login, since that leaves an unlinked account waiting to be claimed.
OX adds that a domain allowlist helps only against outside domains. It does not stop an attacker in the same domain from claiming a colleague's address. It also says restricting network access limits outside exposure only. Users inside the network can still exploit the flaw.
Four questions to put to your platform and security teams:
Do we run LiteLLM, including copies deployed outside normal processes? Which identity providers does it trust, and do any issue unverified emails or allow self-service signup? Are any admin accounts pre-created by email and not yet linked to a login? If an admin were taken over today, which provider keys would we need to rotate?
The last question is the useful one. An AI gateway is only as trustworthy as the identity claims it accepts. Treat an email address as a label, not a proof.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OX Security.
