rootdirective-sec/cve-2026-55255-labCVE-2026-55255の再現のためのローカルDockerラボ。LangflowのResponses APIにおけるIDOR脆弱性です。リクエストベースのPoCにより、脆弱バージョンとパッチ適用済みバージョンでのクロスユーザーフロー実行を検証します。
/api/v1/responses）このリポジトリには、LangflowのOpenAI互換Responses APIに影響を与える不適切な直接オブジェクト参照 (IDOR) 脆弱性であるCVE-2026-55255を再現および検証するためのローカルDockerラボが含まれています。
Langflowは、AIを活用したエージェントやワークフローを構築・デプロイするためのオープンソースプラットフォームです。脆弱な動作は/api/v1/responsesエンドポイントに影響し、認証された攻撃者が別のユーザーのフローUUIDをmodel値として提供することで、Langflowにその被害者のフローを実行させることができます。
このラボでは、2つのLangflowバージョンを比較します：
| サービス | Langflowバージョン | 目的 | URL |
|---|---|---|---|
| vuln | 1.9.0 | 脆弱性比較対象 | http://localhost:7860 |
| patched | 1.9.1 | 修正済み比較対象 | http://localhost:7861 |
このローカルラボで実証されたHTTP検証パスは次のとおりです：
Authenticated attacker API key
→ POST /api/v1/responses
→ request body sets model to victim-owned flow UUID
→ vulnerable target executes the victim-owned flow
→ patched target returns flow_not_found and does not execute the victim-owned flow
```
脆弱なターゲットでは、攻撃者所有のAPIキーが被害者所有のフローを実行でき、そのレスポンスには被害者のみのマーカーが含まれます:```text
VICTIM_ONLY_CONTEXT_55255_VULN
```
パッチ適用後のターゲットでは、同じクロスユーザーリクエストが被害者マーカーを返さず、OpenAIスタイルのエラーボディを返します:```json
{"error":{"message":"Flow with id '<victim-flow-id>' not found","type":"invalid_request_error","code":"flow_not_found"}}
```
このラボは、Langflow 1.9.0 と Langflow 1.9.1 を使用して、脆弱バージョンとパッチ適用済みバージョンの HTTP 動作を検証します。
このラボは意図的にローカルの Docker サービスに限定されています。外部システムを標的とせず、資格情報の窃取、データベースのダンプ、破壊的なペイロード、外部コールバック、マルウェア、永続化、またはポストエクスプロイト活動を含みません。
## 検証済みの事実
| 主張 | 証拠 | このラボでの検証方法 |
| ----- | -------- | ------------------------- |
| CVE-2026-55255 は Langflow の `/api/v1/responses` エンドポイントに影響を与えます。 | GitHub Advisory GHSA-qrpv-q767-xqq2 は `/api/v1/responses` の IDOR を説明しています。 | リファレンスセクションを確認し、両方のローカルターゲットに対して PoC を実行してください。 |
| GitHub Advisory は影響を受けるバージョンを `< 1.9.1`、パッチ適用済みバージョンを `1.9.1` としています。 | GitHub Advisory 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 の Responses API は `POST /api/v1/responses` を使用します。 | Langflow のドキュメントは OpenAI 互換の Responses API エンドポイントについて説明しています。 | PoC または手動の curl リクエストを `/api/v1/responses` に対して実行してください。 |
| Langflow の Responses 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、シェルコマンド、コンテナ API を呼び出しません。 | `poc/validate_idor.py` を確認してください。 |
| 脆弱なターゲットは、攻撃者が所有する API キーで被害者が所有するフローを実行します。 | 脆弱なレスポンスは `VICTIM_ONLY_CONTEXT_55255_VULN` を返します。 | 脆弱な PoC コマンドを被害者のフロー ID と攻撃者の API キーで実行してください。 |
| パッチ適用済みのターゲットは同じクロスユーザー実行パスをブロックします。 | パッチ適用済みのレスポンスは `error.code = flow_not_found` を返し、被害者マーカーを返しません。 | パッチ適用済みの PoC コマンドを被害者のフロー ID と攻撃者の API キーで実行してください。 |
## 前提と未確定事項
このラボは、脆弱な比較対象として Langflow 1.9.0 を使用します。これは、GitHub Advisory GHSA-qrpv-q767-xqq2 が 1.9.1 より前のバージョンを影響ありと特定しており、ローカルテストで 1.9.0 の脆弱な動作が確認されたためです。
このラボは、パッチ適用済みの比較対象として Langflow 1.9.1 を使用します。これは、GitHub Advisory GHSA-qrpv-q767-xqq2 が 1.9.1 をパッチ適用済みバージョンとしてリストしており、ローカルテストで 1.9.1 がテスト対象のクロスユーザー `/api/v1/responses` 実行パスを `flow_not_found` でブロックすることが確認されたためです。
情報源の間でバージョンの不一致があります。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
```
このラボでは、攻撃者が既に被害者のフローUUIDを知っていることを前提としています。PoCはフローIDのブルートフォース、フローの列挙、または被害者のフローIDの発見を試みません。
このラボは、観測可能なHTTP動作に焦点を当てています：```text
POST /api/v1/responses
```
このリクエスト形状:```json
{
"model": "<victim-flow-id>",
"input": "cross-user CVE-2026-55255 validation request",
"stream": false
}
```
このラボは、脆弱なターゲットにおける認可されていないクロスユーザーフロー実行と、パッチ適用済みターゲットにおけるブロックされた動作を示しています。
このラボは以下を実証しません：
* フローUUIDのブルートフォース,
* フローIDの列挙,
* 資格情報の窃取,
* データベースのダンプ,
* 実際のLLMプロバイダーAPIキーの使用,
* 実際の本番データへのアクセス,
* 外部コールバック,
* リモートコマンド実行,
* マルウェア,
* 永続化,
* またはラボ外のシステムへの攻撃。
## Root Cause Summary
CVE-2026-55255の根本原因は、Langflowのフロー解決ロジックにおける認可の欠落です。
`/api/v1/responses` エンドポイントは、`model` フィールドを介してフローUUIDを受け入れます。脆弱なバージョンでは、`get_flow_by_id_or_endpoint_name()` 内のUUIDルックアップパスが、解決された `Flow.user_id` が認証されたAPIキーユーザーと一致することを強制せずに、主キーによって `Flow` オブジェクトを直接ロードする可能性がありました。
脆弱な動作は次のように要約できます：```text
Attacker owns API key
→ attacker sends POST /api/v1/responses
→ model contains victim-owned flow UUID
→ flow resolver loads Flow by UUID
→ resolver does not enforce Flow.user_id == attacker_user.id
→ response endpoint executes the victim-owned flow
→ attacker receives victim flow output
```
パッチ適用後の動作は次のようにまとめられます:```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
```
セキュリティ上の問題は、攻撃者が自身のフローを使用して `/api/v1/responses` を呼び出せることではありません。それは想定された動作です。問題は、低権限の認証済みユーザーが、被害者のフロー UUID を指定した場合に、エンドポイントが他のユーザーが所有するフローを実行させられることです。
セキュリティ教訓は以下の通りです：```text
Object lookup by UUID is not authorization.
Every object lookup used by an authenticated API route must be scoped to the authenticated principal or followed by a strict ownership check before the object is used.
```
## ソースコード分析
ソースレベルの問題は、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:
```
脆弱なUUIDブランチでは、フローはIDによってロードされました：```python
flow_id = UUID(flow_id_or_name)
flow = await session.get(Flow, flow_id)
```
セキュリティ関連の欠落したチェックは：```python
flow.user_id == authenticated_user.id
```
その所有者チェックがないと、有効なフローUUIDがあれば、たとえそれが他のユーザーに属していても、`Flow` オブジェクトを解決できた。
パッチ済みバージョンでは、`user_id` の正規化が追加され、UUIDパスに所有者スコープが強制されます。```python
if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:
flow = None
```
重要な動作は：```text
if the flow exists
and the flow belongs to another user
then treat it as not found
```
これが、修正されたラボ応答が返す理由です：```json
{"error":{"code":"flow_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)]
```
認証済みラッパーなどへ:```python
async def get_flow_for_api_key_user(
flow_id_or_name: str,
api_key_user: Annotated[UserRead, Depends(api_key_security)],
) -> FlowRead:
return await get_flow_by_id_or_endpoint_name(flow_id_or_name, api_key_user.id)
```
これらのラッパー変更は、他のフロー実行ルート（`/api/v1/run*` など）のための関連する強化です。これらは、ヘルパーが単なるリクエストパラメータに依存するのではなく、認証済みユーザーIDを受け取ることを保証します。このラボで示されるコア修正は、`get_flow_by_id_or_endpoint_name()` 内のリゾルバー側の所有権チェックのままです。
したがって、ソースレベルの修正には2つの関連する部分があります。```text
Core resolver fix:
enforce owner scoping before returning a Flow object