2026年7月2日 · 深度技术研究

导语

2026年3月17日，GitHub Security Advisory 发布了 CVE-2026-33017——Langflow 的一个未授权远程代码执行漏洞，CVSS 3.1 满分 10.0。这个漏洞的存在令人震惊：一个拥有超过 14 万 GitHub Stars、被广泛用于企业 AI 工作流构建的平台，其核心 API 端点在没有认证、没有沙箱的情况下直接将用户提交的 Python 代码传入 exec() 执行。

更令人担忧的是，这不是 Langflow 的第一个严重 RCE 漏洞——而是第四个。AI 基础设施平台的安全成熟度，显然没有跟上其普及速度。

一、漏洞技术细节：一个 HTTP 请求即可接管服务器

1.1 漏洞端点

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

这个端点的设计用途是允许公开分享的工作流（Public Flow） 无需认证即可被构建。但问题在于：该端点接受一个可选的 data 参数——当攻击者提交包含自定义 Python 代码节点的 data 时，服务端将其直接传入 Python 的 exec() 函数执行。

1.2 完整攻击链

POST /api/v1/build_public_tmp/{flow_id}/flow
→ start_flow_build(data=attacker_data)
  → generate_flow_events()
    → create_graph()
      → Graph.from_payload(payload)  # 解析攻击者自定义节点
        → instantiate_class(vertex)    # 提取 code 字段
          → eval_custom_component_code(code)
            → create_class(code, class_name)
              → prepare_global_scope(module)
                → exec(compiled_code, exec_globals)  # 任意代码执行

关键细节：prepare_global_scope 执行 AST 赋值节点。攻击者代码如 _x = os.system("id") 是赋值语句，会在图构建阶段被执行——在流程"运行"之前就已经触发了代码执行。

1.3 利用条件极其宽松

  • 无需任何认证：不需要 Authorization header
  • 仅需一个公开 Flow 的 UUID：可通过共享链接发现
  • AUTO_LOGIN 默认开启：攻击者甚至可以自行调用 GET /api/v1/auto_login 获取超级用户 Token，然后创建公开 Flow，再利用该漏洞，全程零门槛
  • 单个 HTTP 请求即可完成攻击

1.4 PoC 核心步骤

  1. 通过 auto_login 获取 Token（当 AUTO_LOGIN=true 时无需凭证）
  2. 创建一个公开 Flow 获取 UUID
  3. 向 build_public_tmp 发送包含恶意 Python 代码的请求（无 Authorization header）
  4. 服务器执行 os.popen("id") 等任意命令

GitHub Security Advisory 中包含完整 PoC，在 Langflow v1.7.3 上6/6 次运行全部确认 RCE 成功（100% 可复现）。

二、CVSS 10.0 满分解读

维度 值 含义
AV:N 网络攻击向量 可从互联网远程利用
AC:L 低攻击复杂度 单个 HTTP 请求即可触发
PR:N 无需权限 零认证要求——这是最致命的特征
UI:N 无需用户交互 完全自动化攻击
S:C 范围变更 影响超出漏洞组件本身
C:H/I:H/A:H CIA 全高 机密性、完整性、可用性全部受损

CVSS 向量：AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

满分 10.0 意味着所有关键指标均为最高风险等级。在 CVSS 评分体系中，获得满分需要同时满足"远程利用 + 零权限 + 零交互 + 全面影响"，这个条件组合极其罕见。

三、在野利用：20 小时内的攻击狂欢

3.1 攻击时间线

Sysdig 威胁研究团队在公告发布后仅 20 小时内即观察到活跃的在野利用活动——此时甚至还没有公开的 PoC。攻击者直接从公告文本描述中逆向重构了利用代码。

3.2 观察到的攻击行为

行为类型 IP 数量 具体操作
自动化扫描 4 个 IP 大规模探测暴露的 Langflow 实例
主动侦察 1 个 IP 预先部署攻击基础设施
数据窃取 1 个 IP 针对 .env 文件和 /etc/passwd 进行凭证收集

攻击者基础设施包括部署在 173.212.205[.]251:8443 的恶意载荷。

3.3 暴露面

