Feed de ameaças

CVE-2026-0770 — Execução remota de código sem autenticação no Langflow (explicação e correções)

RCE no Langflow (CVE-2026-0770, no CISA KEV): diferencie as declarações de versão e as referências de correção, restrinja a exposição, atualize e verifique sinais de comprometimento.

Publicado 2026-07-23 Atualizado 2026-10-23 Última verificação 2026-07-23 8 min de leitura
Nesta página

Um comunicado defensivo sobre vulnerabilidades com exploração confirmada na natureza (listadas no CISA KEV). O que acontece, o que é afetado e como responder, sem instruções de ataque nem prova de conceito.

Diferenças entre as fontes sobre versões (verificado em 23 de outubro de 2026)

O GHSA lista versões até a 1.7.3 sem uma versão corrigida publicada; o CNA marca a 1.4.2 como afetada e as demais versões como desconhecidas. O KEV aponta para a v1.9.0, cujas notas não identificam uma versão mínima corrigida para este CVE. Mantenha separados os escopos de cada fonte.

Resumo do comunicado
CVE
CVE-2026-0770 (inclusão de funcionalidade de uma esfera de controle não confiável, CWE-829)
Severidade
Crítica (CVSS 9,8) — explorada ativamente (CISA KEV)
Tipo
Execução remota de código (RCE) sem autenticação no endpoint validate (verificação de código)
Impacto
Execução de código arbitrário sem autenticação (root em muitas implantações), roubo de credenciais e de metadados de nuvem, movimentação lateral
Afetados
Langflow 1.7.3 e anteriores
Correção principal
Parar a exposição (isolamento de rede + autenticação) + atualizar para a versão mais recente
9.8
CVSS / pior classe
Sem autenticação
Alcançabilidade
RCE→root
Impacto alcançável
Parar a exposição
Principal defesa

Alcançado sem autenticação

O endpoint validate

Execução de código arbitrário (root em muitas configurações)

Roubo de credenciais e de metadados de nuvem / movimentação lateral

Correção: parar a exposição (isolamento de rede + autenticação) e atualizar

Alcançável sem autenticação, o que o torna alvo de varreduras indiscriminadas. Pode ser interrompido em dois pontos: não expondo o serviço e atualizando a versão.

Por que não corrigir é perigoso

Como a execução de código em nível root é alcançável sem autenticação, instâncias públicas do Langflow são alvo de varreduras automatizadas em larga escala. Segundo relatos e inteligência de ameaças, a exploração na natureza foi observada a partir de cerca de 2026-06-27, e, antes de a CISA incluí-la no catálogo KEV, foram registradas mais de 220 tentativas de exploração a partir de 64 IPs de origem distintos. O comportamento observado incluiu verificações de execução de comandos, reconhecimento do sistema, download de scripts adicionais e tentativas de acessar credenciais e metadados de nuvem. Se ele esteve acessível pela internet, trate-o como comprometido.

O que é afetado

ItemDetalhe
AlvoLangflow (construtor visual de agentes/fluxos de IA)
Versões afetadas1.7.3 e anteriores (a faixa do GHSA; o CNA marca a 1.4.2 como afetada e as demais versões como desconhecidas)
Versão corrigidaNenhuma versão corrigida registrada no GHSA; o KEV aponta para a v1.9.0. A versão mínima corrigida não foi estabelecida aqui. Consulte as informações oficiais, atualize e combine o isolamento com a autenticação
Pré-condiçãoNão é necessária autenticação (não autenticado)
Impacto alcançávelExecução de código arbitrário (RCE) → tomada do servidor, roubo de credenciais/metadados, movimentação lateral
StatusExplorada ativamente (CISA KEV)

Nota sobre as pontuações de severidade diferentes (dos dois lados)

As pontuações variam conforme o avaliador e a versão do CVSS. O NVD e a ZDI (ZDI-26-036) atribuem 9.8 (Crítica) pelo CVSS 3.x; o GitHub Advisory atribui 8.9 (Alta) pelo CVSS 4.0. Pontuações que usam versões diferentes ou condições de avaliação diferentes não são diretamente comparáveis. Priorize restringir a exposição e atualizar, porque há relatos de execução de código sem autenticação e de exploração real.

Esta é uma classe de falha recorrente (importante)

