LiteLLM Vulnerability Chain Turns AI Gateways Into a Control Plane Risk

LiteLLM’s recent security history is no longer a normal “Python package has a CVE” story. The more important lesson is that an AI gateway can become a credential vault, an authorization broker, a prompt-processing chokepoint, an MCP execution surface, and a man-in-the-middle position between agents and models.

The latest attention came from Obsidian Security’s June 2026 disclosure of three chained LiteLLM vulnerabilities: CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217. Obsidian described the chain as a CVSS 9.9 path from a default low-privilege user to administrator access and remote code execution on the LiteLLM server. The same research also demonstrated a more AI-native consequence: once the gateway is compromised, an attacker may be able to rewrite model responses and steer downstream agents, including coding agents, toward attacker-chosen tool calls. (Obsidian Security)

A separate LiteLLM flaw, CVE-2026-42271, has also been widely discussed because CISA added it to the Known Exploited Vulnerabilities catalog in June 2026. That vulnerability is not part of the Obsidian CVSS 9.9 chain. It is an MCP command injection issue in LiteLLM test endpoints that affected versions 1.74.2 through versions before 1.83.7, according to NVD. The overlap is architectural rather than numerical: both stories show that AI gateways are now execution-bearing infrastructure, not passive request routers. (NVD)

The distinction matters. If defenders collapse every LiteLLM headline into one vague “RCE” issue, they will miss what to patch, what to rotate, what to investigate, and which trust boundary failed.

The facts that should not be mixed together

The current LiteLLM discussion includes multiple related but distinct events. The table below separates the major ones.

Event	Type	Main attack condition	Main risk	Fixed or mitigated in	Part of Obsidian CVSS 9.9 chain	CISA KEV
CVE-2026-47101	Authorization bypass	Authenticated low-privilege internal_user can create or update a virtual key with unauthorized allowed_routes	Route-level authorization bypass leading toward admin-only endpoints	Full chain fixed in LiteLLM v1.83.14-stable or later per Obsidian	Yes	No public KEV listing found
CVE-2026-47102	Privilege escalation	User can reach /user/update or /user/bulk_update and modify security-sensitive fields	Self-promotion to proxy_admin, full access to users, teams, keys, models, and prompt history	LiteLLM prior to 1.83.10 affected per NVD and GitHub advisory	Yes	No public KEV listing found
CVE-2026-40217	Custom-code guardrail sandbox escape	Attacker can reach custom-code guardrail compile or test path	Server-side code execution through unsafe Python sandbox behavior	Guardrail fixes shipped across April releases, with full chain closed by v1.83.14-stable per Obsidian	Yes	No public KEV listing found
CVE-2026-42271	MCP command injection	Authenticated user can reach MCP preview endpoints in affected versions	Arbitrary host command execution as the LiteLLM proxy process	Patched in 1.83.7 per NVD	No	Yes
CVE-2026-42208	Pre-auth SQL injection	Unauthenticated request reaches vulnerable API key verification path	Database access, possible exposure of virtual keys and provider credentials depending on deployment	Fixed in 1.83.7; LiteLLM recommended 1.83.10-stable	No	Not listed in KEV at the time Sysdig wrote about it
March 2026 PyPI compromise	Supply chain compromise	Installation of malicious litellm==1.82.7 or 1.82.8 from PyPI during the affected window	Credential theft from developer, CI, proxy, and cloud environments	Malicious packages removed; LiteLLM released v1.83.0 through CI/CD v2	No	No

LiteLLM’s official documentation describes the project as a self-hosted AI gateway and OpenAI-compatible proxy for platform teams managing LLM access across an organization. Its documented gateway capabilities include virtual keys, budgets, centralized logging, guardrails, caching, admin UI, agent and MCP gateway features, and support for more than 100 model providers. (LiteLLM)

That is why the blast radius is different from a bug in an ordinary library. If a vulnerable LiteLLM deployment is reachable, the attacker may not be chasing a single application database. The attacker may be standing at the point where model access, budgets, provider keys, prompt data, guardrails, and agent tooling converge.

Why AI gateways are a different kind of target

A traditional API gateway routes traffic, enforces authentication, applies rate limits, and records telemetry. An AI gateway does that, but it often adds several security-sensitive functions that are specific to AI systems.

It may hold upstream provider credentials. It may issue virtual API keys to teams. It may enforce model access. It may log prompts and responses for observability. It may execute guardrail logic. It may route calls to external tools or MCP servers. It may proxy coding-agent traffic. It may sit between a developer’s local agent and the remote model. A compromise of that gateway can therefore become a compromise of both the credential plane and the agent control plane.

LiteLLM’s own docs show this concentration clearly. Its virtual key documentation describes a database-backed proxy setup, a master key used as the proxy admin key, and key-management APIs such as /key/generate. The spend tracking documentation describes cost tracking across keys, users, and teams, with tracking stored in LiteLLM database tables. (LiteLLM)

