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.
What the two CVEs actually do
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.
Why agent builders should care
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.
Prerequisites
- Shell access to wherever LiteLLM runs (Docker host, VPS, or the machine with
pip install litellm) - Your LiteLLM version number (Step 1 shows you how)
- Admin access to your LiteLLM UI and your AI provider dashboards (to rotate keys)
- Permission to restart the gateway container or process
Step 1 - Check your LiteLLM version
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.
Step 2 - Upgrade to LiteLLM 1.83.9 or later
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.
Step 3 - Rotate every provider API key stored in the gateway
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.
- In each provider dashboard (OpenAI, Anthropic, Google AI, and any others configured), generate a new API key.
- Update the environment variables or config file LiteLLM reads — typically
OPENAI_API_KEY,ANTHROPIC_API_KEY,GEMINI_API_KEY, and friends in your.envor Docker Compose file. - Revoke the old keys at the provider so they can't be used if they were exfiltrated.
- Restart the gateway so it picks up the new values.
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.
Step 4 - Audit accounts and verify permissions are actually enforced
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.
Hard cases and limits
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.
FAQ
Am I affected if I only use LiteLLM's Python SDK, not the proxy server?
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.
Do these flaws affect n8n's built-in AI nodes directly?
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.
Was there active exploitation before the patch?
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.
Key Takeaways
- LiteLLM before 1.83.9 is vulnerable to two serious flaws: CVE-2026-35029 (missing authz → any user to admin + RCE) and CVE-2026-59823 (SSRF → every provider API key exposed).
- Upgrade to 1.83.9 or later immediately, then restart the gateway — the running process stays vulnerable until it restarts.
- Rotate every provider API key the gateway stored; revoking the old ones at the provider is what actually kills a stolen key.
- Prune gateway accounts and test permissions as a low-privilege user — the gap between configured and enforced permissions is where this class of bug lives.
- Treat AI gateways as high-value targets in your security routine: they hold the keys to everything your agents do.
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 (reporting Check Point's disclosure, Oct 15, 2026).
Images: Pexels (free license).
Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/
Top comments (0)