Causa principale

Langflow consente a un utente di registrare server MCP (Model Context Protocol) stdio esterni tramite POST /api/v2/mcp/servers/{name}. Il corpo della richiesta viene validato da MCPServerConfig (src/backend/base/langflow/api/v2/schemas.py), che controlla attentamente command, args e le chiavi delle env:

• command deve essere in una allowlist (node, python, npx, uvx, docker, sh, bash…).
• args vengono scansionati per metacaratteri shell (;, |, $, `, (, ), …) e keyword pericolose (-c, eval, pip install, …).
• le chiavi delle env vengono verificate contro DANGEROUS_ENV_VARS (LD_PRELOAD, PATH, NODE_OPTIONS, PYTHONPATH, BASH_ENV, …).

Due lacune combinate portano alla RCE:

1. I valori delle env non vengono mai sanitizzati. Solo le chiavi vengono controllate contro la blocklist; i valori vengono passati verbatim. Quindi un valore PS4 di $(id) sopravvive anche se esattamente gli stessi caratteri verrebbero rifiutati dentro args.

2. La blocklist è incompleta. Nella 1.10.1 DANGEROUS_ENV_VARS non contiene shellopts, bashopts o ps4.

Il launcher (src/lfx/src/lfx/base/mcp/util.py) quindi esegue, su Unix:

Con SHELLOPTS=xtrace bash abilita set -x all'avvio e, prima di eseguire la prima riga tracciata, espande il prompt PS4. La sostituzione di comando dentro PS4 viene quindi eseguita immediatamente — indipendentemente da command/args, che non devono nemmeno essere validi.

La correzione (1.10.2)

La blocklist è centralizzata in src/lfx/src/lfx/base/mcp/util.py come DANGEROUS_MCP_ENV_VARS e guadagna shellopts, bashopts, ps4 (più env, difesa in profondità). schemas.py ora chiama is_dangerous_mcp_env_var(). La registrazione seguente viene rifiutata con HTTP 422 sulla 1.10.2.

Proof of concept

La catena HTTP grezza:

--ps4 fornisce una primitiva grezza per reverse shell / callback OAST:

Riprodurre il lab

Limite della versione corretta (rifiuto):

Vedi EVIDENCE.txt per la trascrizione completa catturata e ANALYSIS.md per l'analisi a livello di sorgente.

Verdetto

CONFERMATO VULNERABILE su langflowai/langflow:1.10.1, verificato con due tecniche indipendenti:

1. Scrittura di file con output risolto — un file che non esisteva prima della richiesta contiene uid=1000(user) gid=0(root) groups=0(root), il vero output di id(1) risolto contro il /etc/passwd del target. Non è un eco della stringa di input $(id …).
2. Callback TCP out-of-band — il target richiama un listener dell'attaccante portando il proprio hostname e kernel reali (CALLBACK user@vbox 6.18.12+kali-amd64).

CORRETTO su langflowai/langflow:1.10.2 — la stessa registrazione restituisce HTTP 422.

Nota sull'affermazione di non autenticazione. L'immagine 1.10.1 viene fornita con AUTO_LOGIN abilitato di default, quindi /api/v1/auto_login restituisce un token da superuser a qualsiasi chiamante senza credenziali — questo è ciò che rende l'intera catena non autenticata su una distribuzione predefinita. Su un'istanza in cui l'autenticazione è imposta, la stessa RCE è raggiungibile da qualsiasi utente autenticato con un token/chiave API valido (passalo tramite --token). L'immagine 1.10.2 richiede inoltre credenziali per avviarsi, un indurimento non correlato.

Impatto

Esecuzione arbitraria di comandi come account di servizio Langflow. Lettura completa di ogni segreto, credenziale e flusso nel database di Langflow, accesso ai servizi interni e ai metadata cloud, e un pivot nella rete circostante.

Rimedio

• Aggiorna a Langflow OSS ≥ 1.10.2.
• Non esporre Langflow a reti non fidate con AUTO_LOGIN abilitato; imposta credenziali esplicite da superuser e disabilita il login automatico.
• Difesa in profondità: esegui il servizio con un account ristretto senza uscita di rete verso l'esterno.

Rilevamento

Cerca registrazioni di server MCP il cui env contiene variabili di controllo della shell e processi bash figli del processo Langflow:

Sigma (creazione di processi):

Licenza

© Caio Fabrício (BiiTts).