Obsidian’s disclosure makes the same point in security terms. It states that a successful chain can reach host-level secrets such as LITELLM_MASTER_KEY, LITELLM_SALT_KEY, and DATABASE_URL, as well as LLM provider credentials for OpenAI, Anthropic, Gemini, Bedrock, Azure, and other configured providers. Obsidian also notes that prompts and responses can be visible to a compromised gateway. (Obsidian Security)

The value of the target explains the speed and precision of follow-on exploitation activity seen in the earlier SQL injection incident. Sysdig reported that exploitation attempts against CVE-2026-42208 appeared 36 hours and seven minutes after the advisory was indexed in the global GitHub Advisory Database. Sysdig also observed that the traffic was not generic SQLMap noise; it targeted high-value LiteLLM schema areas, including virtual API keys, stored provider credentials, and proxy environment-variable configuration. (Sysdig)

In other words, attackers already understand what defenders sometimes understate: the AI gateway is where the keys are.

The 2026 LiteLLM timeline

The LiteLLM vulnerability chain makes more sense when placed next to the earlier LiteLLM events from the same period.

Date	Event	Security meaning
March 24, 2026	LiteLLM disclosed a suspected supply chain incident involving unauthorized PyPI package publishes for litellm==1.82.7 and 1.82.8. LiteLLM said the packages were live for about 40 minutes before PyPI quarantined them.	The release channel became the attack path. Compromising a package used in AI and CI environments can expose secrets without attacking a running server directly.
March 30, 2026	LiteLLM announced CI/CD v2, including isolated environments, separation of validation and release, Trusted Publishing for PyPI, immutable Docker release tags, and Docker image signing.	The response focused on hardening the release pipeline and reducing long-lived publishing credentials.
April 2026	LiteLLM disclosed CVE-2026-42208, a SQL injection in the proxy API key verification path, affecting v1.81.16 through v1.83.6, fixed in v1.83.7, with v1.83.10-stable recommended.	The authentication path itself became an unauthenticated database access path under certain conditions.
April 2026	Sysdig observed targeted exploitation attempts against CVE-2026-42208 about 36 hours after the advisory reached broad vulnerability feeds.	Attackers were not merely scanning. They appeared to understand LiteLLM’s database schema and where valuable secrets lived.
May 2026	CVE-2026-42271 was published in NVD as an MCP test endpoint command injection issue affecting 1.74.2 through versions before 1.83.7.	MCP preview functionality turned a configuration test path into host command execution for authenticated users.
June 8, 2026	CISA added CVE-2026-42271 to the KEV catalog, citing active exploitation.	Defenders should treat the issue as operationally urgent, not theoretical.
June 11, 2026	Obsidian published the CVSS 9.9 chain involving CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217.	A low-privilege LiteLLM user could move through route bypass, role escalation, and code execution.

LiteLLM’s March supply chain incident also explains why many security issues surfaced close together. LiteLLM later said that after the March incident it brought in Veria Labs to audit the proxy, fixed multiple vulnerability reports, launched a bug bounty program, and continued shipping fixes. (LiteLLM)

That does not make the vulnerabilities less serious. It does make the pattern easier to interpret. A popular AI gateway became important enough to attract supply chain attackers, security researchers, bug bounty reporters, opportunistic exploiters, and enterprise defenders at the same time.

CVE-2026-47101, when route constraints became route grants

The first vulnerability in Obsidian’s chain, CVE-2026-47101, is an authorization bypass involving allowed_routes.

LiteLLM has users, teams, organizations, and virtual keys. Users can have global roles, membership roles, and keys. A virtual key authenticates the caller and may carry route restrictions. In a safe design, route restrictions should only narrow what a key can do. They should never grant access beyond the owner’s role. Obsidian found that LiteLLM’s handling of allowed_routes violated that expectation. (Obsidian Security)

The core flaw was that key-management endpoints such as /key/generate, /key/update, /key/regenerate, and /key/service-account/generate could persist user-supplied allowed_routes without confirming that those routes fell within the caller’s actual permissions. Obsidian reported that a default internal_user could mint a key with routes beyond what the role should allow, including routes that lead into admin functionality. (Obsidian Security)

NVD describes CVE-2026-47101 similarly: LiteLLM prior to 1.83.14 allowed an authenticated internal_user to create API keys with access to routes their role did not permit, enabling escalation from internal_user to proxy_admin when combined with the affected routes. (NVD)

The engineering lesson is simple but often missed: a field named like a restriction can still become a grant if it is trusted in the wrong authorization layer.

A safer design would treat route allowlists as an intersection, not a union:

def validate_requested_routes(user_role, requested_routes):
    role_routes = routes_allowed_for_role(user_role)

    for route in requested_routes:
        if route not in role_routes and not is_safe_prefix_match(route, role_routes):
            raise PermissionError("requested route exceeds caller role")

    return requested_routes

That code is intentionally simplified. Real systems need canonical route normalization, wildcard handling, method-level checks, and protection against prefix ambiguity. The important point is the invariant: user-controlled scope may reduce access, not expand it.

A defensive review should ask four questions:

Review question	Why it matters
Can a low-privilege user create or update a virtual key?	Key generation can become privilege generation if fields are not constrained.
Can the user set allowed_routes, wildcard routes, model access, team ownership, or metadata that affects policy?	Security-sensitive fields often hide in “configuration” APIs.
Does the route gate consult user-controlled key state as a fallback grant?	A fallback grant can invert the authorization model.
Are all key writers patched, not just the easiest endpoint?	Obsidian noted the same unchecked write pattern appeared across multiple key-write handlers.

The practical failure is not unique to LiteLLM. Many internal platforms let users create API tokens, service accounts, webhooks, or automation keys. The security property should always be explicit: token scopes must be a subset of the creator’s authority at creation time, and the token’s future use must still be evaluated against current policy when appropriate.

CVE-2026-47102, object checks are not field checks

CVE-2026-47102 is the second major authorization failure in the Obsidian chain. It involves user update endpoints and field-level authorization.

According to Obsidian, /user/update allowed a user to update their own record, but did not restrict which fields a non-admin could modify. The request body passed through without filtering, and user_role could be written directly to the database. A self-update setting user_role to proxy_admin could therefore promote the caller. Obsidian also reported that the same flaw existed on /user/bulk_update. (Obsidian Security)

NVD describes CVE-2026-47102 as affecting LiteLLM prior to 1.83.10. The NVD entry says the endpoint correctly restricted users to updating only their own account, but did not restrict which fields could be changed, allowing a reachable user to set their role to proxy_admin and gain full administrative access to users, teams, keys, models, and prompt history. (NVD)

This is a classic but dangerous split:

Control	What it answers	Why it was not enough
Object-level authorization	“Can this caller update this user record?”	Yes, a user may update their own profile.
Field-level authorization	“Can this caller update this specific field?”	No, regular users should not write user_role, admin flags, ownership fields, or policy fields.
Business invariant	“Can this transition ever be valid without a privileged workflow?”	A self-service transition from internal_user to proxy_admin should be impossible.
Audit and approval	“Should this change require additional review?”	Role changes to global admin should be logged and usually reviewed.

Field-level authorization is especially important in admin APIs built for speed. A developer may add a generic update endpoint, pass a request object into a database update helper, and trust that the endpoint-level check is sufficient. It is not. The endpoint may correctly identify the object and still allow the caller to mutate a privileged field.

A defensive pattern is to use role-specific update schemas:

USER_SELF_UPDATE_FIELDS = {
    "display_name",
    "email_preferences",
    "default_model",
}

ADMIN_USER_UPDATE_FIELDS = {
    "display_name",
    "email_preferences",
    "default_model",
    "user_role",
    "team_memberships",
    "budget_limit",
    "is_disabled",
}

def filter_update_fields(caller_role, requested_update):
    allowed = ADMIN_USER_UPDATE_FIELDS if caller_role == "proxy_admin" else USER_SELF_UPDATE_FIELDS
    denied = set(requested_update) - allowed

    if denied:
        raise PermissionError(f"fields not allowed for caller role: {sorted(denied)}")

    return {k: v for k, v in requested_update.items() if k in allowed}

The safer model is not “deny after update.” It is “never deserialize privileged fields into a low-privilege update path.”

CVE-2026-40217, guardrails became an execution surface

The third vulnerability in the Obsidian chain is CVE-2026-40217, a custom-code guardrail sandbox escape. NVD describes the vulnerability as allowing remote attackers to execute arbitrary code through bytecode rewriting at the /guardrails/test_custom_code URI in LiteLLM through April 8, 2026. (NVD)

Obsidian’s explanation adds important context. LiteLLM’s Custom Code Guardrail allowed administrators to upload Python code that the proxy compiled and ran in a supposedly restricted exec() environment. Obsidian reported that the production CRUD path used exec() while leaving Python builtins available, and that X41 separately showed the playground endpoint’s regex deny-list could be bypassed with runtime bytecode rewriting. (Obsidian Security)

The security lesson is broader than one endpoint. A guardrail that runs user-supplied Python is not just a policy feature. It is a privileged plugin system. Once an attacker reaches it, the gateway is no longer merely forwarding model requests. It is compiling and executing code in the same environment that may hold model credentials, database URLs, callback configuration, and internal network access.

Python sandboxing is notoriously difficult because the language is dynamic, reflective, and rich with ways to recover capabilities if the environment is not designed with strong isolation. Regex deny-lists are particularly fragile. They search for known-dangerous strings, while attackers search for new ways to express the same capability.

A better control set looks less like “block bad words in Python” and more like “do not run arbitrary Python in the gateway process.”

Safer guardrail design	Security value
Prefer declarative guardrails over arbitrary code	Reduces execution risk and improves auditability.
Run custom logic in a separate sandboxed worker	Limits blast radius if code execution occurs.
Drop Linux capabilities and run as non-root	Prevents gateway compromise from becoming host-level compromise.
Use a read-only filesystem where possible	Reduces persistence and tampering paths.
Remove shell tooling from the runtime image	Makes post-exploitation harder.
Keep provider keys outside the process environment when possible	Reduces immediate credential exposure.
Treat guardrail changes as privileged changes	Requires logging, review, and rollback.

