Your LLM Gateway Holds Every API Key. LiteLLM Let Any User Steal Them: CVE-2026-35029 Patch Guide

Check Point's AI agent security team disclosed two vulnerabilities in LiteLLM, the open-source LLM gateway downloaded roughly 100,000 times a month, that together collapse its security model: CVE-2026-35029, a missing authorization check on the runtime configuration endpoint that lets any authenticated user gain admin access and achieve remote code execution, and CVE-2026-59823, a server-side request forgery flaw that redirects the gateway's outbound requests and exposes every stored provider API key. Both are fixed in LiteLLM 1.83.9, and any older version is affected. "Anyone holding an account on a vulnerable deployment could take over the gateway," said Mateo Rojas-Carulla, Check Point's head of research for AI agent security.

LiteLLM is the open-source LLM gateway that roughly 100,000 developers download every month to route their apps through OpenAI, Anthropic, Google, and every other model provider. Check Point's AI agent security team found two vulnerabilities in it that collapse its entire security model: a missing authorization check that lets any user become an admin and run code CVE-2026-35029 , and a server-side request forgery flaw that exposes every provider API key stored in the gateway CVE-2026-59823 . Both are fixed in LiteLLM 1.83.9. If you run LiteLLM — especially in front of your n8n AI agents — this post gives you the four-step check, patch, rotate, and audit procedure. An LLM gateway sits between your application and the model providers. Instead of each workflow calling OpenAI's API directly, everything routes through the gateway, which forwards requests to the right backend. LiteLLM is exactly that: a proxy that centralizes credentials, logging, and usage tracking. That centralization is the point — and it's exactly what makes these flaws dangerous. CVE-2026-35029 is a missing authorization check. Authorization is the part of security that answers "is this user allowed to do this?" LiteLLM's runtime configuration endpoint was missing that check, so any authenticated user — even one with the lowest privilege role — could modify the gateway's runtime configuration. Per Check Point's findings, that turns into full system takeover: file access, credential theft, and remote code execution via malicious Python modules loaded from cloud storage. Mateo Rojas-Carulla, Check Point's head of research for AI agent security, put it bluntly: anyone holding an account on a vulnerable deployment could take over the gateway. CVE-2026-59823 is a server-side request forgery SSRF flaw. SSRF is when an attacker tricks your server into making a network request of their choosing. Here, it lets an attacker redirect the gateway's outbound requests — which means the requests that carry your OpenAI, Anthropic, and Google API keys — toward an attacker-controlled destination. The keys that were supposed to be the most centralized, protected secret in your AI stack get handed over. Check Point disclosed both through the coordinated disclosure process, and LiteLLM shipped the fixes in version 1.83.9 — anything older than 1.83.9 is affected. If you self-host n8n, there's a good chance LiteLLM sits in your stack: it's the natural way to give all your AI Agent nodes one OpenAI-compatible endpoint, with fallbacks, load balancing, and a single bill. The danger here is the blast radius math. A compromised LLM gateway isn't one leaked key — it's every key: OpenAI, Anthropic, Gemini, and whatever else you've configured. And unlike a leaked key that an attacker quietly uses, a gateway takeover is a standing foothold: the attacker can execute code on the host, read files, and pivot further. Christopher Jess, senior R&D manager at Black Duck, noted the pattern is painfully familiar: a missing permission check let low-privileged users reach administrative functions, with code execution as the consequence. As AI adoption accelerates, he warned, security fundamentals are being treated as secondary — and a gateway that centralizes all your AI access is a particularly valuable target. The one-line takeaway: the box holding all your model API keys let any of its users pick the lock and walk out with the whole ring. pip install litellm The vulnerabilities affect every LiteLLM version older than 1.83.9 . Find your running version first. If you run LiteLLM in Docker, exec into the container: docker exec <your-litellm-container pip show litellm 2 /dev/null | grep -E "Name|Version" Or check from the host if you installed with pip: pip show litellm | grep -E "Name|Version" You should see a Version: line like Version: 1.83.9 . Anything below 1.83.9 is vulnerable — proceed to Step 2 immediately. If you're on 1.83.9 or later, the fixes are in; skip to Step 4 and still do the audit, because the flaws were live in your version history if you ever ran an older build. Pull and restart with the fixed release. For Docker Compose installs: cd /path/to/your/litellm-compose docker compose pull docker compose up -d docker exec <your-litellm-container pip show litellm | grep Version The pip show output must read 1.83.9 or higher. For pip installs, upgrade in place: pip install --upgrade "litellm =1.83.9" Restart the LiteLLM process afterward — the fix is in the application code, so a running old process stays vulnerable until restarted. Warning: upgrading doesn't erase what already happened. If your gateway was reachable by accounts you don't fully trust, treat key rotation in Step 3 as mandatory, not optional. CVE-2026-59823 exposes the API keys LiteLLM stores. Rotating means generating a brand-new key at the provider and replacing the old one everywhere the gateway reads it, so any stolen copy stops working. OPENAI API KEY , ANTHROPIC API KEY , GEMINI API KEY , and friends in your .env or Docker Compose file. Verify the old keys are dead by checking your provider dashboards: the revoked keys should show as inactive or deleted, and your LiteLLM health endpoint should still respond normally with the new keys in place. Check Point's explicit recommendation applies here: since any account could have exploited these flaws, review who has gateway access and remove accounts that no longer need it. In the LiteLLM UI, list users and their roles, and prune anything stale — former teammates, test accounts, shared credentials. Then do the permission check that would have caught this bug: log in as a low-privilege user and try to reach an admin-only endpoint the runtime config modification path is the one to test . If a low-privilege account can change anything admin-scoped, your role enforcement still has a gap — the fix closed these two CVEs, but the discipline of verifying permissions in practice is what keeps the next missing check from hurting you. Finally, add the gateway to your security routine: include LiteLLM in your regular vulnerability scans and penetration tests alongside your web apps and cloud infra. Gateways are high-value targets precisely because they centralize secrets. This guide covers the reported, patched CVEs only. It does not audit your LiteLLM deployment for other misconfigurations — open admin UI to the internet, default credentials, overly broad key scopes. If your gateway was internet-facing, assume broader exposure and review access logs for unusual config changes around the disclosure window Check Point's detailed post went out October 13, 2026 . There is no published workaround that avoids the upgrade; patching is the only fix. I also haven't verified LiteLLM's exact endpoint paths for the vulnerable calls — use the official advisory and your version's behavior as the source of truth, not this post, for the specific API routes in your environment. The disclosed flaws target the LiteLLM proxy/gateway server, which serves multiple users and stores provider keys. A local SDK-only setup that never exposes a server to other users is not the attack scenario described — but if you run the proxy at all, check your version. No. They affect LiteLLM itself. But if your n8n workflows point at a self-hosted LiteLLM endpoint, every model call your agents make flows through the vulnerable component — which is why this is an n8n-builder problem too. Neither Check Point's report nor the coverage I've seen confirms in-the-wild exploitation. That said, the details were published October 13, 2026, and exploitability is trivial for any account holder — the safe assumption is that exposed instances are being probed now. Next: if your LiteLLM is internet-facing, review its access logs for config changes made by unexpected accounts around mid-October. And while you're in the gateway's settings, check that the admin UI isn't reachable from the public internet at all — that's a separate exposure these CVEs didn't need, but it's the next one attackers will try. Sources: Infosecurity Magazine https://www.infosecurity-magazine.com/news/high-risk-vulnerabilities-llm-tool/ reporting Check Point's disclosure, Oct 15, 2026 . Images: Pexels free license . Originally published on CortexFlow https://cortexflow.tech/blog/litellm-missing-auth-rce-cve-patch-guide/ . Free n8n templates: https://cortexflow.tech/templates/ https://cortexflow.tech/templates/