Langflow und der stdio-Transport von MCP: wie aus „Werkzeug hinzufügen" eine Shell wurde – und wie man sie schließt

/01Was zu Langflow und MCP-stdio gemeldet wurde

Langflow, ein verbreiteter Open-Source-Baukasten für KI-Agenten und Pipelines, hat im September zwei kritische Sicherheitshinweise zum selben Muster veröffentlicht. Beide betreffen den stdio-Transport des Model Context Protocol (MCP): Ein Benutzer trägt einen „MCP-Server" ein, Langflow startet dafür einen Prozess – und vor den Korrekturen war dieser Prozess ein beliebiger Shell-Befehl auf dem Langflow-Server.

• CVE-2026-105740 (GHSA-7w94-79vh-5mr2, veröffentlicht am 10. September 2026, bei NVD seit 5. Oktober): Jeder angemeldete Benutzer erreicht Codeausführung über „Add MCP Server" mit stdio-Transport. Der Befehl ging ungeprüft an bash -c "exec {command}"; über das env-Feld ließen sich zusätzlich LD_PRELOAD oder PATH setzen. CVSS 9,9. Behoben in 1.9.0.
• CVE-2026-105697 (GHSA-w794-rj3p-xv45, veröffentlicht am 28. September 2026): Dieselbe Klasse über alle anderen Eingänge – MCP-Konfigurationen in Flows, Tweaks und der MCP-Tools-Komponente. Betroffen sind langflow 1.1.2 bis vor 1.10.3, langflow-base 0.1.2 bis vor 0.10.3 und lfx vor 1.10.3. CVSS 9,9. Vollständig behoben in 1.10.3.

Am 15. Oktober berichtete The Hacker News unter Berufung auf den Sicherheitsdienstleister Previdian über Angriffe auf CVE-2026-105740: Nach dessen Honeypot-Daten 1.423 Versuche von 27 IP-Adressen seit dem 19. September, mit einem Anstieg ab dem 11. Oktober. Das ist eine Sekundärmeldung; die Rohdaten sind nicht öffentlich. Im Katalog der aktiv ausgenutzten Schwachstellen der CISA (KEV, Stand 21. Oktober 2026) stehen beide CVEs nicht.

Die Daten erzählen noch etwas anderes: Die korrigierten Versionen sind älter als die Hinweise. Langflow 1.9.0 erschien auf PyPI am 14. April 2026, 1.10.3 am 23. Juli 2026. Wer seit dem Sommer aktualisiert, war geschützt, bevor die Lücke öffentlich hieß. Wer eine Instanz seit dem Frühjahr nicht angefasst hat, steht seit Wochen in einer öffentlichen Anleitung. Aktuell ist 1.12.7 vom 21. Oktober 2026. Die Sammelübersicht zu den früheren Langflow-Lücken steht im Artikel zur CVE-Welle im KI-Stack; hier geht es um das Muster dahinter.

/02Warum stdio ein Prozessstart ist

MCP kennt zwei Standard-Transporte: stdio und Streamable HTTP. Die Spezifikation beschreibt stdio in einem Satz, der für Sicherheitsfragen alles sagt: „The client launches the MCP server as a subprocess." Der Client – hier Langflow – startet den Server als Kindprozess und spricht mit ihm über Standardeingabe und -ausgabe. Eine stdio-Konfiguration ist deshalb nichts anderes als eine Befehlszeile: command plus args plus env.

In einem Desktop-Werkzeug ist das unproblematisch. Der Benutzer startet auf seinem eigenen Rechner einen Prozess mit seinen eigenen Rechten; er hätte den Befehl auch selbst ins Terminal tippen können. In einer Serveranwendung mit mehreren Benutzern kippt das: Wer eine MCP-Konfiguration anlegen darf, darf auf dem Server einen Prozess starten – mit den Rechten des Serverdienstes, mit dessen Umgebungsvariablen, mit dessen Netzzugang. Aus „Werkzeug hinzufügen" wird „Shell auf dem Server".