Obsidian reported that BerriAI responded quickly to the RCE issue and added PROXY_ADMIN checks to guardrail compile endpoints in an early patch. It also said the full chain was closed across later fixes, with the remaining allowed_routes bypasses fixed by April 25, 2026 in v1.83.14-stable. (Obsidian Security)

The MCP confusion, CVE-2026-42271 is related but separate

CVE-2026-42271 is often discussed alongside the Obsidian chain, but it is a different vulnerability.

NVD describes CVE-2026-42271 as affecting LiteLLM versions 1.74.2 through versions before 1.83.7. The vulnerable endpoints were POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, which were used to preview an MCP server before saving it. They accepted a full server configuration in the request body, including command, args, and env fields used by the stdio transport. When called with a stdio configuration, the endpoints spawned the supplied command as a subprocess with the privileges of the proxy process. The endpoints were gated only by a valid proxy API key and lacked a role check, so authenticated users, including low-privilege internal-user key holders, could run host commands. The issue was patched in 1.83.7. (NVD)

CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 8, 2026. The Hacker News reported the addition and noted that CISA cited evidence of active exploitation. The same report also said there was no public information about who was exploiting it, how widespread the attacks were, or whether observed exploitation used the unauthenticated chain described by Horizon3. (CISA)

Horizon3 showed why the issue could become worse in some deployments. Its research said CVE-2026-42271 could be chained with CVE-2026-48710, a Starlette “BadHost” Host Header validation bypass, to bypass authentication entirely in LiteLLM deployments whose dependency tree included Starlette versions at or below 1.0.0. Horizon3 assessed the combined chain as CVSS 10.0 and recommended upgrading LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later. (Horizon3.ai)

The underlying security principle is not limited to LiteLLM. MCP stdio is powerful because it allows an AI system to interact with local or remote tools. That same power means a server configuration containing a command is not harmless metadata. It is an execution request.

A safe MCP management plane should enforce at least these rules:

mcp_policy:
  allow_user_defined_stdio_servers: false
  allowed_server_ids:
    - internal-ticket-reader
    - approved-doc-search
  require_admin_for_server_creation: true
  require_review_for_command_changes: true
  block_test_endpoints_from_untrusted_networks: true
  log_fields:
    - user_id
    - endpoint
    - server_id
    - command_hash
    - args_hash
    - source_ip

The values above are illustrative, not a LiteLLM-specific configuration contract. The design goal is clear: users should not be able to submit arbitrary commands for the gateway to test or run. Approved tools should be registered, versioned, reviewed, and monitored like production integrations.

CVE-2026-42208 showed that attackers knew where to look

The earlier SQL injection vulnerability, CVE-2026-42208, is not part of the Obsidian chain, but it is essential background for understanding attacker interest in LiteLLM.

LiteLLM’s official security update says CVE-2026-42208 was a SQL injection in the proxy API key verification path. Affected versions were v1.81.16 through v1.83.6; the fix was available in v1.83.7 and later; and LiteLLM recommended upgrading to v1.83.10-stable. LiteLLM also said an unauthenticated request with a crafted Authorization: Bearer header could, under certain conditions, reach a vulnerable database query path, potentially resulting in unintended database access depending on deployment configuration, network exposure, database permissions, and stored data. (LiteLLM)

Sysdig’s threat research added a real-world exploitation dimension. It reported that the first exploitation attempt appeared 36 hours and seven minutes after the advisory was indexed in the global GitHub Advisory Database. The attacker attempted schema-aware enumeration against three high-value areas: virtual API keys, stored provider credentials, and proxy environment-variable configuration. Sysdig also said it did not observe follow-through such as authenticated reuse of exfiltrated keys or virtual-key minting; the notable finding was the speed and precision of the enumeration attempt. (Sysdig)

The defensive implication is uncomfortable: once an AI gateway CVE is public, attackers may not need much time to understand the schema. Documentation, code, advisories, and open-source repositories can tell them where the valuable tables and environment fields are.

That changes how defenders should prioritize response. A pre-auth SQL injection in an AI gateway is not just “database exposure.” It can become:

Data reached	Why it matters
Virtual API keys	Attackers may replay keys to access models, generate spend, or reach internal routes depending on key scope.
Provider credentials	Direct upstream access may bypass gateway monitoring and budgets.
Proxy environment configuration	Environment variables often contain secrets, internal URLs, database credentials, or feature flags.
Prompt and response logs	Sensitive user input, internal data, and model output may be exposed.
User and team tables	Attackers can map authorization structure and target admins.

If an affected LiteLLM proxy was reachable from an untrusted network during the vulnerable window, patching alone is not enough. Teams should review logs, inspect database activity where possible, and rotate credentials that may have been exposed.

From gateway RCE to agent steering

