rickidevs/cve-2026-34070# Ich habe eine Zero-Day-Schwachstelle in langchain gefunden – So ist es abgelaufen
Wie eine vergessene Legacy-API in einem der beliebtesten KI-Frameworks Millionen von Anwendungen stillschweigend für beliebige Dateilesevorgänge exponiert hat.
Es gibt ein bestimmtes Gefühl, das man bekommt, wenn ein Proof-of-Concept beim ersten Versuch funktioniert. Nicht gerade Aufregung – eher eine langsame, unbehagliche Erkenntnis, dass gerade etwas Reales passiert ist. Genau so fühlte es sich an, als ich meine Testkonfiguration gegen load_prompt_from_config() laufen ließ und zusah, wie der Inhalt einer Datei, die es nichts anzugehen hatte, direkt in meinem Terminal ausgegeben wurde.
Dies ist die Geschichte von CVE-2026-34070: eine Path-Traversal-Schwachstelle in langchain-core, die in Version 1.2.22 gepatcht wurde.
Wenn du in den letzten Jahren irgendetwas mit KI gebaut hast, hast du mit ziemlicher Sicherheit LangChain angefasst. Es ist das verbindende Gewebe des modernen KI-Stacks – das Framework, das Sprachmodelle, Vektor-Datenbanken, Tools und Prompt-Verwaltung zu kohärenten Anwendungen verdrahtet. Mit über 130k Sternen auf GitHub und einer Verbreitung von kleinen Wochenendprojekten bis hin zu Enterprise-Deployments bleibt eine Schwachstelle hier nicht isoliert.
Ich hatte gerade eine Code-Review des Prompts-Subsystems durchgeführt, als mir etwas ins Auge fiel: ein Modul namens langchain_core/prompts/loading.py. Es lud Dateien von der Festplatte, basierend auf Werten, die direkt aus deserialisierten Konfigurations-Dictionaries gezogen wurden. Keine Validierung. Keine Pfad-Bereinigung. Nur .
open(path)Ich las weiter.
Drei interne Funktionen standen im Zentrum davon:
_load_template() – liest Dateien, auf die template_path, suffix_path und prefix_path verweisen_load_examples() – liest Dateien, auf die der examples-Schlüssel verweist, wenn er ein String ist_load_few_shot_prompt() – liest Dateien, auf die example_prompt_path verweistDie Dateiendungs-Prüfungen waren vorhanden. .txt für Templates. .json, .yaml, .yml für Beispiele. Aber es gab nichts, das diese Pfade daran hinderte, absolut (/etc/passwd) oder traversal-basiert (../../../../home/user/.ssh/) zu sein. Der Endungs-Filter gab ein falsches Sicherheitsgefühl – er bedeutete nur, dass ein Angreifer die richtige Endung wählen musste, nicht dass der Angriff blockiert war.
Diese Funktionen sind alle über zwei öffentlich zugängliche APIs erreichbar: load_prompt() und load_prompt_from_config().
Die einfachste Version sah so aus:
from langchain_core.prompts.loading import load_prompt_from_config
config = {
"_type": "prompt",
"template_path": "/tmp/secret.txt",
"input_variables": [],
}
prompt = load_prompt_from_config(config)
print(prompt.template) # Inhalt von /tmp/secret.txt, sauber ausgegeben
Das war's. Gib einen absoluten Pfad ein, erhalte den Dateiinhalt zurück, verpackt in einer PromptTemplate. Keine Authentifizierung. Keine speziellen Privilegien. Wenn du das Config-Dictionary beeinflussen kannst, kannst du Dateien lesen.
Directory Traversal funktionierte genauso sauber:
config = {
"_type": "prompt",
"template_path": "../../etc/secret.txt",
"input_variables": [],
}
Die JSON/YAML-Variante war wohl gefährlicher, wegen der Art von Dateien, die sie erreichen konnte:
config = {
"_type": "few_shot",
"examples": "../../../../.docker/config.json",
"example_prompt": {
"_type": "prompt",
"input_variables": ["input", "output"],
"template": "{input}: {output}",
},
"prefix": "",
"suffix": "{query}",
"input_variables": ["query"],
}
prompt = load_prompt_from_config(config)
.docker/config.json enthält deine Docker-Hub-Zugangsdaten. ~/.azure/accessTokens.json hat deine Azure-Tokens. Kubernetes-Manifeste, CI/CD-Konfigurationen, interne Anwendungseinstellungen – alles mit der richtigen Endung, das irgendwo im Dateisystem liegt, war Freiwild.
Der CVSS-Score kam bei 7.5 High heraus, mit einem Vektor von AV:N/AC:L/PR:N/UI:N – netzwerkzugänglich, geringe Komplexität, keine Privilegien, keine Benutzerinteraktion erforderlich.
Der Score ist unter 9+ begrenzt, weil die Dateiendungs-Prüfung einschränkt, welche Dateien gelesen werden können. Aber 7.5 unterschätzt dennoch die reale Auswirkung in bestimmten Deployment-Mustern.
Denk darüber nach, wo das in der Produktion landet:
load_prompt_from_config() weitergibt, ist jeder Benutzer ein potenzieller Angreifer.In diesen Umgebungen spielt die Einschränkung "durch Dateiendung begrenzt" eine viel geringere Rolle. Ein Angreifer kann einfach Dateien anvisieren, von denen er weiß, dass sie existieren und die richtige Endung haben. Auf einer typischen Cloud-Instanz: requirements.txt, config.yaml, .env.yaml, gemountete Secret-Dateien mit .json-Endungen – die Liste ist lang.
Die betroffenen Funktionen werden im Advisory als "undokumentierte Legacy-APIs" beschrieben. Sie stammen aus der Zeit vor dem aktuellen langchain_core.load-Serialisierungssystem (dumpd/dumps/load/loads), das ein Allowlist-basiertes Modell verwendet und keine Dateisystem-Lesevorgänge durchführt.
Die neuen APIs existieren. Sie sind besser. Aber der alte Code wurde nie aufgeräumt – er lag einfach da, erreichbar, ohne Validierung, wartend.
Das ist ein Muster, das Beachtung verdient. In schnelllebigen Open-Source-Projekten, besonders in solchen, die so schnell gewachsen sind wie LangChain, sammelt sich technische Schuld in den Ecken an. Legacy-Code, der "nie wirklich für Benutzer gedacht war", bekommt nicht dieselbe Prüfung wie die primäre API-Oberfläche. Aber er ist immer noch aufrufbar. Er ist immer noch im Paket. Und wenn er Dateien von der Festplatte liest, ist er eine potenzielle Schwachstelle.
Der Patch kam in langchain-core 1.2.22. Der Fix fügt eine Pfadvalidierung hinzu, die sowohl absolute Pfade als auch ..-Traversal-Sequenzen ablehnt, bevor irgendeine Datei geöffnet wird. Eine Notluke – allow_dangerous_paths=True – ist für Anwendungen verfügbar, die wirklich aus vertrauenswürdigen Pfaden lesen müssen, mit der ausdrücklichen Anerkennung, dass der Aufrufer das Risiko bewusst eingeht.
Die Legacy-APIs wurden mit diesem Release auch formell als veraltet markiert. Sie werden in 2.0.0 vollständig entfernt. Wenn du load_prompt() oder load_prompt_from_config() irgendwo verwendest, migriere jetzt zu den langchain_core.load-Äquivalenten, anstatt auf die breaking change zu warten.
Sofort aktualisieren:
pip install --upgrade langchain-core
Verifiziere, dass du auf 1.2.22 oder neuer bist:
python -c "import langchain_core; print(langchain_core.__version__)"
Wenn du auf LangChain aufbaust, lohnt sich ein schnelles Audit:
load_prompt und load_prompt_from_config in deiner Codebasis. Wenn sie auftauchen, prüfe, was an sie übergeben wird..txt, .json oder .yaml-Endungen auf deinen Instanzen existieren und was sie enthalten.Sicherheits-Bugs in KI-Infrastruktur werden wichtiger werden, nicht weniger, je mehr sensible Workloads diese Systeme verarbeiten. LangChains Team hat gut reagiert – der Fix ist sauber, der Deprecation-Pfad ist klar, und die Advisory-Dokumentation ist gründlich.
Aber es ist eine gute Erinnerung daran, dass die Angriffsfläche einer KI-Anwendung nicht nur das Modell ist. Es ist jede Bibliothek im Stack, jede Legacy-Funktion, die nie aufgeräumt wurde, jede Stelle, an der "der Benutzer wird hier wohl keine nicht vertrauenswürdige Eingabe übergeben" sich als Annahme statt als Garantie herausstellte.
Lies den Code. Besonders die alten Teile.
CVE-2026-34070 wurde dieser Schwachstelle zugewiesen. Das vollständige Advisory ist im LangChain GitHub Security Advisory verfügbar.