Warum Lucairn keine
Credentials-Tabellen-Verletzung zu befürchten hat.
Im April 2026 wurde LiteLLM CVE-2026-42208 — CVSS 9.3, Pre-auth SQL-Injection — innerhalb von 36 Stunden nach Offenlegung ausgenutzt. Angreifer haben die Tabelle litellm_credentials ausgelesen: Workspace-Admin-Schlüssel für Anthropic, OpenAI, AWS Bedrock. Der Breach ist nicht passiert, weil das LiteLLM-Team eine schlechte Entscheidung getroffen hat; er ist passiert, weil die architektonische Klasse — KI-Gateway mit geteiltem Credentials-Backend — einen Single Point of Failure hat, den jeder Pre-auth-Bug freilegt. Lucairn liefert eine andere Klasse. Diese Seite erklärt den Unterschied, in fünf Punkten und einer Vergleichstabelle.
Eine Pre-auth-SQLi,
und eine Tabelle zum Auslesen.
CVE-2026-42208 war eine nicht authentifizierte SQL-Injection im Authentifizierungspfad von LiteLLM. Der Injection-Punkt erreichte die Spalte litellm_credentials.credential_values — die Tabelle, die Workspace-Admin-Schlüssel für Upstream-LLM-Anbieter (Anthropic, OpenAI, AWS Bedrock) hält. Angreifer haben die Tabelle ins Visier genommen, entschlüsselt was möglich war, und sind direkt in Anthropic- / OpenAI- / Bedrock-Umgebungen der Kunden über die gestohlenen Schlüssel weitergesprungen. NVD veröffentlichte im April 2026; aktive Exploitation folgte innerhalb von ~36 Stunden.
Der tragende Befund: das ist kein LiteLLM-spezifisches Bug-Muster. Jedes KI-Gateway, das ein geteiltes Credentials-Backend hält, hat dieselbe architektonische Exponierung. Der Schadensradius liegt in der Credentials-Tabelle, nicht in der SQLi konkret. Ein Pre-auth-Bug — SQLi, Deserialisierung, Auth-Bypass, File-Traversal — in jedem Gateway dieser Form legt alle Upstream-Schlüssel aller Kunden gleichzeitig offen.
BYOK-Passthrough,
durch Konstruktion.
Das Lucairn-Gateway persistiert keine Upstream-LLM-Schlüssel. Die Architektur ist geradlinig:
- Pro Anfrage, nie gespeichert. Kunden senden ihren Upstream-Schlüssel pro Anfrage via X-Upstream-Key-Header (BYOK-Passthrough). Der Schlüssel wird einmal gelesen, zur Authentifizierung beim Upstream-Anbieter (Anthropic, OpenAI, Mistral) verwendet, dann verworfen.
- Keine lucairn_credentials-Tabelle. Es gibt keinen geteilten Backend-Speicher für LLM-Schlüssel von Kunden. Nichts, was ein Angreifer auslesen könnte.
- Im Code verifiziert. Die Bedingung ist an der Proxy-Grenze festgehalten. Aus src/app/api/sandbox/run/route.ts:32 — `// - BYOK key NEVER persisted, NEVER logged.`
- Lucairn-API-Schlüssel sind anders gefasst. Lucairn mintet eigene Gateway-API-Schlüssel (lcr_live_*) für Rate-Limiting und Kontingente — aber das sind Gateway-API-Schlüssel, keine Upstream-LLM-Schlüssel. Eine Kompromittierung bleibt auf die Gateway-Aufrufrate des Kunden begrenzt, nicht auf seine Cloud-LLM-Rechnung.
Die Architektur ist der Schutz. Code, der ein Geheimnis nicht speichert, kann dieses Geheimnis nicht leaken.
Fünf Eigenschaften,
die im Spec-Sheet zählen.
Jeder Punkt unten ist eine echte, beschaffungsrelevante Eigenschaft, die ein Sicherheits- oder Compliance-Prüfer im Lieferanten-Fragebogen abhaken kann. Keine erfordert, Lucairn etwas zu glauben, das nicht im Gateway-Code steht.
Schadensradius nach einem Pre-auth-Bug.
Shared-Cred-Gateway: alle Upstream-LLM-Schlüssel aller Kunden leaken in einem einzigen Dump. BYOK-Passthrough: keinerlei Credentials-Exposition — das Gateway hat nichts zum Leaken.
Wiederherstellungszeit.
Shared-Cred: Upstream-Schlüssel jedes Kunden bei jedem Cloud-LLM-Anbieter rotieren, Erkennungsregeln nachschärfen, sich bei N Enterprise-Kunden entschuldigen. BYOK-Passthrough: der Bug wird gepatcht. Keine Upstream-Schlüssel-Rotation nötig.
Beweisspur.
Shared-Cred: Gateway-Logs sind die einzige Geschichte, welcher Kunde welchen Upstream-Schlüssel wann benutzt hat. BYOK-Passthrough: die eigene Anbieter-Konsole des Kunden (Anthropic-, OpenAI-Dashboards) zeigt das vollständige Bild; das Gateway ist für den Upstream-API-Audit-Trail beiläufig.
Erste Frage des Aufsehers.
„Zeigen Sie mir den Datenfluss.“ Shared-Cred-Antwort: eine Credentials-Tabelle steht im Scope, hält Cross-Customer-Geheimnisse. BYOK-Passthrough-Antwort: eine solche Tabelle existiert nicht; der Upstream-Schlüssel-Fluss ist pro Anfrage, im Speicher, nach dem Aufruf verworfen.
Versicherung und AVV-Exposition.
Ein Shared-Cred-Gateway-Breach ist ein meldepflichtiger Vorfall nach Artikel 33 DSGVO für jeden betroffenen Kunden (deren Upstream-LLM-Credentials sind die geleakten personenbezogen-adjazenten Geheimnisse). BYOK-Passthrough: ein Breach auf Lucairn-Seite legt Kunden-LLM-Schlüssel überhaupt nicht offen, was die Meldepflicht-Fläche auf das verengt, was das Gateway sonst noch hielt.
Shared-Cred-Gateway
vs. Lucairn-BYOK-Passthrough.
Acht Eigenschaften, nach denen ein Beschaffungsprüfer typischerweise fragt. Lesen Sie die Spalte, die Sie in einem Audit lieber verteidigen würden.
| Eigenschaft | Shared-Cred-KI-Gateway | Lucairn-BYOK-Passthrough |
|---|---|---|
| Speicherung des Upstream-LLM-Schlüssels | In einer Credentials-Tabelle persistiert, pro Anfrage referenziert | Nie persistiert. Aus dem Header gelesen, einmal benutzt, verworfen |
| Schadensradius eines Pre-auth-Bugs | Upstream-Schlüssel jedes Kunden in einem Dump exponiert | Keine Credentials-Tabelle zum Auslesen. Bug wird in place gepatcht |
| Schlüsselrotation nach Anbieter-Breach | Kunde muss jeden Upstream-LLM-Schlüssel bei jedem Anbieter rotieren | Keine Upstream-Schlüssel-Rotation nötig |
| Audit-Trail der Upstream-Schlüssel-Nutzung | Beim Gateway | Beim Kunden, beim Upstream-Anbieter (Anthropic-/OpenAI-Konsole) |
| DSGVO-Art.-33-Meldefläche (Anbieter-Seite) | Jeder betroffene Kunde (Cross-Customer-Geheimnis-Leak) | Kein Upstream-Schlüssel-Leak; Fläche verengt auf andere Gateway-Daten |
| Datenfluss-Antwort an den Aufseher | Ein geteiltes Credentials-Backend liegt im Scope | Pro-Anfrage-Passthrough, kein geteiltes Backend |
| Lucairn-API-Schlüssel (lcr_live_*) | — | Gespeichert, nur für Rate-Limiting und Kontingente verwendet. Kompromittierung auf die Gateway-Aufrufrate des Kunden begrenzt |
| Code-Referenz | Implementierungsspezifisch | src/app/api/sandbox/run/route.ts:32 — `// - BYOK key NEVER persisted, NEVER logged.` |
Der ehrliche Scope
dieses Vorteils.
- Lucairn behauptet keine Immunität gegen alle KI-Gateway-Risiken. Das Gateway hat seine eigenen Bugs zu beachten — Input-Parsing, Sanitizer-Regressionen, Prompt-Injection-via-Header, Abhängigkeits-CVEs. Jeder davon hat seinen eigenen Mitigation-Track und seine eigene Vorfallhistorie.
- BYOK-Passthrough schützt nur, was im Scope ist. Kunden-Prompts fließen weiterhin durch Lucairns Pipeline, werden sanitisiert und erhalten signierte Belege. Diese Pipeline hat ihre eigenen Fehlermodi, an anderer Stelle auf dieser Seite dokumentiert (siehe /security und /compliance/eu-ai-act).
- Der architektonische Vorteil ist konkret. Die CVE-2026-42208-Klasse — Credentials-Tabellen-Kompromittierung — ist in Lucairns Modell strukturell nicht möglich, weil die Tabelle nicht existiert. Das ist eine echte Reduktion des Schadensradius. Es ist keine Aussage über jede andere Schwachstellenklasse, und es ist keine Aussage darüber, dass Lucairn nach einem Standard zertifiziert wäre.
Den Proxy ausprobieren
oder einen echten Beleg prüfen.
Die architektonische Aussage ist überprüfbar. Die Sandbox zeigt den BYOK-Passthrough-Fluss von Anfang bis Ende; die Verify-Seite lässt Sie ein echtes signiertes Zertifikat prüfen, ohne Lucairn zu kontaktieren.
REFERENZEN
- NVD · CVE-2026-42208
- Sysdig · CVE-Bericht
- src/app/api/sandbox/run/route.ts:32 (im Repo)