The most important part of the Obsidian research is not simply that the chain reaches RCE. Server-side RCE is serious, but defenders already understand that class of risk. The newer problem is what happens because the compromised server is an AI gateway.

Obsidian describes a “man-in-the-gateway” position: the attacker controls the box that sits between an agent and its model. Instead of persuading the model through prompt injection, the attacker can rewrite model outputs directly. In the demonstrated scenario, the attacker used LiteLLM callbacks to see and modify LLM request and response flows, then replaced a model response with a forged tool call and rewrote safety-check context so the action appeared allowed. Obsidian says the victim typed only “hello” in Claude Code before the downstream local execution occurred. (Obsidian Security)

That detail matters because it shifts the threat model. Many AI security discussions focus on malicious prompts influencing model behavior. Gateway compromise skips persuasion. The attacker is no longer asking the model to misbehave. The attacker is editing what the agent receives.

A high-level attack model looks like this:

User or agent client
        |
        | prompt, context, tool schema
        v
Compromised AI gateway
        |
        | modified request or response
        v
Model provider
        |
        | legitimate model response returns
        v
Compromised AI gateway rewrites output
        |
        | forged tool call or altered safety context
        v
Downstream agent executes attacker-shaped action

This is why AI gateway security belongs closer to control-plane security than middleware hardening. The gateway may not own the developer workstation, the SaaS account, or the cloud environment directly. But if it can shape the instructions and tool calls that trusted agents consume, it can influence those systems indirectly.

Practical exposure assessment

Defenders need to answer five questions before they can decide how urgent this is.

First, are you running LiteLLM at all? That sounds obvious, but LiteLLM can appear as a direct dependency, a transitive dependency, a containerized gateway, a dev-team proxy, an internal platform service, or part of an agent framework. The March PyPI incident showed that unpinned transitive installs through AI agent frameworks, MCP servers, or orchestration tools can matter. LiteLLM explicitly warned that users may be affected if a dependency pulled in LiteLLM as a transitive, unpinned dependency during the affected window. (LiteLLM)

Second, are you running an affected version? Check both Python packages and deployed containers:

python -m pip show litellm

litellm --version 2>/dev/null || true

docker ps --format 'table {{.Image}}\t{{.Names}}\t{{.Ports}}' | grep -i litellm

kubectl get deploy,statefulset,daemonset -A -o wide | grep -i litellm

Third, is the proxy reachable from an untrusted network? Internet exposure is the highest priority, but internal exposure can still matter if low-privilege users, CI runners, developer laptops, or compromised workloads can reach the management plane.

# Defensive inventory examples
ss -lntp | grep ':4000'

kubectl get svc -A | grep -i litellm

kubectl get ingress -A | grep -i litellm

Fourth, are sensitive management surfaces enabled or reachable? The endpoints most relevant to the discussed issues include key management, user management, guardrails, and MCP test paths. The mere presence of a route in logs is not proof of exploitation, but unexpected access should be investigated.

# Example reverse proxy log review
grep -E '(/key/generate|/key/update|/user/update|/user/bulk_update|/guardrails|/mcp-rest/test/connection|/mcp-rest/test/tools/list)' \
  /var/log/nginx/access.log* 2>/dev/null

Fifth, what secrets could the gateway reach? List environment variables, secret mounts, database credentials, model-provider keys, cloud metadata access, service-account tokens, and egress permissions. Do not assume an AI gateway only has model keys. In many deployments it also has observability, database, cache, storage, and internal API access.

Detection signals that deserve priority

The strongest signals are behavior-based, not version-based. Version checks tell you exposure. Logs tell you whether something suspicious happened.

Signal	Possible meaning	Common false positive	Priority
Requests to /mcp-rest/test/connection from unknown users or networks	Possible probing or use of CVE-2026-42271 path	Legitimate admin testing MCP server setup	High
Requests to /mcp-rest/test/tools/list outside change windows	MCP preview activity that may spawn subprocesses	Tool inventory testing	High
Requests to /guardrails/test_custom_code or unexpected guardrail CRUD	Possible custom-code testing or sandbox probing	Legitimate guardrail development	High
Low-privilege user calling /key/generate with broad routes or wildcard-like routes	Possible CVE-2026-47101 abuse pattern	Misconfigured internal automation	High
Calls to /user/update that modify user_role	Possible CVE-2026-47102 exploitation	Legitimate admin role change, if performed by admin	Critical
LiteLLM proxy process spawning shell, Python, Node, npm, npx, curl, wget, or netcat	Possible command execution through MCP, guardrail, callback, or post-exploitation	Legitimate tool integration, if explicitly approved	Critical
New or modified callbacks invisible to normal admin review	Possible man-in-the-gateway persistence or response rewriting	Planned observability integration	Critical
Unusual Host headers near MCP test endpoint requests	Possible use of Starlette BadHost chain	Misconfigured reverse proxy or scanner	High
Database queries touching verification tokens, credentials, or config tables from unexpected request paths	Possible CVE-2026-42208 exploitation	Admin UI or maintenance scripts	Critical

