Causa raiz

O Langflow permite que um usuário registre servidores stdio MCP (Model Context Protocol) externos via POST /api/v2/mcp/servers/{name}. O corpo da requisição é validado por MCPServerConfig (src/backend/base/langflow/api/v2/schemas.py), que é cuidadoso com command, args e com as chaves de env:

• command deve estar em uma lista de permitidos (node, python, npx, uvx, docker, sh, bash…).
• args são verificados quanto a metacaracteres de shell (;, |, $, `, (, ), …) e palavras-chave perigosas (-c, eval, pip install, …).
• as chaves de env são verificadas contra DANGEROUS_ENV_VARS (LD_PRELOAD, PATH, NODE_OPTIONS, PYTHONPATH, BASH_ENV, …).

Duas lacunas se combinam para viabilizar RCE:

1. Os valores de env nunca são saneados. Apenas as chaves são verificadas contra a lista de bloqueio; os valores são repassados literalmente. Assim, um valor $(id) em PS4 sobrevive mesmo que os exatos mesmos caracteres fossem rejeitados dentro de args.

2. A lista de bloqueio está incompleta. Na 1.10.1, DANGEROUS_ENV_VARS não contém shellopts, bashopts ou ps4.

O launcher (src/lfx/src/lfx/base/mcp/util.py) então executa, no Unix:

Com SHELLOPTS=xtrace, o bash ativa set -x na inicialização e, antes de executar a primeira linha rastreada, expande o prompt PS4. A substituição de comando dentro de PS4, portanto, é executada imediatamente — independentemente de command/args, que nem precisam ser válidos.

A correção (1.10.2)

A lista de bloqueio é centralizada em src/lfx/src/lfx/base/mcp/util.py como DANGEROUS_MCP_ENV_VARS e ganha shellopts, bashopts, ps4 (além de env, como defesa em profundidade). schemas.py agora chama is_dangerous_mcp_env_var(). O registro abaixo é rejeitado com HTTP 422 na 1.10.2.

Prova de conceito

A cadeia HTTP bruta:

--ps4 fornece uma primitiva bruta para shells reversos / callbacks OAST:

Reproduzir o laboratório

Comportamento na versão corrigida (rejeitado):

Veja EVIDENCE.txt para a transcrição completa capturada e ANALYSIS.md para a análise detalhada em nível de código-fonte.

Veredito

CONFIRMADO VULNERÁVEL em langflowai/langflow:1.10.1, verificado por duas técnicas independentes:

1. Escrita de arquivo com saída resolvida — um arquivo que não existia antes da requisição contém uid=1000(user) gid=0(root) groups=0(root), a saída real de id(1) resolvida contra o /etc/passwd do alvo. Isso não é um eco da string de entrada $(id …).
2. Callback TCP fora de banda — o alvo estabelece uma conexão de volta a um listener do atacante, carregando seu hostname e kernel reais (CALLBACK user@vbox 6.18.12+kali-amd64).

CORRIGIDO em langflowai/langflow:1.10.2 — o mesmo registro retorna HTTP 422.

Nota sobre a alegação de não autenticado. A imagem 1.10.1 é distribuída com AUTO_LOGIN ativado por padrão, portanto /api/v1/auto_login retorna um token de superusuário para qualquer chamador, sem credenciais — é isso que torna toda a cadeia não autenticada em uma implantação padrão. Em uma instância onde a autenticação é aplicada, o mesmo RCE é alcançável por qualquer usuário autenticado com um token/chave de API válido (passe-o via --token). A imagem 1.10.2 adicionalmente exige credenciais para iniciar, um hardening não relacionado.

Impacto

Execução arbitrária de comandos como a conta de serviço do Langflow. Leitura completa de todos os segredos, credenciais e flows no banco de dados do Langflow, acesso a serviços internos e metadados de nuvem e um pivô para a rede ao redor.

Remediação

• Atualize para Langflow OSS ≥ 1.10.2.
• Não exponha o Langflow a redes não confiáveis com AUTO_LOGIN ativado; defina credenciais explícitas de superusuário e desative o login automático.
• Defesa em profundidade: execute o serviço sob uma conta restrita, sem saída de rede externa.

Detecção

Procure por registros de servidores MCP cujo env contenha variáveis de controle de shell e por processos filhos bash do processo Langflow:

Sigma (criação de processos):

Licença

© Caio Fabrício (BiiTts).