Drei Details aus den Advisories machen das Muster gefährlicher, als es auf den ersten Blick wirkt:

• Der Befehl läuft vor dem Handshake. Das MCP-SDK startet den Prozess, bevor überhaupt eine MCP-Nachricht ausgetauscht wird. Die Oberfläche meldet danach „failed to start" – der Befehl ist trotzdem gelaufen.
• Der Befehl läuft beim Auflisten. Laut GHSA-7w94 reicht GET /api/v2/mcp/servers?action_count=true, also das Öffnen der MCP-Einstellungsseite. Jeder Administrator, der nachsieht, was eingetragen ist, löst den Befehl erneut aus.
• Der Befehl ist unsichtbar im Flow. MCP-Konfigurationen liegen in den Projekteinstellungen, nicht im Flow-Editor. Wer Flows prüft, sieht sie nicht.

Dazu kommt die Voreinstellung. Mit LANGFLOW_AUTO_LOGIN=true – laut Advisory der Standard und nur für Entwicklung gedacht – gibt GET /api/v1/auto_login ein Token ohne Anmeldedaten heraus. Eine Instanz in Standardkonfiguration im Netz ist damit ohne Konto angreifbar.

/03Der Fix in zwei Stufen: die API geprüft, die Senke nicht

Lehrreich ist, wie die Lücke geschlossen wurde. GHSA-w794 dokumentiert den Verlauf offen, und er wiederholt sich in vielen Projekten: Erst wird der gemeldete Eingang abgesichert, dann merkt man, dass es weitere Eingänge zur selben gefährlichen Stelle gibt.

Der Unterschied zwischen 1.9.0 und 1.10.3 ist der Kern der Sache. In 1.9.0 prüfte das Datenmodell der REST-API. Die Stelle, an der der Prozess tatsächlich startet – die „Senke" –, nahm aber weiter alles an, was ankam. Jeder Weg, der nicht über dieses Datenmodell lief, war offen. 1.10.3 prüft dort, wo der Schaden entsteht, unmittelbar vor dem Start, und startet den Prozess ohne Shell: shlex.split statt bash -c.

Für die eigene Bewertung heißt das: Eine Prüfung im Formular ist keine Prüfung. Wenn Sie eigene Agenten-Werkzeuge bauen oder einkaufen, fragen Sie, wo die Prüfung sitzt – am Eingang oder an der Senke. Nur die zweite Antwort hält, wenn später ein neuer Eingang dazukommt.

/04Versionscheck und Spurensuche

Die erste Frage ist die Version, die zweite, ob jemand die Lücke schon genutzt hat. Beide lassen sich mit Bordmitteln beantworten. Die Befehle gehen von einem Container namens langflow auf Port 7860 aus.

# 1) Version: über die API (Endpunkt /api/v1/version liefert JSON), im Container oder per pip
curl -s http://127.0.0.1:7860/api/v1/version
docker exec langflow pip show langflow langflow-base lfx 2>/dev/null | grep -E '^(Name|Version)'
pip show langflow | grep '^Version'          # bei Installation in einer venv

# 2) Steht Auto-Login offen? Erwartet bei gehärteter Instanz: kein Token
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:7860/api/v1/auto_login
docker exec langflow sh -c 'echo "LANGFLOW_AUTO_LOGIN=${LANGFLOW_AUTO_LOGIN:-nicht gesetzt (Standard)}"'

# 3) Welche MCP-Server sind eingetragen? (mit einem Admin-Token, OHNE action_count –
#    das würde stdio-Befehle starten)
curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:7860/api/v2/mcp/servers | python3 -m json.tool

# 4) Zugriffe auf die MCP-Konfiguration im Log des Reverse-Proxys
grep -E '(POST|PATCH) /api/v2/mcp/servers' /var/log/nginx/access.log | awk '{print $1, $4, $6, $7}' | sort | uniq -c