For Linux hosts, process execution telemetry is especially useful. If LiteLLM is normally just a network service, the proxy process should not be spawning arbitrary shells or package managers.

Example auditd rule pattern:

# Example only: tune path and user for your environment
auditctl -a always,exit -F arch=b64 -S execve -k litellm_exec_monitor
ausearch -k litellm_exec_monitor | grep -iE 'litellm|bash|sh|python|node|npx|curl|wget|nc'

For Kubernetes, look for unexpected process execution inside the LiteLLM pod and suspicious egress:

kubectl logs -n <namespace> deploy/<litellm-deployment> --since=72h \
  | grep -Ei 'mcp-rest/test|guardrails|user/update|key/generate|callback|subprocess|exec'

kubectl get pods -A -o wide | grep -i litellm

For reverse proxies, block or alert on management endpoints from untrusted networks:

# Defensive example: restrict sensitive LiteLLM management surfaces
location ~ ^/(mcp-rest/test/connection|mcp-rest/test/tools/list|guardrails|user/|key/) {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;

    proxy_pass http://litellm_backend;
}

That example is intentionally conservative. Production route design should separate user-facing model inference from admin and management APIs whenever possible.

Credential rotation after exposure

Credential rotation is painful, but AI gateway incidents make it hard to avoid. Obsidian’s research identifies provider credentials, host-level secrets, database credentials, prompt/response data, and OAuth or SaaS API tokens as possible blast-radius items when the gateway is compromised. (Obsidian Security)

After exposure, prioritize rotation in this order:

Secret type	Rotate when	Why
LiteLLM master key	Any suspected admin-plane exposure, RCE, SQLi against key tables, or compromise of environment variables	It can control the gateway itself.
LiteLLM salt key	Any suspected database plus host secret exposure	It may be needed to decrypt stored credentials.
Database credentials	Any suspected RCE, SQL injection, or environment compromise	Attackers may return later even after app patching.
Provider API keys	Any suspected database, config, environment, or prompt gateway compromise	Direct upstream use can bypass the gateway.
Virtual API keys	Any suspected key table access or admin takeover	Attackers may replay them.
OAuth and SaaS tokens used by agents or tools	Any suspected MCP, callback, or agent gateway compromise	Tool tokens can enable lateral movement.
CI and cloud credentials on the same host	Any suspected supply chain or host-level compromise	AI infrastructure often runs near build and deployment secrets.

Do not rotate keys before preserving enough evidence to understand the incident, unless the key is actively being abused. In practice, many teams do both: snapshot logs and database state, then rotate.

Hardening LiteLLM and similar AI gateways

The immediate step is version remediation. For the Obsidian chain, upgrade to LiteLLM v1.83.14-stable or later according to Obsidian’s disclosure. For CVE-2026-42271, upgrade to 1.83.7 or later according to NVD and Horizon3. For CVE-2026-42208, LiteLLM says the fix is in v1.83.7 and later and recommends v1.83.10-stable. (Obsidian Security)

But version remediation is not the whole defense. The architecture should assume that AI gateways are high-value control planes.

Layer	Recommended control	Reason
Network	Do not expose admin or management routes to the public internet	Many issues become much worse when reachable by anyone.
Identity	Separate inference keys from admin keys	A key used by an app should not manage users, routes, guardrails, or MCP servers.
Authorization	Enforce route scopes as subsets of caller authority	Prevents user-controlled scopes from becoming privilege grants.
Field safety	Use role-specific update schemas	Blocks self-service writes to user_role, ownership, and policy fields.
Guardrails	Avoid arbitrary Python execution in the gateway process	Guardrails should not become RCE by design.
MCP	Allowlist server definitions and disallow arbitrary stdio commands from users	MCP configuration can be code execution.
Runtime	Run non-root, read-only, with minimal tools and dropped capabilities	Limits post-exploitation.
Secrets	Use a secret manager and least-privilege provider keys	Reduces blast radius of environment or database exposure.
Egress	Block unknown outbound traffic from the gateway	Makes exfiltration and reverse connections harder.
Audit	Log admin changes, key creation, role updates, guardrail changes, and callback changes	Enables incident reconstruction.
Continuous validation	Test the actual deployed trust boundary, not only dependency versions	Misconfiguration can reintroduce risk after patching.

A hardened deployment should separate the data plane from the admin plane. User applications should reach model inference endpoints. Only a narrow admin network should reach key generation, user management, guardrail management, MCP server registration, callback configuration, and sensitive diagnostic routes.

A safer MCP and agent gateway pattern

MCP and agent gateways need stronger controls than ordinary API routes because they may trigger tool execution.

A reasonable baseline is:

agent_gateway_controls:
  admin_plane:
    network: private
    mfa_required: true
    role_required_for_mcp_changes: proxy_admin
    role_required_for_guardrail_changes: proxy_admin
  mcp:
    arbitrary_stdio: disabled
    approved_servers_only: true
    command_changes_require_review: true
    test_endpoints_public: false
  runtime:
    run_as_root: false
    read_only_filesystem: true
    outbound_allowlist:
      - approved_model_provider_domains
      - approved_observability_endpoint
    block_metadata_service: true
  audit:
    log_role_changes: true
    log_key_scope_changes: true
    log_callback_changes: true
    log_guardrail_changes: true

