Sicherheitslücke in LiteLLM setzt alle API-Keys im LLM Gateway aufs Spiel
LiteLLM ist ein Open-Source-LLM-Gateway, das monatlich von rund 100.000 Entwicklern genutzt wird, um Anfragen an OpenAI, Anthropic, Google und andere Anbieter zu leiten. Das AI-Sicherheitsteam von Check Point fand zwei Schwachstellen, die das gesamte Sicherheitsmodell aushebeln, darunter eine fehlende...
Veröffentlicht am 16. Oktober, ursprünglich erschienen auf cortexflow.tech
LiteLLM ist das Open-Source-LLM-Gateway, das monatlich von rund 100.000 Entwicklern heruntergeladen wird, um ihre Anwendungen über OpenAI, Anthropic, Google und alle anderen Modellanbieter zu leiten. Das AI-Agent-Sicherheitsteam von Check Point hat darin zwei Schwachstellen gefunden, die das gesamte Sicherheitsmodell zusammenbrechen lassen: eine fehlende Autorisierungsprüfung, die es jedem Nutzer ermöglicht, Admin zu werden und Code auszuführen (CVE-2026-35029), sowie eine Server-Side-Request-Forgery-Schwachstelle, durch die jeder im Gateway gespeicherte Anbieter-API-Schlüssel offengelegt wird (CVE-2026-59823). Beide sind in LiteLLM 1.83.9 behoben.
Wenn Sie LiteLLM betreiben, insbesondere vor Ihren n8n-KI-Agenten, bietet Ihnen dieser Beitrag die vierstufige Prozedur: prüfen, patchen, Schlüssel rotieren und auditieren.
Ein LLM-Gateway sitzt zwischen Ihrer Anwendung und den Modellanbietern. Statt dass jeder Workflow die OpenAI-API direkt aufruft, läuft alles über das Gateway, das die Anfragen an das richtige Backend weiterleitet. Genau das ist LiteLLM: ein Proxy, der Zugangsdaten, Logging und Nutzungsverfolgung zentralisiert. Diese Zentralisierung ist der Sinn der Sache, und genau das macht diese Schwachstellen so gefährlich.
CVE-2026-35029 ist eine fehlende Autorisierungsprüfung. Autorisierung ist der Teil der Sicherheit, der die Frage beantwortet, ob ein Nutzer etwas tun darf. Dem Laufzeit-Konfigurationsendpunkt von LiteLLM fehlte diese Prüfung, sodass jeder authentifizierte Nutzer, selbst einer mit der niedrigsten Rollenberechtigung, die Laufzeitkonfiguration des Gateways ändern konnte.
Laut den Erkenntnissen von Check Point führt das zu einer vollständigen Übernahme des Systems: Dateizugriff, Diebstahl von Zugangsdaten und Remote-Code-Ausführung über bösartige Python-Module, die aus Cloud-Speicher geladen werden. Mateo Rojas-Carulla, Leiter der Forschung für AI-Agent-Sicherheit bei Check Point, brachte es auf den Punkt: Jeder, der über ein Konto auf einer verwundbaren Installation verfügt, konnte das Gateway übernehmen.
CVE-2026-59823 ist eine Server-Side-Request-Forgery-Schwachstelle (SSRF). SSRF bedeutet, dass ein Angreifer Ihren Server dazu verleitet, eine Netzwerkanfrage seiner Wahl auszuführen. Hier ermöglicht es einem Angreifer, die ausgehenden Anfragen des Gateways, also diejenigen, die Ihre OpenAI-, Anthropic- und Google-API-Schlüssel tragen, an ein von ihm kontrolliertes Ziel umzuleiten. Die Schlüssel, die das am stärksten zentralisierte und geschützte Geheimnis Ihres KI-Stacks sein sollten, werden damit herausgegeben.
Check Point hat beide Schwachstellen im Rahmen des koordinierten Disclosure-Prozesses offengelegt, und LiteLLM hat die Fehlerbehebungen in Version 1.83.9 ausgeliefert. Alles Ältere als 1.83.9 ist betroffen.
Wenn Sie n8n selbst hosten, sitzt LiteLLM recht wahrscheinlich in Ihrem Stack: Es ist der naheliegende Weg, allen Ihren AI-Agent-Nodes einen einzigen OpenAI-kompatiblen Endpunkt mit Fallbacks, Lastverteilung und einer einzigen Rechnung zu geben. Die Gefahr liegt hier in der Reichweitenrechnung. Ein kompromittiertes LLM-Gateway ist nicht nur ein geleakter Schlüssel, sondern jeder Schlüssel: OpenAI, Anthropic, Gemini und alles andere, was Sie konfiguriert haben. Und anders als bei einem geleakten Schlüssel, den ein Angreifer still nutzt, ist eine Gateway-Übernahme ein dauerhafter Stützpunkt: Der Angreifer kann Code auf dem Host ausführen, Dateien lesen und sich weiter ausbreiten.
Christopher Jess, Senior R&D Manager bei Black Duck, stellte fest, dass das Muster schmerzhaft vertraut ist: Eine fehlende Berechtigungsprüfung ermöglichte Nutzern mit geringen Rechten den Zugriff auf administrative Funktionen, mit Code-Ausführung als Folge. Mit der wachsenden KI-Adoption, warnte er, würden die Sicherheitsgrundlagen als zweitrangig behandelt, und ein Gateway, das den gesamten KI-Zugriff zentralisiert, sei ein besonders wertvolles Angriffsziel.
Die Kernaussage in einem Satz: Die Box, die alle Ihre Modell-API-Schlüssel enthält, ließ jeden ihrer Nutzer das Schloss knacken und den ganzen Schlüsselbund mitnehmen.
Die Schwachstellen betreffen jede LiteLLM-Version älter als 1.83.9. Ermitteln Sie zunächst Ihre laufende Version.
Wenn Sie LiteLLM in Docker betreiben, führen Sie folgenden Befehl im Container aus:
docker exec <ihr-litellm-container> pip show litellm 2>/dev/null | grep -E "Name|Version" Oder prüfen Sie vom Host aus, wenn Sie mit pip installiert haben:
pip show litellm | grep -E "Name|Version" Sie sollten eine Zeile wie Version: 1.83.9 sehen. Alles unter 1.83.9 ist verwundbar, fahren Sie sofort mit Schritt 2 fort. Wenn Sie Version 1.83.9 oder neuer verwenden, sind die Fixes enthalten; springen Sie zu Schritt 4 und führen Sie trotzdem das Audit durch, denn die Schwachstellen waren in Ihrer Versionshistorie aktiv, falls Sie jemals einen älteren Build betrieben haben.
Ziehen Sie das korrigierte Release und starten Sie neu. Bei Docker-Compose-Installationen:
cd /pfad/zu/ihrer/litellm-compose docker compose pull docker compose up -d docker exec <ihr-litellm-container> pip show litellm | grep Version Die Ausgabe von pip show muss 1.83.9 oder höher anzeigen. Bei pip-Installationen aktualisieren Sie direkt:
pip install --upgrade "litellm>=1.83.9" Starten Sie danach den LiteLLM-Prozess neu. Der Fix steckt im Anwendungscode, daher bleibt ein laufender alter Prozess verwundbar, bis er neu gestartet wurde.
Warnung: Das Upgrade löscht nicht das, was bereits geschehen ist. Wenn Ihr Gateway für Konten erreichbar war, denen Sie nicht voll vertrauen, behandeln Sie die Schlüsselrotation in Schritt 3 als verpflichtend, nicht als optional.
CVE-2026-59823 legt die von LiteLLM gespeicherten API-Schlüssel offen. Rotation bedeutet, beim Anbieter einen completely neuen Schlüssel zu erzeugen und den alten überall zu ersetzen, wo das Gateway ihn liest, damit jede gestohlene Kopie unbrauchbar wird.
Prüfen Sie, ob die alten Schlüssel deaktiviert sind, indem Sie Ihre Anbieter-Dashboards kontrollieren: Die widerrufenen Schlüssel sollten als inaktiv oder gelöscht erscheinen, und Ihr LiteLLM-Health-Endpunkt sollte mit den neuen Schlüsseln weiterhin normal antworten.
Die ausdrückliche Empfehlung von Check Point greift hier: Da jedes Konto diese Schwachstellen ausnutzen konnte, überprüfen Sie, wer Gateway-Zugriff hat, und entfernen Sie Konten, die ihn nicht mehr benötigen. Listen Sie in der LiteLLM-Oberfläche die Nutzer und ihre Rollen auf und entfernen Sie alles Veraltete, etwa frühere Teammitglieder, Testkonten und geteilte Zugangsdaten.
Führen Sie dann die Berechtigungsprüfung durch, die diesen Fehler gefunden hätte: Melden Sie sich als Nutzer mit geringen Rechten an und versuchen Sie, einen rein administrativen Endpunkt zu erreichen (die Laufzeitkonfigurationsänderung ist der zu testende Pfad). Wenn ein Konto mit geringen Rechten etwas im Admin-Bereich ändern kann, hat Ihre Rollendurchsetzung noch eine Lücke. Der Fix hat diese beiden CVEs geschlossen, aber die Praxis, Berechtigungen tatsächlich zu verifizieren, verhindert, dass die nächste fehlende Prüfung Sie trifft.
Fügen Sie das Gateway schließlich in Ihren Sicherheitsalltag ein: Nehmen Sie LiteLLM in Ihre regelmäßigen Schwachstellenscans und Penetrationstests auf, gemeinsam mit Ihren Webanwendungen und Ihrer Cloud-Infrastruktur. Gateways sind wertvolle Ziele, gerade weil sie Geheimnisse zentralisieren.
Diese Anleitung deckt nur die gemeldeten und gepatchten CVEs ab. Sie prüft Ihre LiteLLM-Installation nicht auf andere Fehlkonfigurationen wie eine im Internet offene Admin-Oberfläche, Standard-Zugangsdaten oder zu weit gefasste Schlüsselberechtigungen. Wenn Ihr Gateway aus dem Internet erreichbar war, gehen Sie von einer breiteren Exposition aus und prüfen Sie die Zugriffsprotokolle auf ungewöhnliche Konfigurationsänderungen im Zeitraum um die Offenlegung (Check Points ausführlicher Beitrag erschien am 13. Oktober 2026). Es gibt keinen veröffentlichten Workaround, der das Upgrade vermeidet; Patchen ist die einzige Lösung.
Ich habe zudem die genauen Endpunktpfade von LiteLLM für die verwundbaren Aufrufe nicht verifiziert. Nutzen Sie die offizielle Empfehlung und das Verhalten Ihrer Version als maßgebliche Quelle für die konkreten API-Routen in Ihrer Umgebung, nicht diesen Beitrag.
Die offengelegten Schwachstellen zielen auf den LiteLLM-Proxy- bzw. Gateway-Server ab, der mehrere Nutzer bedient und Anbieter-Schlüssel speichert. Eine rein lokale SDK-Einrichtung, die niemals einen Server für andere Nutzer exponiert, ist nicht das beschriebene Angriffsszenario. Wenn Sie den Proxy aber überhaupt betreiben, prüfen Sie Ihre Version.
Nein. Sie betreffen LiteLLM selbst. Wenn Ihre n8n-Workflows jedoch auf einen selbst gehosteten LiteLLM-Endpunkt verweisen, fließt jeder Modellaufruf Ihrer Agenten durch die verwundbare Komponente, weshalb dies auch ein Problem für n8n-Entwickler ist.
Weder Check Points Bericht noch die Berichterstattung, die ich gesehen habe, bestätigen Ausnutzung in freier Wildbahn. Die Details wurden jedoch am 13. Oktober 2026 veröffentlicht, und die Ausnutzung ist für jeden Kontoinhaber trivial. Die sichere Annahme ist, dass exponierte Instanzen derzeit abgeklopft werden.
Weiter: Wenn Ihr LiteLLM aus dem Internet erreichbar ist, prüfen Sie die Zugriffsprotokolle auf Konfigurationsänderungen durch unerwartete Konten Mitte Oktober. Und während Sie sich in den Gateway-Einstellungen befinden, kontrollieren Sie, ob die Admin-Oberfläche überhaupt nicht aus dem öffentlichen Internet erreichbar ist. Das ist eine separate Exposition, die diese CVEs nicht brauchten, aber sie ist der nächste Angriffspunkt, den Angreifer versuchen werden.
Quellen: Infosecurity Magazine (Berichterstattung über Check Points Offenlegung, 15. Oktober 2026).
Ursprünglich veröffentlicht auf CortexFlow. Kostenlose n8n-Vorlagen finden Sie auf cortexflow.tech unter Templates.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 16 • Originally published at cortexflow.tech
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.
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" Enter fullscreen mode Exit fullscreen mode Or check from the host if you installed with pip:
pip show litellm | grep -E "Name|Version" Enter fullscreen mode Exit fullscreen mode 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 Enter fullscreen mode Exit fullscreen mode The pip show output must read 1.83.9 or higher. For pip installs, upgrade in place:
pip install --upgrade "litellm>=1.83.9" Enter fullscreen mode Exit fullscreen mode 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.
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 (reporting Check Point's disclosure, Oct 15, 2026).
Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/