Notifications
Clear all
Topic starter
14/08/2026 6:37 pm
TL;DR: Three chained LiteLLM vulnerabilities let a default low-privilege user reach admin access and arbitrary code execution, while also enabling a compromised gateway to inject tool calls into downstream agents like Claude Code, according to Obsidian Security. The core issue is that AI gateways concentrate trust, so route checks and field-level authorization cannot be treated as interchangeable controls.
NHIMG editorial — based on content published by Obsidian Security: LiteLLM: From Low-Privilege User to Admin and RCE (CVE-2026-47101, CVE-2026-47102, CVE-2026-40217)
By the numbers:
- 83% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in current deployments.
Questions worth separating out
Q: What breaks when AI gateways let low-privilege users influence route permissions?
A: The gateway stops enforcing least privilege and starts widening access based on caller-controlled data.
Q: Why do AI gateways create more risk than ordinary application proxies?
A: AI gateways often hold master keys, provider credentials, and routing authority for multiple downstream services.
Q: How do you know whether gateway authorization policies are actually working?
A: You know they are working when policy tests cover both allowed and denied scenarios, decision logs are captured, and changes can be released without breaking expected access.
Practitioner guidance
- Separate route access from state-change authorization Audit every gateway endpoint that writes identity state, role state, or permission state.
- Inventory all protected identity fields Review update handlers for fields such as user_role, membership roles, service-account bindings, and token scopes.
- Treat executable guardrails as privileged code Move any user-authored or admin-authored runtime code out of the main gateway process where possible.
What's in the full report
Obsidian Security's full research covers the exploit details this post intentionally leaves at the control-analysis level:
- Line-by-line proof-of-concept walkthroughs for the allowed_routes bypass and role escalation paths.
- Code-level explanation of the custom-code guardrail sandbox escape, including the exec() and bytecode-bypass paths.
- Patch timeline and version guidance for LiteLLM v1.83.14-stable and the earlier fix releases.
- Operational recommendations for rotating provider keys, database credentials, and MCP tokens after suspected exposure.
👉 Read Obsidian Security's analysis of LiteLLM CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217 →
LiteLLM CVEs and AI gateway privilege gaps: what breaks first?
Explore further
14/08/2026 6:44 pm
AI gateways are becoming identity enforcement points, not just integration layers. LiteLLM shows that the control plane between agents and models now carries route policy, key ownership, guardrails, and audit authority. When that layer fails, the breach is not limited to one service account or one API token. Practitioners should treat gateways as privileged identity infrastructure with its own governance model.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when a compromised AI gateway injects tool calls into agents?
A: Accountability usually spans the platform owner, the team that exposed the gateway, and the group that trusted it as an execution intermediary. In governance terms, the gateway should be treated like a privileged identity broker, so ownership, logging, and emergency revocation need a named control owner before incidents occur.
👉 Read our full editorial: LiteLLM’s admin and RCE chain exposes AI gateway trust gaps