The exact syntax will vary by platform. The important control is not the YAML; it is the policy. Any component that can register tools, spawn subprocesses, rewrite prompts, modify model responses, or change admin roles should be treated as privileged infrastructure.

Incident response checklist for the first 48 hours

When a LiteLLM gateway may have been exposed, the first response should be evidence-driven.

Step	Action	Why
1	Identify all LiteLLM deployments, including containers, Python installs, dev proxies, and transitive dependencies	Shadow gateways are common in fast-moving AI teams.
2	Record current version, image digest, config, environment, and deployment history	You need a timeline before patching changes state.
3	Restrict network access to admin and test endpoints	Reduces active exposure while investigation continues.
4	Upgrade to a fixed version appropriate for the relevant CVEs	Removes known vulnerable paths.
5	Search logs for sensitive endpoints and unusual source IPs	Finds possible exploitation attempts.
6	Review key creation and update history	Looks for unauthorized routes or wildcard scopes.
7	Review user role changes	Detects self-promotion or admin takeover.
8	Review guardrail and callback changes	Looks for persistence or response rewriting.
9	Check process execution telemetry	Finds command execution through MCP, guardrails, or post-exploitation.
10	Rotate master keys, provider keys, virtual keys, database credentials, and tool tokens based on exposure	Prevents replay and follow-on abuse.
11	Review prompt and response logs for sensitive data exposure	Determines privacy, customer, and compliance impact.
12	Re-test controls after patching	Confirms that the management plane is actually protected.

Teams that already run authorized validation workflows should include AI gateways, MCP endpoints, and agent tool boundaries in routine testing. A version scanner may confirm that a patched package is installed, but it will not prove that management endpoints are isolated, that low-privilege users cannot mutate privileged fields, that dangerous MCP test routes are blocked, or that evidence is collected cleanly when a control fails. In authorized environments, Penligent can be used as part of a broader AI-assisted penetration testing workflow for attack surface mapping, verification, evidence capture, and retesting. A related Penligent analysis of CVE-2026-42208 frames the same issue as an AI gateway credential problem rather than a narrow SQL injection bug: CVE-2026-42208, LiteLLM SQL Injection and the AI Gateway Credential Problem.

The key is authorization and scope. AI-assisted validation should never be run against systems without permission, and it should produce reproducible evidence rather than speculative claims.

Design mistakes that made the chain plausible

The LiteLLM vulnerability chain is useful because it shows several recurring security mistakes in one place.

First, user-controlled scope was not treated as a subset of caller authority. The allowed_routes concept should have narrowed a virtual key, but the vulnerable path allowed it to broaden access.

Second, object ownership was confused with field authorization. A user may be allowed to edit their own profile, but that does not mean the user may edit their own role.

Third, code execution was placed too close to secrets. Custom-code guardrails may be useful, but executing them in the gateway process creates a direct path from admin-plane abuse to host-level impact.

Fourth, MCP testing blurred the line between validation and execution. A “test connection” endpoint that accepts a command and runs it is not just a diagnostic endpoint. It is an execution API.

Fifth, AI response integrity was not treated as a critical trust boundary. A compromised gateway can alter the agent’s perception of what the model said. For coding agents and tool-using assistants, that can be as powerful as compromising the tool itself.

Common mistakes during remediation

Many organizations will respond by patching and moving on. That is not enough when the exposed component holds credentials and may have executed code.

Mistake	Why it is risky	Better action
Patching without log review	You may remove the vulnerable code while leaving stolen keys active	Preserve and inspect logs before and after upgrade
Rotating only provider keys	Attackers may still hold virtual keys, database credentials, or OAuth tokens	Rotate by blast-radius category
Leaving management endpoints on the same public route	Future admin-plane bugs remain internet-reachable	Split inference and admin planes
Trusting “authenticated only” endpoints	Low-privilege keys may be easy to obtain or intended for many users	Apply role checks and endpoint segmentation
Allowing arbitrary MCP stdio definitions	User-controlled commands remain execution primitives	Use approved server definitions
Treating guardrails as low-risk policy	Custom guardrails can be privileged code	Audit, isolate, and review them
Ignoring callbacks	Callbacks may see and modify request and response flows	Make callbacks visible, logged, and change-controlled

What defenders should monitor after patching

Post-patch monitoring should focus on persistence, replay, and downstream abuse.

Look for old virtual keys being used from new source networks. Look for provider API usage that bypasses the gateway after provider keys may have leaked. Look for new callbacks, changed guardrails, or unexpected MCP server definitions. Look for coding-agent behavior that includes unexplained tool calls, local shell execution, or unusual prompts. Look for cloud or SaaS API calls from the gateway host that do not match normal model routing.

