Langflow <= 1.6.9 CORS Misconfiguration to Token Hijack & RCE

Falha de encadeamento em Langflow, plataforma open-source de agentes e workflows de IA com mais de 140 mil estrelas no GitHub: uma configuração de CORS que reflete qualquer origem com credenciais habilitadas, somada a um cookie de refresh token configurado como SameSite=None, permite que uma página maliciosa capture tokens de sessão de uma vítima logada. Como o Langflow expõe endpoints autenticados que executam código Python arbitrário por design, o roubo de token vira RCE completo no servidor. O CVSS 4.0 de 9.4 reflete corretamente a severidade final, mas o vetor real depende de engenharia social (a vítima precisa clicar em um link) e de uma configuração padrão vulnerável que passou a ser corrigida a partir da versão 1.7.

A cadeia tem três componentes, cada um documentado pela Obsidian Security. Primeiro, o middleware CORS do Langflow (baseado em FastAPI) responde com allow_origins='*' e allow_credentials=True — combinação que navegadores modernos normalmente bloqueiam, mas que frameworks web mal configurados às vezes permitem via reflexão dinâmica da origem recebida. Segundo, o cookie que guarda o refresh token é emitido com SameSite=None, o atributo que existe justamente para permitir envio cross-site — sem ele, o navegador não enviaria o cookie em uma requisição originada de outro domínio. Terceiro, o endpoint de refresh de token não tem proteção CSRF própria (token anti-CSRF, verificação de origem server-side, etc.), então aceita qualquer requisição que chegue com o cookie válido, independentemente de onde ela partiu. Isso é classificado como CWE-346 (Origin Validation Error).

A exploração exige que a vítima tenha uma sessão ativa no Langflow (cookie de refresh válido no navegador) e seja induzida a visitar uma página controlada pelo atacante enquanto essa sessão está viva — é o UI:P do vetor CVSS. A página maliciosa executa uma requisição cross-origin com credentials:'include' contra o endpoint de refresh do Langflow; como o CORS reflete a origem do atacante e aceita credenciais, o navegador da vítima entrega o cookie, e a resposta — legível pela página maliciosa por causa do CORS permissivo — contém um par access_token/refresh_token novo e válido. A partir daí o atacante já não precisa mais do navegador da vítima nem de acesso à mesma rede: ele usa os tokens diretamente para chamar endpoints autenticados da API do Langflow, incluindo o endpoint de validação/execução de código que já foi alvo de outra CVE anterior (CVE-2025-3248) e que, por design, executa Python arbitrário no processo do servidor.

A CrowdSec confirmou exploração ativa em ambiente real a partir de 23 de janeiro de 2026, descrevendo operação provavelmente orquestrada em escala profissional. Um detalhe relevante para quem monitora: como o vetor depende do navegador da vítima fazendo a requisição, os IPs observados em logs de acesso são os das vítimas (em faixas residenciais), não da infraestrutura do atacante — o que dificulta medir o alcance real da campanha e dificulta bloqueio por IP.

A correção definitiva é atualizar o Langflow. A CrowdSec indica que a partir da versão 1.7 a configuração padrão de CORS já não é vulnerável a este vetor. O catálogo KEV da CISA referencia a release v1.9.3 como o ponto de correção associado à CVE. Há uma inconsistência de granularidade entre fontes sobre exatamente onde a cadeia foi fechada por completo — recomenda-se, além de atualizar, verificar manualmente a configuração de CORS e do cookie após o upgrade, em vez de confiar apenas no número de versão.

Se a atualização imediata não for possível, o paliativo real é de configuração, não de rede: definir a variável de ambiente LANGFLOW_CORS_ALLOW_CREDENTIALS=False desativa o envio de credenciais em requisições cross-origin, quebrando o elo central da cadeia. Onde isso não for viável (por exemplo, se alguma integração legítima depender de credenciais cross-origin), restringir LANGFLOW_CORS_ORIGINS a uma lista explícita de hosts confiáveis reduz a superfície, embora não elimine o risco caso um desses hosts confiáveis seja comprometido. Um WAF genérico não mitiga isso de forma confiável, porque o ataque ocorre no navegador da vítima contra um endpoint legítimo com credenciais legítimas — não há payload malformado para uma assinatura de WAF detectar.

O sinal mais direto seria requisições cross-origin ao endpoint de refresh token do Langflow com cabeçalho Origin apontando para domínios fora da lista de origens confiáveis do ambiente, seguidas em curto intervalo por chamadas ao endpoint de validação/execução de código usando o token recém-emitido — esse padrão (refresh a partir de origem estranha + uso imediato do token em endpoint de execução) é o indicador de comprometimento mais confiável disponível. Vale notar a limitação apontada pela CrowdSec: como a requisição maliciosa parte do navegador da vítima, os endereços IP registrados nos logs do servidor são das vítimas, tipicamente em faixas residenciais, e não da infraestrutura do atacante — bloqueio ou triagem por IP de origem não identifica o atacante e pode até penalizar usuários legítimos enganados.