# 5) Laufende Kindprozesse des Langflow-Dienstes – alles außer npx/uvx/node/python ist verdächtig
docker top langflow -eo pid,ppid,user,etime,args

Deutung: Eine Version unter 1.10.3 ist das Signal zum Handeln. Liefert Schritt 2 den Status 200, gibt die Instanz Tokens ohne Anmeldung aus. Erwarten Sie nach dem Abschalten einen Fehlercode; Previdian sah in seinen Honeypots laut Sekundärmeldung 403. In Schritt 3 gehört jeder Eintrag auf den Prüfstand, den niemand im Team kennt – besonders Befehle wie bash, sh oder python3 mit -c, und env-Felder mit LD_PRELOAD, PATH oder NODE_OPTIONS. Rufen Sie die Liste ohne action_count=true ab; mit dem Parameter versucht Langflow, die Server zu verbinden, und startet damit genau die Befehle, die Sie suchen.

Laut Sekundärmeldung lasen die beobachteten Angreifer Umgebungsvariablen aus, darunter LANGFLOW_SECRET_KEY und LANGFLOW_SUPERUSER_PASSWORD, und versuchten über Docker-Befehle an das Dateisystem des Hosts zu kommen. Wer eine anfällige Instanz offen im Netz hatte, aktualisiert deshalb nicht nur, sondern tauscht alle Geheimnisse, die im Container sichtbar waren: Secret Key, Superuser-Passwort, API-Schlüssel der angebundenen Modelle und Datenbanken.

/05Härtung ab 1.10.3: Allowlist, Paketliste, strenge Modi

Der Fix schließt beliebige Befehle aus. Erlaubt bleiben laut Advisory node, python, python3, npx, uvx und docker; bash, sh und cmd nur, um einen dieser Befehle einzuwickeln. Dazu kommen Prüfungen auf Shell-Metazeichen in Argumenten und eine Sperrliste gefährlicher Umgebungsvariablen. Ein touch /tmp/x scheitert mit „Command 'touch' is not allowed for security reasons".

Das Advisory sagt selbst, wo die Lücke in der Lücke liegt: npx und uvx dürfen weiterhin jedes Paket starten – so werden MCP-Server üblicherweise verteilt. Wer einen MCP-Server eintragen darf, kann also immer noch beliebigen Code aus npm oder PyPI holen und ausführen lassen. Für Mehrbenutzerbetrieb nennt das Advisory deshalb zusätzliche Schalter; die strengeren Modi kamen mit 1.11.0 – ein Grund mehr, nicht bei 1.10.3 stehen zu bleiben:

# .env bzw. Umgebungsvariablen des Langflow-Dienstes
# (strenge Modi seit 1.11.0, die letzten drei begrenzen stdio-Server ab 1.11.1 auf Superuser)
LANGFLOW_AUTO_LOGIN=false

# Nur diese Pakete dürfen npx/uvx starten (kommagetrennt, exakte Paketnamen)
LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES=@modelcontextprotocol/server-filesystem,mcp-server-fetch

# Interpreter (python -c, node -e, Skripte) und docker-Argumente streng prüfen
LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true
LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true

# Eigenen Code einschränken – begrenzt stdio-MCP-Server zugleich auf Superuser
LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false
LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true
LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true

Die Paketnamen im Beispiel stehen stellvertretend; tragen Sie genau die Server ein, die Ihre Flows brauchen, und pinnen Sie die Version dort, wo das Werkzeug es zulässt. Die Docker-Härtung lehnt laut Quelltext unter anderem --privileged, --cap-add, Host-Namespaces und andere Netzwerke als none, bridge oder default ab – sinnvoll, weil docker in der Allowlist sonst selbst ein Weg auf den Host ist.

In der Praxis bewährt sich eine Regel, die über Schalter hinausgeht: Neue MCP-Server kommen nicht über die Oberfläche, sondern über einen Änderungsantrag. Ein Administrator prüft Paket, Herausgeber und Version, trägt das Paket in die Allowlist ein und dokumentiert, welcher Flow es braucht. Das kostet pro Werkzeug eine Viertelstunde und macht aus einer offenen Liste eine geführte.