Gateway compromise can also affect billing and abuse monitoring. If provider credentials were exposed, attackers may generate cost or use the keys for unrelated activity. Rate limits, budget alarms, and provider-side audit logs should be reviewed alongside gateway logs.

FAQ

What is the LiteLLM vulnerability chain?

• The main CVSS 9.9 chain disclosed by Obsidian combines CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217.
• The chain starts with an authorization bypass involving allowed_routes, continues into role escalation through user update fields, and can reach server-side code execution through custom-code guardrail behavior.
• Obsidian reported that a default low-privilege user could reach administrator access and RCE when the vulnerabilities were chained in affected versions.
• The broader security lesson is that AI gateways should be treated as credential and control-plane infrastructure, not just API middleware.

Is CVE-2026-42271 part of the CVSS 9.9 LiteLLM chain?

• No. CVE-2026-42271 is related to LiteLLM and AI gateway execution risk, but it is not one of the three CVEs in the Obsidian CVSS 9.9 chain.
• CVE-2026-42271 affects MCP preview endpoints that accepted stdio server configuration, including command, args, and env fields.
• NVD says the issue affected LiteLLM versions 1.74.2 through versions before 1.83.7 and was patched in 1.83.7.
• CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog, so defenders should prioritize it even though it is a separate issue.

Which LiteLLM versions should defenders upgrade to?

• For the Obsidian chain involving CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217, Obsidian says the full set of fixes is included in LiteLLM v1.83.14-stable and later.
• For CVE-2026-42271, NVD says the issue is patched in 1.83.7.
• For CVE-2026-42208, LiteLLM says the fix is in 1.83.7 and later and recommends v1.83.10-stable.
• In practice, teams should move to a current maintained release, then verify configuration, endpoint exposure, and secret rotation needs.

Can a low-privilege LiteLLM user really become admin?

• In the Obsidian chain, yes, under affected conditions.
• CVE-2026-47101 allowed a low-privilege user to create a key with routes beyond the user’s role.
• CVE-2026-47102 allowed reachable users to modify user_role through insufficient field-level authorization.
• A low-privilege user could therefore move through route bypass into role escalation and become proxy_admin in the vulnerable chain.

Why are AI gateways more sensitive than ordinary API proxies?

• AI gateways often store or reach upstream model-provider credentials.
• They may issue virtual API keys, enforce budgets, log prompts and responses, and manage team access.
• They may also run guardrails, callbacks, MCP tool definitions, or agent routing logic.
• A compromise can expose provider keys, prompt data, virtual keys, model responses, and tool execution paths.

What logs should defenders check first?

• Reverse proxy logs for /mcp-rest/test/connection, /mcp-rest/test/tools/list, /guardrails, /guardrails/test_custom_code, /key/generate, /key/update, /user/update, and /user/bulk_update.
• Application logs for role changes, virtual key creation, wildcard route scopes, callback changes, guardrail changes, and MCP server changes.
• Host or container telemetry for unexpected subprocesses spawned by the LiteLLM process.
• Database logs for access to verification token, credentials, configuration, and user role tables.
• Provider-side logs for API key use from unfamiliar networks or outside normal gateway paths.

Should teams rotate OpenAI, Anthropic, Gemini, Bedrock, Azure, or other provider keys after exposure?

• Rotate provider keys if the gateway had RCE exposure, SQL injection exposure affecting credential tables, suspicious admin activity, suspicious callback or guardrail changes, or evidence that environment variables or database secrets were reached.
• Rotate LiteLLM virtual keys if verification token tables, key-management endpoints, or admin accounts may have been accessed.
• Rotate database credentials and LiteLLM master or salt keys if host-level secrets may have been exposed.
• Review provider-side usage logs after rotation because stolen keys may have been used outside the gateway.

What is the safest long-term architecture for LiteLLM or similar gateways?

• Separate inference traffic from admin and management traffic.
• Keep management endpoints private and reachable only from trusted networks.
• Enforce strict role and field-level authorization on key, user, route, guardrail, callback, and MCP APIs.
• Do not allow arbitrary stdio MCP commands from ordinary users.
• Treat custom-code guardrails and callbacks as privileged code, not simple configuration.
• Run the gateway with least privilege, minimal runtime tooling, restricted egress, and externalized secrets.
• Continuously validate the deployed controls, not just the installed package version.

Closing judgment

The LiteLLM vulnerability chain is important because it shows where AI infrastructure is heading. The gateway is no longer just a convenience layer for calling many models through one API. It can become the place where credentials, prompts, responses, budgets, tool calls, guardrails, callbacks, and agent workflows meet.

That position makes it valuable. It also makes it dangerous.

For defenders, the right response is not only “upgrade LiteLLM.” Upgrade, then reduce network exposure, rotate secrets where exposure is plausible, audit admin state, inspect guardrails and callbacks, constrain MCP execution, and verify that low-privilege users cannot cross into management authority. AI gateway security now belongs in the same category as identity providers, CI/CD systems, cloud control planes, and privileged automation platforms: if it can steer trusted systems, it must be hardened and monitored like a control plane.