威胁动态

CVE-2026-0770 — Langflow 未认证远程代码执行漏洞(解读与修复)

Langflow 远程代码执行(CVE-2026-0770,已列入 CISA KEV):区分版本说明与修复参考,限制暴露面,及时更新并排查入侵迹象。

发布于 2026-07-23 更新于 2026-10-23 最后核实 2026-07-23 3 分钟阅读
本页目录

这是一份针对已确认在野利用(列入 CISA KEV)漏洞的防御性通告。内容包括发生了什么、哪些产品受影响,以及如何应对;不包含攻击方法或概念验证代码。

版本来源差异(核查日期:2026 年 10 月 23 日)

GHSA 列出的版本范围至 1.7.3,但未登记修复版本;CNA 将 1.4.2 标为受影响,其他版本未知。KEV 链接指向 v1.9.0,但其说明未确定该 CVE 的最低修复版本。请将这些来源的适用范围分开看待。

通告摘要
CVE
CVE-2026-0770(引入来自不可信控制域的功能,CWE-829)
严重性
严重(CVSS 9.8)— 已被积极利用(CISA KEV)
类型
validate(代码检查)端点中的未认证远程代码执行(RCE)
影响
无需认证即可执行任意代码(许多部署中为 root 权限)、凭证和云元数据被窃取、横向移动
受影响范围
Langflow 1.7.3 及更早版本
主要修复
停止暴露服务(网络隔离 + 身份验证)并更新到最新版本
9.8
CVSS / 最高等级
无需认证
可达性
RCE→root
可达影响
停止暴露
主要防御

无需认证即可访问

validate 端点

任意代码执行(许多环境中为 root)

凭证和云元数据窃取 / 横向移动

修复:停止暴露服务(网络隔离 + 身份验证)并更新

无需认证即可访问,因此容易成为大范围自动化扫描的目标。可在两个环节阻断:不暴露服务,以及更新版本。

为什么不修复很危险

由于无需认证即可触及 root 级代码执行,公开的 Langflow 实例正受到大规模自动化扫描的针对。据报道和威胁情报显示,在野利用最早约在 2026-06-27 被观察到;在 CISA 将其加入 KEV 目录之前,已记录到来自 64 个不同源 IP 的 220 多次利用尝试。观察到的行为包括命令执行检测、系统侦察、下载额外脚本,以及尝试访问凭证和云元数据。如果它曾可从互联网访问,请将其视为已失陷。

受影响范围

项目详情
目标Langflow(用于 AI 代理/流程的可视化构建工具)
受影响版本1.7.3 及更早版本(GHSA 范围;CNA 将 1.4.2 标为受影响,其他版本未知)
修复版本GHSA 中未登记修复版本;KEV 链接指向 v1.9.0。此处未确定最低修复版本。请查阅官方信息,更新,并将隔离与身份验证结合使用
前提条件无需认证(未认证)
可达影响任意代码执行(RCE)→ 服务器被接管、凭证/元数据被窃取、横向移动
状态已被积极利用(CISA KEV)

关于严重性评分差异的说明(双方观点)

评分因评估方和 CVSS 版本而异。NVD 和 ZDI(ZDI-26-036)依据 CVSS 3.x 给出 9.8(严重);GitHub Advisory 依据 CVSS 4.0 给出 8.9(高危)。使用不同版本或评估条件得出的评分不能直接比较。由于已有未认证代码执行和实际利用的报告,应优先限制暴露面并更新。

这是一类反复出现的缺陷(重要)

Langflow 的 validate / 代码执行端点此前曾出现未认证 RCE 并被列入 KEV 目录(CVE-2025-3248);另有一个 Langflow 缺陷的报告显示,某个据称“已修复”的版本仍可被利用。请勿假设“已经更新,所以安全了”。应当更新,但要把网络隔离、身份验证和最小权限作为长期的主要控制措施。

应对措施

1

停止互联网暴露(最优先)

将 Langflow 从公共网络中撤下。使用反向代理加身份验证、IP 白名单以及仅限 VPN/内网访问,使未认证的可达性为零。Langflow 的设计本就会执行代码,因此暴露本身就是根本风险。这才是真正阻断 RCE 的措施。
2

更新到最新版本(但不要只依赖补丁)

更新到最新可用版本。请区分 GHSA 登记信息与 KEV 的修复参考,并将更新与隔离加身份验证结合使用。请始终查看厂商的发布说明和安全公告,以确认当前状态。
3

排查入侵迹象(假设曾被暴露)

检查可疑进程、计划任务(cron)条目和外连流量;留意异常的文件写入;查找访问凭证或云元数据的痕迹(例如实例 IAM 令牌);以及 validate 端点上的未认证访问记录。应将 RCE 视为“服务器机密(密钥、令牌、数据库凭证)可能已泄露”,若曾被暴露,请轮换凭证。
4

以最小权限运行并缩小攻击面

以非 root 用户运行 Langflow,并尽量减少其可访问的云权限(实例角色等)。在不需要的情况下,限制其访问元数据端点。即使被入侵,这也属于纵深防御,有助于减少损失。
5

自动监控 CVE 并快速更新

监控 Langflow 及其他自托管产品的版本和 CVE,在发布公告时及时更新或阻断。这样可以从结构上避免“已知的公开 CVE 被遗漏而长期未修复”的情况。

本站观点:会执行代码的工具默认“不暴露”

从根本上看,问题与其说是某个漏洞,不如说是将一个设计上就会执行代码的工具暴露给不可信网络。AI 代理构建器和低代码平台常常以任意代码执行为前提来换取便利,而一个“仅供内部测试”的实例也可能悄然变成面向互联网的服务。立即更新是必要的,但长期真正有效的做法是:默认开发/测试用的代码执行工具绝不接入互联网,并建立自动监控自托管 CVE、快速阻断的日常机制。另请参阅我们的 AI 时代安全检查清单。

延伸阅读

来源与范围

以下主要参考资料支持上文讨论的设置、范围或修复内容;链接核查日期为 2026 年 10 月 23 日。请查阅其版本和配置条件。检查清单的优先级和经验教训属于本站指导意见,并非对全文的重新验证,也不构成安全保证。

FAQ

QCVE-2026-0770 允许攻击者做什么?
A

在 Langflow 的代码检查(validate)端点中,通过 exec_globals 参数传入的不可信输入会被 Python 的 exec() 直接执行。未经认证的攻击者因此可以运行任意代码(在许多部署中为 root 权限),进而导致服务器被接管、凭证和云元数据被窃取,并可横向渗透到其他系统。CVSS 9.8,且已确认在野利用(CISA KEV)。

Q最可靠的修复方法是什么?
A

限制互联网暴露,要求身份验证并采用最小权限原则,及时更新并排查入侵迹象。GHSA 未登记已修复的版本,而 KEV 链接指向 v1.9.0。请勿根据这一差异推断最低修复版本;请查阅官方信息,核对已安装的版本。

Q为什么不同来源的严重性评估存在差异?
A

NVD 和 ZDI 依据 CVSS 3.x 给出 9.8(严重);GitHub Advisory 依据 CVSS 4.0 给出 8.9(高危)。使用不同版本或评估条件得出的评分不能直接比较。由于已有未认证代码执行和实际利用的报告,应优先限制暴露面并更新。