/06Containerisierung: Langflow und seine MCP-Prozesse einsperren

Die Allowlist begrenzt, was gestartet werden darf. Der Container begrenzt, was ein gestarteter Prozess anrichten kann. Beides zusammen ist das, was man „Verteidigung in der Tiefe" nennt. Das offizielle Image läuft bereits als Benutzer mit UID 1000 statt root; der Rest ist Startkonfiguration.

docker run -d --name langflow --restart unless-stopped \
  -p 127.0.0.1:7860:7860 \
  --user 1000:0 \
  --cap-drop ALL --security-opt no-new-privileges:true \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=256m \
  -v langflow-data:/app/data \
  --pids-limit 256 --memory 4g \
  --network langflow-net \
  --env-file /etc/langflow/langflow.env \
  langflowai/langflow:1.12.7

# Kein Docker-Socket im Container – sonst ist "docker" in der Allowlist ein Weg auf den Host
docker inspect langflow --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' | grep -c docker.sock
# erwartet: 0

Die Punkte im Einzelnen: Port nur auf 127.0.0.1, davor ein Reverse-Proxy mit Anmeldung. --cap-drop ALL und no-new-privileges verhindern, dass ein gestarteter Prozess sich Rechte holt. --read-only mit einem noexec-tmpfs verhindert, dass ein Angreifer ein Werkzeug nachlädt und startet; prüfen Sie im Test, ob npx-basierte MCP-Server damit noch starten, denn sie wollen meist in ein Cache-Verzeichnis schreiben – dann ein eigenes Volume dafür. --pids-limit und --memory begrenzen Schaden durch Prozessfluten.

Das wichtigste Element ist das Netz. Das Netzwerk langflow-net sollte nur die Ziele erreichen, die Flows wirklich brauchen: das Sprachmodell auf dem GPU-Server, die Vektordatenbank für RAG, freigegebene interne Dienste. Keine Route ins Internet, kein Zugriff auf Metadaten-Endpunkte. Ein Angreifer, der Umgebungsvariablen ausliest, muss sie auch wegschicken können. Wie man ausgehende Verbindungen von Agenten über ein Gateway führt und Zugangsdaten erst dort einsetzt, beschreibt der Artikel zu Egress-Kontrolle und Credential-Injection.

Noch einen Schritt weiter geht, wer stdio auf dem Langflow-Server ganz meidet. MCP-Server lassen sich als eigene Dienste mit Streamable HTTP betreiben, je in einem eigenen Container mit eigenen Rechten; Langflow verbindet sich dann per URL statt per Prozessstart. Für diesen Transport verlangt die Spezifikation, dass Server den Origin-Header prüfen, lokal nur an 127.0.0.1 lauschen und Verbindungen authentifizieren. Die Anleitung dazu steht im Tutorial zum Selbsthosten von MCP-Servern.

/07Grenzen: was Allowlist und Container nicht lösen

Ehrlich: Auch eine gehärtete Langflow-Instanz ist ein Werkzeug, das Code ausführen soll. Die Allowlist schließt die offensichtlichen Wege, aber nicht alle.