Shodan 扫描显示约 12,000+ 个 Langflow 实例暴露于公网。这些实例中的大部分可能仍在运行受影响版本，构成巨大的攻击面。

四、历史背景：Langflow 的"第四次"

CVE-2026-33017 并非孤立事件。Langflow 在短短一年内已经出现了五个严重漏洞：

CVE CVSS 类型 修复版本
CVE-2025-3248 9.8 未授权 RCE（代码验证端点） 1.3.0
CVE-2025-34291 9.4 CORS/CSRF 链 → 账户接管 + RCE 1.7.x
CVE-2026-27966 9.8 Prompt 注入 → Python REPL 1.8.0
CVE-2026-33017 10.0 未授权 RCE（公开 Flow 构建端点） 1.9.0
CVE-2026-33309 9.9 任意文件写入 → RCE 1.9.0

其中 CVE-2025-3248 已被 CISA KEV（已知被利用漏洞）收录，并被 Trend Micro 确认被 Flodrix 僵尸网络在野利用。

一个平台的连续五个 CVSS 9+ 漏洞，反映了什么？

五、我的分析：AI 基础设施安全的三重危机

危机一："快速迭代"压倒了"安全设计"

Langflow 的漏洞模式暴露了一个系统性问题：核心 API 端点在设计时就缺乏认证和沙箱机制。build_public_tmp 端点允许未认证用户提交任意 data 并传入 exec() 执行——这不是"实现细节的疏忽"，而是架构层面的安全设计缺失。

五个漏洞中有四个涉及 RCE，且大多与"未认证 + 代码执行"相关。这说明 Langflow 的安全模型从一开始就没有正确处理"公开功能"与"危险操作"之间的边界。

危机二：AI 平台是攻击者的"蜜罐"

Langflow 拥有 14 万+ GitHub Stars，被广泛用于企业 AI 工作流。这些部署中往往存储着 API 密钥、模型凭证、数据库连接字符串等高价值目标。一个 CVSS 10 的未授权 RCE 意味着攻击者可以一步到位地获取整个 AI 基础设施的访问权限。

更讽刺的是：使用 Langflow 构建安全检测流程的企业，其自身的安全防护可能因为 Langflow 的漏洞而被完全绕过。

危机三：安全披露与修复的速度竞赛

Sysdig 的数据显示，攻击者在漏洞公告发布后 20 小时内就开始在野利用。而根据行业数据，企业平均需要数周到数月才能完成补丁部署。对于暴露在公网上的 Langflow 实例，这个时间差可能意味着已经被攻破。

六、修复与缓解

6.1 官方修复

升级至 Langflow >= 1.9.0。修复方式是从 build_public_tmp 端点移除 data 参数——公开 Flow 只能执行数据库中存储的预存数据，永远不接受用户提交的可执行数据。

6.2 临时缓解（无法立即升级时）

  1. 通过防火墙或反向代理阻止 POST /api/v1/build_public_tmp/ 的访问
  2. 关闭 AUTO_LOGIN 功能
  3. 将 Langflow 实例从公网隔离
  4. 对已暴露的实例进行全面的凭证轮换（API 密钥、数据库密码、云凭证等）

七、给 AI 平台开发者的建议

  1. 默认认证：所有 API 端点默认需要认证，"公开功能"应有独立的、受限的权限模型
  2. 代码执行沙箱：任何接受用户代码的端点必须有强沙箱隔离（如 gVisor、Firecracker），而非直接 exec()
  3. 安全审查流程：对"接受外部输入 → 执行代码"的路径进行专项安全审查
  4. 漏洞历史复盘：连续出现同类型漏洞说明根本原因未被解决，需要从架构层面重新审视安全模型

免责声明

本文仅供网络安全技术研究和教育目的，所有漏洞信息来源于 GitHub Security Advisory（GHSA-vwmf-pq79-vjvx）及安全公司的公开研究报告。本文不包含任何可直接用于非法攻击的原始利用代码或攻击载荷，所有技术描述均以安全防御、漏洞修复和行业分析为导向。读者应遵守所在国家/地区的法律法规，仅将本文内容用于授权的安全测试和防御性安全研究。未经授权对他人系统进行渗透测试或攻击属于违法行为。

参考资料