A CVE-2026-33017 afeta instâncias do Langflow até a versão 1.8.1 e já foi explorada em varreduras e coleta de credenciais poucas horas após a divulgação pública.
| Componente | Endpoint POST /api/v1/build_public_tmp/{flow_id}/flow do Langflow, plataforma open source de IA, em versões anteriores ou iguais a 1.8.1. |
| Vetor | Requisição HTTP POST não autenticada com parâmetro opcional data contendo definições de fluxo controladas pelo atacante e código Python em nós do fluxo. |
| Impacto | Execução remota de código com os privilégios do processo servidor, com risco confirmado de leitura de variáveis de ambiente, arquivos de configuração, credenciais e tentativa de entrega de payload posterior. |
| Prioridade | Atualizar para versão corrigida, remover exposição pública desnecessária, restringir acesso por firewall ou proxy autenticado, auditar segredos e rotacionar chaves em instâncias expostas. |
| Versões | Todas as versões do Langflow até 1.8.1 foram descritas como afetadas; a correção aparece na versão de desenvolvimento 1.9.0.dev8. |
| IoC | Atividade posterior foi associada ao endereço 173.212.205[.]251 na porta 8443, citado como origem ou hospedagem de próximo estágio no contexto observado. |
| Prazo regulatório | A CISA adicionou a CVE-2026-33017 ao catálogo KEV em 25 de março de 2026, com prazo de correção para agências FCEB até 8 de abril de 2026. |
A CVE-2026-33017 é uma falha crítica no Langflow que combina ausência de autenticação em um endpoint público com injeção de código em definições de fluxo. O problema está no caminho POST /api/v1/build_public_tmp/{flow_id}/flow, criado para permitir a construção de fluxos públicos. Quando o parâmetro opcional data é aceito, o servidor passa a processar dados fornecidos pelo cliente em vez de usar somente a definição armazenada no banco de dados. O resultado é que nós do fluxo podem carregar código Python arbitrário, que chega a uma chamada exec() sem isolamento, permitindo execução remota no processo do servidor.
A exploração foi observada em ambiente real cerca de 20 horas após a publicação do aviso em 17 de março de 2026. O dado é relevante porque não havia, naquele momento, um PoC público citado no contexto; operadores maliciosos aparentemente derivaram a exploração diretamente da descrição técnica do problema. A falha é distinta da CVE-2025-3248, embora compartilhe o mesmo ponto perigoso no fim da cadeia, a execução de Python sem barreira de sandbox. No caso anterior, o abuso passava pelo endpoint /api/v1/validate/code; nesta vulnerabilidade, o ponto exposto é a construção temporária de fluxos públicos.
O fluxo vulnerável depende de uma condição funcional legítima do Langflow: fluxos públicos precisam ser acessíveis sem autenticação. A quebra ocorre quando o endpoint aceita uma definição completa enviada pelo usuário por meio de data e permite que essa definição substitua o conteúdo persistido no servidor. Em uma instância exposta, uma única requisição POST pode carregar nós manipulados com código Python embutido. Como esse código é entregue à execução sem isolamento, a fronteira entre entrada de usuário e execução local desaparece, e o atacante passa a operar no mesmo contexto do serviço Langflow.
O impacto técnico confirmado no contexto inclui leitura de variáveis de ambiente, acesso ou alteração de arquivos, coleta de credenciais e tentativa de implantação de um próximo estágio. Também foi relatada extração de /etc/passwd, enumeração de arquivos de configuração, bancos de dados e conteúdo de arquivos .env. Esses artefatos indicam foco em segredos operacionais, especialmente chaves, senhas de banco e valores usados por integrações de IA ou pipelines. A consequência prática não deve ser tratada apenas como uma execução genérica de comandos: em ambientes reais, o processo do Langflow pode ter acesso a credenciais de aplicações, conectores de dados e componentes de cadeia de software.
A atividade descrita evoluiu de varredura automatizada para scripts Python customizados. Esse padrão sugere duas fases defensivamente relevantes: validação de vulnerabilidade e exploração de pós-comprometimento no mesmo intervalo de sessão. A presença de um endereço defangado associado a payload posterior, 173.212.205[.]251:8443, não deve ser usada como único critério de detecção, porque operadores podem trocar infraestrutura rapidamente. O sinal mais forte está na combinação de requisições incomuns ao endpoint vulnerável, presença de data com definição de fluxo não esperada, execução anômala do processo servidor e leitura de arquivos de credenciais logo após o acesso HTTP.
A superfície principal é qualquer instância do Langflow acessível por rede em versões anteriores ou iguais a 1.8.1. O risco aumenta quando o serviço fica exposto diretamente à internet, sem proxy autenticado, sem filtragem de origem e com permissões amplas no sistema operacional. Como a falha não exige autenticação, controles baseados apenas em contas de usuário dentro da aplicação não reduzem o vetor se o endpoint público permanecer alcançável. Ambientes de laboratório, PoCs internos e implantações temporárias também entram no escopo quando reutilizam segredos reais em variáveis de ambiente.
A relevância para equipes de AppSec, segurança de nuvem e engenharia está na posição típica dessas plataformas: elas frequentemente integram bancos de dados, chaves de API, provedores de modelos, repositórios e serviços internos. Se o processo do Langflow roda com permissões excessivas ou compartilha o mesmo ambiente de segredos de produção, a execução remota pode virar coleta de credenciais com impacto em sistemas conectados. O contexto também aponta risco de comprometimento de cadeia de software quando credenciais coletadas dão acesso a bancos, ambientes de build ou integrações usadas por desenvolvimento.
- Instâncias do Langflow até a versão 1.8.1 com o endpoint
build_public_tmpacessível por rede. - Servidores em que o processo do Langflow consegue ler variáveis de ambiente, arquivos
.env, configurações de banco ou segredos de integração. - Ambientes em que fluxos públicos são necessários, mas não há controle externo de acesso, segmentação de rede ou proxy autenticado.
- Implantações de IA conectadas a bancos de dados, repositórios, serviços de automação ou credenciais usadas por pipelines.
A investigação deve começar pelos logs HTTP do serviço, proxy reverso, balanceador e WAF, buscando requisições POST para /api/v1/build_public_tmp/{flow_id}/flow, especialmente quando o corpo contém data com estrutura de definição de fluxo. A ausência de autenticação torna a origem do tráfego um sinal importante, mas não suficiente. Varreduras podem aparecer como muitas tentativas contra IDs de fluxo inexistentes, enquanto exploração efetiva tende a ser seguida por comportamento local anômalo do processo, como leitura de arquivos sensíveis ou conexão de saída para infraestrutura não usual.
No endpoint, os sinais incluem criação de subprocessos inesperados pelo serviço, acesso a /etc/passwd, leitura de arquivos .env, enumeração de diretórios de configuração e consultas incomuns a bancos conectados. Em telemetria de rede, conexões de saída logo após a requisição suspeita merecem prioridade, principalmente para portas não usadas normalmente pelo ambiente. O endereço 173.212.205[.]251 na porta 8443 foi citado no contexto como artefato observado, mas a defesa deve tratá-lo como exemplo limitado e procurar classes de comportamento: callbacks externos, downloads de próximo estágio e sessões de coleta de credenciais.
Em nuvem e contêineres, a caça deve incluir variáveis de ambiente expostas, montagens de segredo, permissões de service accounts, volume mounts e acessos a metadados ou serviços internos a partir do workload do Langflow. Em CI/CD, revise se credenciais presentes no host ou no runtime foram usadas após a janela de exploração. Uma linha do tempo útil correlaciona publicação do aviso em 17 de março de 2026, primeiras tentativas no intervalo de 20 horas, inclusão no KEV em 25 de março de 2026 e qualquer tráfego contra o endpoint vulnerável antes da aplicação da correção.
- Requisições POST ao endpoint
/api/v1/build_public_tmp/{flow_id}/flowcontendo parâmetrodatafora do padrão esperado para fluxos públicos. - Leitura anômala de
/etc/passwd, arquivos.env, configurações de banco e diretórios de aplicação pelo processo do Langflow. - Conexões de saída para destinos desconhecidos logo após acesso ao endpoint vulnerável, incluindo uso incomum da porta 8443.
- Uso posterior de chaves, tokens ou senhas que estavam disponíveis como variáveis de ambiente na instância exposta.
A resposta deve priorizar correção e redução imediata de exposição. Instâncias vulneráveis devem ser atualizadas para uma versão corrigida conforme o canal oficial do projeto, com atenção ao dado de que a correção foi descrita na versão de desenvolvimento 1.9.0.dev8. Quando a atualização não puder ser aplicada de forma imediata, o endpoint deve deixar de ser publicamente acessível por meio de firewall, lista de origem permitida, VPN, proxy reverso com autenticação ou desativação temporária de recursos de fluxo público quando viável para o negócio. Como a causa envolve aceitar definição de fluxo fornecida pelo cliente, a mitigação defensiva precisa impedir que dados controlados externamente sejam executados como código.
Após corrigir o software, a equipe deve tratar instâncias expostas como potencialmente comprometidas se houve tráfego suspeito após a divulgação. A ordem prática é preservar logs, identificar requisições ao endpoint, verificar processos e conexões de saída, auditar leitura de arquivos sensíveis, listar segredos acessíveis ao runtime e rotacionar credenciais que estiveram disponíveis no ambiente. Isso inclui chaves de API, senhas de banco de dados, tokens de provedores de IA, credenciais de repositório e segredos usados por automação. A rotação deve ser acompanhada de invalidação de sessões e revisão de permissões, porque segredos coletados podem continuar válidos mesmo depois que a vulnerabilidade for corrigida.
A mitigação estrutural exige reduzir privilégio do processo Langflow. O serviço não deve rodar com permissões amplas, não deve compartilhar segredos de produção sem necessidade e deve ficar em segmento de rede compatível com sua função. Contêineres devem ter filesystem restrito, variáveis sensíveis minimizadas, egress filtrado e logs centralizados. Em ambientes em que fluxos públicos são requisito, a defesa deve separar a publicação de fluxo da execução de definições arbitrárias e validar que somente dados persistidos no servidor sejam executados.
- Atualizar o Langflow para versão corrigida e confirmar que versões até 1.8.1 não permanecem expostas.
- Bloquear acesso direto ao endpoint vulnerável com firewall, proxy autenticado, segmentação ou controle equivalente.
- Auditar variáveis de ambiente, arquivos
.env, configurações de banco e segredos disponíveis ao processo do Langflow. - Rotacionar chaves, tokens e senhas de bancos ou integrações que puderam ser lidos por uma instância exposta.
- Monitorar conexões de saída e downloads de próximo estágio, tratando o IP defangado citado como indicador limitado, não como cobertura completa.
- Revisar permissões do serviço, egress de rede, montagens de segredo e identidade usada por workloads de IA.
0 Comentários