Könnten Ihre API-Keys offengelegt sein?
Im Oktober 2026 wurden drei Vorfälle bekannt, die Secrets von Kunden betreffen: die Umgebungsvariablen bei Railway, LiteLLM-Version 1.107.0 mit einem Credential Stealer und die verschlüsselten API-Keys von TiDB Cloud.
Wir erfassen Ihre Secrets, rotieren sie in einer Reihenfolge, die das größte Risiko zuerst abstellt, widerrufen die alten, prüfen, ob jemand sie genutzt hat, und verlagern sie in einen Secrets Manager mit kurzlebigen Tokens.
# Welche LiteLLM-Version ist installiert?$ pip show litellm | grep -i ^versionVersion: 1.107.0# 1.107.0 ist die bösartige Version, am 21.10. auf PyPI und Docker Hub veröffentlicht$ docker images | grep -i litellm$ grep -rn "litellm" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null# Letzte saubere Version im Lockfile und in den Images festschreiben$ pip install "litellm==1.106.2"# Die Version festzuschreiben säubert die Maschine nicht: alle erreichbaren Secrets rotierenDrei Vorfälle, dieselbe offene Aufgabe
In allen drei Fällen hat der Anbieter seinen Teil erledigt, und die Rotation des Offengelegten liegt beim Kunden: Der Anbieter kann weder Ihren Stripe- noch Ihren OpenAI-Schlüssel ändern.
Railway
Am 21. Oktober wurde ungewöhnliche Aktivität in den Systemen festgestellt, die die Umgebungsvariablen der Kunden speichern. Ein Dritter konnte auf verschlüsselte Variablen zugreifen und sie teilweise entschlüsseln. Railway hat alle Deployments pausiert und bittet um Rotation. Zahl der Betroffenen und Angriffsweg sind nicht veröffentlicht. Quelle.
LiteLLM 1.107.0
Am 21. Oktober erschien auf PyPI und Docker Hub eine bösartige 1.107.0: Sie stiehlt Zugangsdaten und lädt Fremdcode nach, sobald irgendein Python-Prozess startet. Die Angreifer nutzten GitHub-CLI-OAuth-Tokens, die drei Entwicklern gestohlen wurden; der GitHub-Tag ist sauber. Es ist das zweite Mal in diesem Jahr. Quelle: Wiz.
PingCAP / TiDB Cloud
Zwischen dem 9. September und dem 7. Oktober nutzte ein Dritter gestohlene Zugangsdaten eines Dienstkontos und kopierte Konto- und Projektmetadaten, Texte aus dem SQL-Editor, Abrechnungsdaten und verschlüsselte API-Key-Werte. Keine Hinweise auf Auswirkungen auf die in TiDB gespeicherten Daten. Quelle: PingCAP.
Sechs Schritte, von der Bestandsaufnahme bis zu kurzlebigen Tokens
Die ersten vier sperren den Zugriff und messen den Schaden. Die letzten beiden ändern, wie Sie Secrets aufbewahren, damit das nächste Leck weniger betrifft und kürzer dauert.
- 01
Bestandsaufnahme der Secrets
PaaS-Variablen, .env-Dateien, CI-Secrets, Schlüssel in Docker-Images und im Code. Für jedes: worauf es Zugriff gibt und an wie vielen Stellen es liegt.
- 02
In Reihenfolge rotieren
KI-Anbieter, Cloud, Datenbanken, Zahlungsanbieter und CI-Tokens. Zuerst das, was sich am schnellsten in Verbrauch oder Zugriff auf weitere Secrets verwandelt.
- 03
Alte widerrufen
Ein Schlüssel, den Sie nicht mehr nutzen, der aber aktiv ist, ist für jeden mit Zugriff genauso viel wert. Wir prüfen bei jedem Anbieter, dass der alte widerrufen ist.
- 04
Nutzungslogs prüfen
Verbrauch bei den KI-Anbietern, CloudTrail oder das Audit-Log Ihrer Cloud, Datenbankzugriffe und das Stripe-Dashboard, im Zeitraum der Offenlegung.
- 05
Secrets Manager
Wir verlagern die Secrets in einen Manager (den Ihrer Cloud, Vault oder Doppler), damit jedes an einer Stelle liegt und Rotieren heißt, einen Wert zu ändern.
- 06
Kurzlebige Tokens
Wo der Anbieter es erlaubt, holen sich CI und Dienste temporäre Zugangsdaten (OIDC, IAM-Rollen), statt Schlüssel ohne Ablaufdatum zu speichern.
Was zuerst rotiert wird und warum
LiteLLM ist ein Proxy vor den Modellanbietern, daher hat eine Maschine, auf der es läuft, meist die KI-Schlüssel griffbereit. Mit einem gestohlenen KI-Schlüssel lässt sich in Minuten Verbrauch auf Ihre Kosten erzeugen, und ein Cloud-Schlüssel öffnet den Rest.
CI-Tokens stehen am Ende der Liste, weil wir sie zum Ausrollen der vorherigen Änderungen nutzen. Gibt es Hinweise, dass die CI selbst kompromittiert ist, rücken sie nach vorn, und wir rollen in der Zwischenzeit von anderer Stelle aus.
Erstellen, ausrollen, widerrufen, prüfen
Wird widerrufen, bevor der neue Schlüssel ausgerollt ist, fällt die Anwendung aus. Wird der neue ausgerollt und der alte nicht widerrufen, bleibt das Leck offen.
Weniger Stellen, an denen ein Schlüssel liegt
Am längsten dauert bei einer Notfallrotation herauszufinden, wo jeder Schlüssel liegt. Mit einem Secrets Manager existiert diese Bestandsaufnahme schon vor dem Vorfall.
- Derselbe API-Key liegt im PaaS, auf zwei Laptops und in der CI
- Niemand weiß, an wie vielen Stellen er für eine Rotation geändert werden muss
- Schlüssel laufen nie ab: einer, der vor einem Jahr geleakt wurde, funktioniert noch
- Kein Protokoll, wer welches Secret wann gelesen hat
- Jedes Secret liegt an einer Stelle (AWS Secrets Manager, Vault, Doppler oder der Dienst Ihrer Cloud), und die Anwendungen lesen es dort
- Rotieren heißt: einen Wert ändern und neu ausrollen
- Die CI bezieht per OIDC temporäre Zugangsdaten, statt dauerhafte Schlüssel zu speichern
- Der Manager protokolliert Zugriffe, und genau das prüft man bei einem Vorfall zuerst
Nutzen Sie Railway, LiteLLM oder TiDB Cloud?
Schreiben Sie uns →Häufige Fragen zu offengelegten Zugangsdaten
Wir nutzen Railway. Müssen wir alles rotieren?
Wir haben LiteLLM 1.107.0. Reicht ein Downgrade auf 1.106.2?
Was tun, wenn wir TiDB Cloud nutzen?
Warum diese Reihenfolge?
Sind wir nach der Rotation sicher?
Wir beginnen mit der Bestandsaufnahme
Sagen Sie uns, wo Sie deployen und welche Anbieter Sie nutzen. Daraus erstellen wir die Liste der zu rotierenden Secrets samt Reihenfolge, und Sie entscheiden, ob wir sie abarbeiten oder Ihr Team.
Erzählen Sie uns Ihre Herausforderung. Wir schlagen die Lösung vor.
Unverbindlich. Innerhalb von 24 Stunden erhalten Sie ein Angebot mit Umfang, Zeitplan und Budget. Ohne Kleingedrucktes.