Langflow 中因授权校验缺失导致的跨租户流程劫持

What is this?

Langflow 是一个被广泛部署的开源可视化框架，用于构建 LLM 智能体与检索增强生成（RAG）管线。2026 年 6 月 19 日，其维护者发布了一份安全公告，涉及 /api/v1/responses 接口中的一个不安全的直接对象引用（IDOR）：任何已认证用户只需在请求中提供某个流程的标识符，即可执行属于他人的流程。该接口接受由客户端提供的流程标识符，却从不校验调用方是否确实拥有该流程。

这个漏洞之所以严重，是因为 Langflow 的流程通常会把有效的机密——LLM 服务商密钥、云凭据、数据库连接串——直接内嵌在组件配置中。因此劫持他人的流程不只是越权执行，更是一条通往其凭据的路径。Sysdig 威胁研究团队报告称，首次在野利用发生于 2026 年 6 月 25 日，美国 CISA 于 2026 年 7 月 7 日将该漏洞列入其已知被利用漏洞（KEV）目录，并要求联邦民口机构在 7 月 10 日前完成修复。修复其实更早就已发布，包含在 Langflow 1.9.1 中。

How it works

根本原因是辅助函数 get_flow_by_id_or_endpoint_name（helpers/flow.py）中缺失了一处所有权校验。当通过可读的 endpoint_name 查询流程时，查询会限定在当前用户；而通过 UUID 查询同一流程时，则不会：

# 示意 —— 存在漏洞的分支通过 UUID 解析流程，
# 却没有确认请求方是否为其所有者。
flow_id = UUID(flow_id_or_name)
flow = await session.get(Flow, flow_id)   # 此路径没有所有者校验
# ...
# 相比之下，endpoint_name 分支确实按 user_id 过滤。

/api/v1/responses 接口兼容 OpenAI-Responses：它把 model 字段当作流程 UUID。只要向它提供另一个租户的 UUID，平台就会通过其自身受信任的执行路径，在该租户内嵌凭据之下运行该租户的流程。

这里有一条应当明说的现实约束：Langflow 的流程 UUID 是一个 122 位的随机值，无法暴力猜测，而 endpoint_name 路径已正确限定范围，因此不存在靠猜测别名走捷径的可能。利用取决于先获得一个有效的流程标识符。在被观测到的入侵中，攻击者拉取了 GET /api/v1/flows/ 列表——该接口泄露了这些标识符——随后将这些标识符回放到 responses 接口。这正是典型的泄露到 IDOR 链条：一个过于宽松的列表接口，把「无法猜测」的对象引用变成了可用的攻击。

示例提示

下面的代码片段以防御视角展示了该技术：responses 端点将 model 字段当作流程 UUID 并在不校验归属的情况下执行，因此一个被泄露的流程 ID 就能以另一租户的内嵌凭据运行其流程。此处不展示可用的漏洞利用——仅供防御者参考。

# Langflow cross-tenant flow hijack (illustrative, defensive)
# The /api/v1/responses endpoint treats "model" as a flow UUID and
# ran it WITHOUT checking the caller owned it (pre-1.9.1):
victim_flow_id = "[REDACTED-flow-uuid]"   # first leaked via GET /api/v1/flows/
POST /api/v1/responses  { "model": victim_flow_id, "input": "[hidden instruction]" }
# -> runs another tenant's flow under THEIR embedded API keys.
# Root cause: missing ownership check on the UUID lookup path (IDOR).
# Defense: upgrade to Langflow 1.9.1+, scope object lookups to the caller,
# authorize/rate-limit ID-listing endpoints, and vault your secrets.

Why it matters

本案的启示在于：CVSS 分数并不是可利用性的排名。这个流程授权漏洞得分 9.9，因为它突破了跨租户边界；但 Sysdig 观察到同一攻击者仅把它当作两次请求的顺手之举，反而把精力集中在同一产品中另一个未认证的远程代码执行漏洞上（评分更低，为 9.3，却可在互联网上大规模喷洒且无需凭据）。在单个自托管实例上，代码执行是 IDOR 所能带来能力的严格超集，因此以「投入产出比」为导向的攻击者会转向 RCE。

IDOR 只有在一种场景下才配得上它的高危评级：多租户或托管型 Langflow。在那里，各租户的流程运行于隔离的 worker 中，RCE 因而被限制在单个租户内，无法凭自身跨越边界。而授权漏洞却可以——悄然地、在应用层、以一次外观合法、唯一异常只是「流程 ID 不对」的 API 调用完成。对于把 Langflow 作为共享服务运营的人来说，这正是触及其他客户机密的路径，而且远在嘈杂 RCE 的检测足迹之下。

更广的教训超出了这一款产品。AI 编排平台在设计上就集中了大量凭据，使其成为高价值目标，而其快速演进的代码库仍在不断引入经典的 Web 授权缺陷。请以对待任何多租户 SaaS 的同等访问控制审慎，来对待这些平台。

Defenses

1. 打补丁并确认版本。 修复包含在 Langflow 1.9.1（PR #12832）中；请使用最新版本。现在两条查询分支都会校验所有权，跨用户查询返回 404 而非 403，以避免存在性预言机。
2. 将 ID 泄露接口视为 IDOR 攻击面的一部分。 泄露流程 UUID 的列表路由，正是使该漏洞可达的原因。对象枚举接口应与它们所解锁的敏感操作，接受同等的授权审查与限流。
3. 停止在流程中内嵌明文机密。 通过密钥管理器或平台变量存储来引用凭据，而不要把服务商与云密钥粘贴进组件配置。如果某个流程曾被暴露，轮换它携带的每一个密钥——按已被窃取处理。
4. 不要将自托管实例无认证暴露。 被观测到的攻击者首先探测了无认证的 auto_login 默认设置。请把 Langflow 置于认证与网络控制之后；绝不要把具备管理能力的实例发布到开放互联网。
5. 在多租户部署中于应用层强制隔离。 按 worker、按租户的沙箱无法阻止应用层的授权突破。将每次对象查询限定到调用方，并显式测试跨租户情形。
6. 监控攻击链，而不仅是载荷。 一次枚举调用（/api/v1/flows/）紧接着携带刚列出的标识符的 /api/v1/responses 调用，是一个强信号。Sysdig 与 SentinelOne 已发布该被观测行动的失陷指标。

Status

项目	参考	日期	备注
厂商公告（IDOR，CWE-639）	GHSA-qrpv-q767-xqq2 / CVE-2026-55255	2026-06-19	CVSS 9.9，范围变更；影响 < 1.9.1
修复发布	Langflow 1.9.1（PR #12832）	2026-04-22（合并）	两条路径均校验所有权
首次在野利用	Sysdig TRT	2026-06-25	枚举 → responses 链；「leak api keys」提示
列入 CISA KEV	CISA 警报	2026-07-07	联邦修复截止 2026-07-10
关联 RCE（同一产品）	CVE-2026-33017	KEV 2026-03-25	未认证，CVSS 9.3，约 20 小时内被大规模利用

本次遵循了负责任披露：报告者获得致谢，补丁在公开公告之前已发布。正确的结论不是「又一个 AI CVE」，而是一个提醒：经典的授权失效缺陷如今正落在那些保管着你的模型与云密钥的工具里——而高 CVSS 分数说明的是影响，而非攻击者实际会最先触及哪个漏洞。