• Lieferkette. Ein Paket auf der Allowlist ist so vertrauenswürdig wie sein Herausgeber und seine nächste Version. Wer npx ohne feste Version startet, lädt beim nächsten Start womöglich etwas anderes als gestern.
• Andere Code-Pfade. Langflow hat weitere Funktionen, die Code ausführen. Am selben 28. September erschien GHSA-8qpj-27x8-pwpq (CVSS 9,9, behoben in 1.10.1): Die Python-REPL-Komponente führte Code ohne Sandbox aus. GHSA-9fpm-3445-2vx4 beschreibt, wie Prompt Injection in der Smart-Transform-Komponente zu Codeausführung führen konnte. Das zeigt: Bei agentische-Werkzeugen ist die Grenze zwischen Daten und Befehl dünn.
• Vertrauenswürdige Benutzer. Die Workarounds im Advisory lauten im Kern: Auto-Login aus und Konten nur an vertrauenswürdige Personen. Das ist ehrlich, aber auch ein Eingeständnis. Langflow ist kein Mandantensystem für Fremde.
• Werkzeuge mit Rechten. Ein legitimer MCP-Server mit Dateisystem- oder Datenbankzugriff tut, was das Modell verlangt. Gegen manipulierte Werkzeugbeschreibungen und vergiftete Antworten hilft keine Prozess-Allowlist; das ist das Thema des Artikels zu Tool Poisoning.

Und die Gegenseite: Für einen Entwickler, der Langflow allein auf seinem Notebook nutzt, ohne Netzfreigabe, ist das Muster weitgehend bedeutungslos – er startet ohnehin, was er will. Wer gar kein Langflow betreibt, sondern Function Calling direkt im eigenen Code oder eine feste Agenten-Orchestrierung ohne Benutzerkonfiguration, hat diese Angriffsfläche nicht. Relevant wird sie, sobald mehrere Personen Werkzeuge eintragen dürfen oder die Instanz aus dem Netz erreichbar ist.

/08Entscheidung: welcher Betrieb welche Härtung braucht

Die richtige Tiefe hängt davon ab, wer die Instanz erreicht und wer Werkzeuge eintragen darf – nicht von der Größe des Hauses.

Die meisten Mittelständler, die Langflow einsetzen, landen in der zweiten Zeile: eine Instanz, ein kleines Team, interne Daten. Dort ist der Aufwand überschaubar – ein Update, eine .env-Datei, eine neue Startzeile. Die dritte Zeile ist der Punkt, an dem aus einem Werkzeug eine Plattform wird; dort lohnt es, die Architektur einmal grundsätzlich zu klären, statt Schalter nachzurüsten.

/09Das Muster über Langflow hinaus

Langflow ist der aktuelle Fall, nicht der einzige Ort, an dem das Muster wohnt. Jede Anwendung, die MCP-Server per stdio startet und deren Konfiguration von mehr als einer Person bearbeitet werden kann, hat dieselbe Frage zu beantworten: Wer darf eine Befehlszeile eintragen, und wo wird sie geprüft?

Drei Prüffragen für jedes Werkzeug mit MCP-Anbindung – ob Chat-Oberfläche, Workflow-Baukasten oder selbstgebauter Orchestrator auf LangChain-Basis:

1. Welche Rolle darf stdio-Server eintragen, und ist das in der Rechteverwaltung sichtbar oder eine Nebenwirkung einer anderen Berechtigung?
2. Wird der Befehl direkt gestartet oder über eine Shell? Ein bash -c mit zusammengesetztem String ist ein Warnsignal, auch wenn davor geprüft wird.
3. Sitzt die Prüfung an der Stelle, an der der Prozess startet – oder nur im Formular?

Werkzeugaufrufe ist das, was Agenten nützlich macht. Es ist auch das, was sie gefährlich macht, sobald die Werkzeugliste selbst zur Eingabe wird. Für On-Premise-Betreiber ist das eine gute Nachricht: Die Werkzeugliste liegt in Ihrer Hand. Sie können sie kurz halten, prüfen und versionieren – was bei einem Cloud-Dienst mit offenem Marktplatz für Erweiterungen deutlich schwerer ist. Leitplanken im Modell ersetzen das nicht; sie wirken auf Antworten, nicht auf Prozessstarts.

Das ist keine Formsache: Zwischen dem Fix in 1.9.0 und dem Hinweis lagen fast fünf Monate, zwischen dem vollständigen Fix in 1.10.3 und dessen Hinweis gut zwei. Wer nur auf Advisories reagiert, ist bei Langflow systematisch spät. Wer regelmäßig aktualisiert, war es nicht.