LiteLLM Privilege Bugs Let Attackers Forge Admin Keys, Expose AI Credentials

A pair of high-severity vulnerabilities in LiteLLM, one of the most widely used gateways for enterprise AI deployments, allows authenticated users to escalate their privileges and generate API keys with unauthorized access—potentially exposing sensitive prompt data and cloud credentials across organizations running GPT-4, Claude, and other large language models.

The flaws, disclosed May 21 as CVE-2025-47101 and CVE-2025-47102, both carry CVSS scores of 8.8 and can be chained together to create a complete privilege escalation pathway. An attacker with low-level access could promote themselves to administrator, then mint API keys granting entry to restricted routes they should never see. The vulnerabilities affect LiteLLM versions prior to 1.83.14 and 1.83.10 respectively, and patches are available.

What makes these bugs particularly concerning isn't their sophistication—it's their simplicity. Both represent fundamental failures in role-based access control, the kind of security 101 mistakes that shouldn't appear in infrastructure handling API keys to nearly every major LLM provider. Yet here they are, in a Python package that serves as critical middleware for enterprise AI operations.

LiteLLM serves as a unified gateway that abstracts away differences between OpenAI, Anthropic, Google, and other AI providers, making it trivial for developers to swap models or route requests across multiple services. That convenience concentrates risk. A single compromised LiteLLM instance can expose keys to dozens of AI services simultaneously, along with the prompt history that might contain proprietary code, customer data, or intellectual property.

CVE-2025-47101 stems from insufficient validation when internal users generate new API keys. The system stores whatever allowedroutes field the user specifies without checking whether those routes align with the user's actual permissions. An internaluser—the lowest privilege tier—can simply request routes reserved for proxy_admin roles, and the system complies.

CVE-2025-47102 operates one level earlier in the attack chain. The /user/update endpoint correctly prevents users from modifying other people's accounts but fails to restrict which fields within their own account they can change. That includes userrole. An attacker can submit a simple API call promoting themselves from internaluser to proxy_admin before proceeding to the key generation exploit.

The attack scenario is straightforward: authenticate with legitimate low-privilege credentials, elevate your role through the update endpoint, generate admin-level API keys, then exfiltrate LLM access tokens and prompt histories. No sophisticated tooling required, no zero-days involved—just predictable API calls exploiting missing authorization checks.

This isn't LiteLLM's first security crisis in recent months. In March, malicious versions 1.82.7 and 1.82.8 appeared on PyPI for approximately 40 minutes as part of a sophisticated supply chain attack attributed to the TeamPCP threat actor. The compromised packages could have exposed credentials across thousands of installations before being pulled. In April, CVE-2025-42208, a critical SQL injection vulnerability with a CVSS score of 9.3, saw exploitation attempts within 36 hours of disclosure, with the first recorded attempt on April 26 at 16:17 UTC.

The pattern suggests AI infrastructure security is struggling to keep pace with AI infrastructure adoption. Organizations racing to deploy LLMs are plugging in middleware that hasn't undergone the security hardening expected of critical systems handling authentication and authorization. We're essentially running 2015-era access control patterns on 2025-era AI workloads.

The vulnerabilities require authenticated access, narrowing the threat model to insider threats or compromised accounts. But in practice, that's not much of a barrier. Contractors, third-party integrations, and overly broad service accounts create numerous pathways to low-privilege authenticated sessions. Once inside, these bugs provide a clean escalation path.

According to CVE advisories published by VulnCheck, organizations running LiteLLM should update immediately to version 1.83.14 or later to address CVE-2025-47101. Security teams should audit existing API keys for routes that exceed the generating user's intended permissions and review user role assignments for unauthorized modifications. Logging around the /user/update endpoint and key generation routes would help detect exploitation attempts.

The disclosure comes at a moment when AI gateway security is drawing increased scrutiny. As LLM deployments move from experimental to production, the middleware connecting applications to AI providers becomes load-bearing infrastructure. A compromise at this layer doesn't just affect one model or one provider—it can expose an organization's entire AI attack surface.

The bigger question is whether we're applying sufficient scrutiny to the growing stack of AI middleware. LiteLLM isn't an outlier—it's representative of an entire category of tools that moved from research projects to production infrastructure faster than their security posture could mature. Basic access control mechanisms that would be table stakes in traditional API gateways are failing in AI proxies handling exponentially more sensitive data.

As these systems become foundational to enterprise AI deployments, the access control basics can't be an afterthought. The race to ship AI features is outpacing the discipline to secure the infrastructure those features run on—and vulnerabilities like CVE-2025-47101 and CVE-2025-47102 are the result.