Os endpoints de validação / execução de código do Langflow já tiveram RCEs anteriores sem autenticação incluídas no catálogo KEV (CVE-2025-3248), e, para outra falha do Langflow, relatou-se que uma versão supostamente "corrigida" continuava explorável. Não presuma que "atualizamos, então estamos seguros". Atualize, sim, mas tenha o isolamento de rede, a autenticação e o privilégio mínimo como controles principais permanentes.

Como responder

1

Pare a exposição à internet (prioridade máxima)

Tire o Langflow das redes públicas. Use um proxy reverso + autenticação, uma lista de IPs permitidos e acesso apenas por VPN/rede interna, de modo que o alcance sem autenticação seja zero. O Langflow executa código por design, então a exposição em si é o risco principal. Isso é o que realmente bloqueia a RCE.
2

Atualize para a versão mais recente (mas não dependa só da correção)

Atualize para a versão mais recente disponível. Diferencie o registro do GHSA da referência de correção do KEV e combine a atualização com isolamento + autenticação. Sempre consulte as notas de versão e os alertas de segurança do fornecedor para o status atual.
3

Verifique sinais de comprometimento (presuma que houve exposição)

Procure processos suspeitos, entradas de cron e tráfego de saída; gravações de arquivos inesperadas; vestígios de acesso a credenciais ou metadados de nuvem (por exemplo, tokens IAM de instância); e acessos não autenticados ao endpoint validate. Trate a RCE como "segredos do servidor (chaves, tokens, credenciais de banco de dados) podem ter vazado" e rotacione as credenciais caso tenha havido exposição.
4

Execute com privilégio mínimo e reduza a superfície de ataque

Execute o Langflow como um usuário não root e minimize as permissões de nuvem que ele pode alcançar (funções de instância, etc.). Onde não for necessário, restrinja o alcance ao endpoint de metadados. Isso é defesa em profundidade para minimizar os danos mesmo se houver invasão.
5

Monitore CVEs por máquina e atualize rapidamente

Monitore as versões e os CVEs do Langflow e de outros produtos self-hosted, e atualize/bloqueie rapidamente quando os alertas forem publicados. Isso evita de forma estrutural que "um CVE público conhecido passe despercebido e fique sem correção".

A visão deste site: ferramentas que executam código devem ficar 'não expostas' por padrão

No fundo, o problema é menos sobre um bug específico e mais sobre expor uma ferramenta que executa código por design a uma rede não confiável. Construtores de agentes de IA e plataformas low-code muitas vezes trazem a execução de código arbitrário como premissa em troca de conveniência — e uma instância de "teste interno" discretamente passa a ficar exposta à internet. A atualização é obrigatória, mas o que compensa a longo prazo é um padrão em que ferramentas de execução de código de desenvolvimento/teste nunca tocam a internet, além de uma rotina que monitora por máquina os CVEs de produtos self-hosted e os bloqueia rapidamente. Veja também nossa checklist de segurança na era da IA.

Leia a seguir

Fontes e escopo

Estas referências primárias sustentam as configurações, o escopo ou as recomendações de correção discutidos acima; os links foram verificados em 23 de outubro de 2026. Consulte suas condições de versão e configuração. As prioridades e lições da checklist são orientações deste site, não uma revalidação completa do artigo nem uma garantia de segurança.

FAQ

QO que o CVE-2026-0770 permite que um atacante faça?
A

No endpoint de verificação de código (validate) do Langflow, a entrada não confiável passada pelo parâmetro exec_globals é executada diretamente pelo exec() do Python. Um atacante não autenticado pode, portanto, executar código arbitrário (como root em muitas implantações), levando diretamente à tomada do servidor, ao roubo de credenciais e de metadados de nuvem, e ao pivoteamento para outros sistemas. CVSS 9,8, com exploração confirmada na natureza (CISA KEV).

QQual é a correção mais segura?
A

Restrinja a exposição à internet, exija autenticação e privilégio mínimo, atualize e verifique sinais de comprometimento. O GHSA não registra uma versão corrigida publicada, enquanto o KEV aponta para a v1.9.0. Não deduza uma versão mínima corrigida a partir dessa diferença; verifique as informações oficiais para a versão instalada.

QPor que as avaliações de severidade diferem entre as fontes?
A

O NVD e a ZDI atribuem 9,8 (Crítica) pelo CVSS 3.x; o GitHub Advisory atribui 8,9 (Alta) pelo CVSS 4.0. Pontuações que usam versões diferentes do CVSS ou condições de avaliação diferentes não são diretamente comparáveis. Priorize a restrição da exposição e a atualização, porque há relatos de execução de código sem autenticação e de exploração real.