系统:运行中
← 返回所有攻击
INFRASTRUCTURE CRITICAL NEW

Langflow 的公开构建端点:20 小时内被武器化的未授权 RCE

CVE-2026-33017 将 Langflow 的公开流程构建端点变成未授权远程代码执行。该漏洞于 2026 年 3 月 17 日披露,20 小时内即被野外利用——早于任何公开 PoC 出现。

2026-06-07 // 5 min affects: langflow, ai-agent-builders, rag-pipelines, llm-orchestration

这是什么?

Langflow 是一个被广泛部署的开源可视化框架,用于构建 LLM 智能体和 RAG(检索增强生成)流水线。CVE-2026-330172026 年 3 月 17 日披露,是其公开构建端点中的一个未授权远程代码执行漏洞。NVD 将其评为 9.8(CVSS 3.1),GitHub CNA 记录则评为 9.3(CVSS 4.0)。这些评分通常不会成为重点。这次的重点是时钟:Sysdig 威胁研究团队公告发布后 20 小时内便观察到野外利用,而当时尚无任何公开的概念验证。攻击者读完公告、写出利用代码,随即开始扫描整个互联网。

本文是对一个已披露、已修复漏洞的防御性分析。文中不复现任何有效载荷——补丁已公开,要点在于运营层面。

工作原理

漏洞位于一个无需认证即可访问的端点中:

POST /api/v1/build_public_tmp/{flow_id}/flow

在 1.8.1 及更早版本中,该端点接受一个可选的 data 参数。一旦提供该参数,端点便会基于攻击者控制的流程数据来构建流程,而非数据库中存储的流程定义。Langflow 的「flow」是一个节点图,而节点定义中可以携带 Python 代码。该代码路径会到达 exec(),且没有任何沙箱——因此攻击者提供的节点代码会以 Langflow 进程的权限在主机上执行。

请求(未认证)
  -> build_public_tmp 端点
  -> 可选的 `data` = 攻击者的流程图
  -> 节点定义包含 Python 代码
  -> exec()  [无沙箱]
  -> 代码在主机上执行

1.9.0 中的修复彻底移除了公开构建端点的 data 参数,使其无法再被传入攻击者控制的图。但有一个重要细节:中间版本 1.8.2 曾被宣称已修复,而 JFrog 安全研究团队证明 1.8.2 仍可被利用,并且无法在其提交记录中找到对应的补丁。实际后果是:仅凭版本号并不是可靠的修复信号。

在后渗透阶段,研究人员报告了直接奔向价值的入侵:窃取云凭证(AWS 密钥)并在被攻陷主机上部署 worker 类载荷。该端点提供了未授权代码执行,之后的一切都是常规后渗透,取决于 Langflow 主机能触及哪些资源。

为何重要

第一个原因是 20 小时的武器化窗口。没有任何可复制的 PoC。公告文本本身就足以还原漏洞,「披露」到「全网扫描」之间的间隔被压缩到不足一天。任何假定 CVE 发布后还有一周平静期的补丁 SLA,都建立在一个对暴露在互联网上的 AI 工具已不再成立的威胁模型之上。

第二个原因是 这类软件运行在哪里。Langflow 是一个构建工具——一种开发者便利设施,常常因为「只是」内部原型工具而被部署在拥有宽泛出站访问与环境云凭证的云主机上。对于未授权 RCE 而言,这是最糟糕的宿主。CISA 于 2026 年 3 月 25 日将 CVE-2026-33017 加入其已知被利用漏洞(KEV)目录,并依据 BOD 22-01 指令要求联邦民事机构在 4 月 8 日前完成修复——这表明受影响的是真实暴露的部署,而非实验室实例。

第三个原因:对用户控制的图数据调用 exec() 是一种模式,而非孤例。许多 LLM 编排与智能体构建框架都会评估用户提供的、内嵌代码的「flow」「工具」或「skill」。如果你自己的技术栈把序列化的智能体定义转化为被执行的 Python 或 shell,你也许正以另一个名字拥有同一个漏洞。Langflow 的节点图只是其最显眼的实例。

防御

  1. 升级到 1.9.0 或更高版本——并要验证,不要相信版本号。 鉴于 1.8.2 的绕过,请确认你运行的构建中 build_public_tmp 已不再有 data 参数,而不是假定一个标注为「已修复」的发行版真的已修复。

  2. 把 Langflow 移出公网。 流程构建器没有理由以可路由 IP 监听 0.0.0.0。将其绑定到 localhost,或置于带网络 ACL 的 VPN/经认证的反向代理之后。大多数被利用的实例只是因为可被访问。

  3. 为暴露在互联网上的 AI 工具重新校准补丁 SLA。 20 小时这个数字如今就是你的规划基准。把公告发布——而非 PoC 发布——视为利用时钟的起点,并为暴露资产上的未授权 RCE 设立计划外的紧急修复通道。

  4. 剥离环境凭证并限制出站。 Langflow 主机上不应有长期 AWS/云密钥;使用范围受限、短时效的 IAM 凭证,并默认拒绝出站。即便代码执行已发生,这也能削弱后渗透阶段所观察到的凭证窃取与 worker 部署。

  5. 在你自己的构建器中消除对用户控制定义的 exec()/eval() 如果智能体/流程/skill 定义可以携带代码,请在沙箱中运行它们(独立进程、seccomp、无主机挂载且无网络的容器)——绝不要在编排进程内联执行。

  6. 追猎指标。 对指向 build_public_tmp 的请求、Langflow 进程派生的异常子进程,以及意外的出站连接(凭证端点、未知的 C2/worker 代理)设置告警。在攻击者之前,用外部扫描(Shodan/Censys)盘点你的暴露面。

状态

项目来源日期备注
CVE-2026-33017 披露NVD / GitHub CNA2026-03-17未授权 RCE,CVSS 3.1 9.8 / CVSS 4.0 9.3
野外利用Sysdig TRT~2026-03-18公告后 20 小时内,无公开 PoC
加入 CISA KEVCISA / Help Net Security2026-03-25FCEB 修复截止 2026-04-08(BOD 22-01)
补丁Langflow 1.9.02026移除 build_public_tmpdata 参数
1.8.2 仍可利用JFrog 安全研究团队2026「已修复」的中间版本被证明可绕过

漏洞已修复。可复用的教训与 Langflow 本身无关:一个执行用户提供代码、且暴露在互联网上的未授权构建器,会在公告文本的基础上被利用——其速度快于大多数团队安排补丁窗口的速度。在下一个公告替你检验这一假设之前,先找出并关闭你那些暴露在外的 AI 工具。

Sources