CVE-2026-55255: Langflow’s /api/v1/responses endpoint contains an IDOR that lets any authenticated user execute another user’s flow by supplying the victim’s flow UUID.

Langflow's OpenAI-compatible POST /api/v1/responses endpoint contains an Insecure Direct Object Reference (IDOR). The helper get_flow_by_id_or_endpoint_name resolves a flow by UUID using session.get(Flow, flow_id) without comparing flow.user_id to the caller's identity. Because /api/v1/responses passes the authenticated user's id as the second argument but the UUID branch ignores it, any authenticated user can execute any other user's flow by supplying the victim's flow UUID as the request model value. The fix (commit b0afe3d2d6, PR #12832) adds an ownership check on both the UUID and endpoint-name branches and returns the flow as not-found when the caller is not the owner.

• Package/component affected: langflow-base 0.9.0 (langflow 1.9.0), helper langflow.helpers.flow.get_flow_by_id_or_endpoint_name, reached via langflow.api.v1.openai_responses.create_response (POST /api/v1/responses).
• Affected versions: Langflow < 1.9.1 (advisory) / < 1.9.2 (NVD). The vulnerable source analyzed here is commit f52d0f0072 (langflow 1.9.0 / langflow-base 0.9.0), the parent of the fix commit b0afe3d2d6.
• Risk level and consequences: High. An authenticated (non-superuser) attacker can execute arbitrary flows owned by other tenants by UUID, exposing those flows' outputs (cross-tenant data disclosure), consuming the victims' resources, and affecting integrity. This is a cross-tenant authorization bypass.

Impact Parity

• Disclosed/claimed maximum impact: Authenticated cross-tenant flow execution / IDOR (authorization bypass) on /api/v1/responses.
• Reproduced impact from this run: An authenticated low-privileged attacker executed a victim-owned flow through the real POST /api/v1/responses endpoint by supplying the victim's flow UUID as model, receiving a completed response whose output contained the flow's executed result. The same request against the fixed build (commit b0afe3d2d6) was rejected with error.code = "flow_not_found".
• Parity: full — the claimed IDOR (cross-tenant flow execution) was reproduced end-to-end through the real HTTP API on a running Langflow 1.9.0 server, with a fixed-commit negative control.
• Not demonstrated: No privilege escalation to superuser, no code execution beyond running an existing flow, and no RCE. The proof demonstrates the authorization bypass (flow execution + output disclosure), which is the claimed impact.

Root Cause

get_flow_by_id_or_endpoint_name(flow_id_or_name, user_id) has two branches:

# vulnerable (commit f52d0f0072, langflow-base 0.9.0)
try:
    flow_id = UUID(flow_id_or_name)
    flow = await session.get(Flow, flow_id)     # <-- no user_id check
except ValueError:
    endpoint_name = flow_id_or_name
    stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)
    if user_id:                                  # <-- only scoped when truthy
        uuid_user_id = UUID(user_id) if isinstance(user_id, str) else user_id
        stmt = stmt.where(Flow.user_id == uuid_user_id)
    flow = (await session.exec(stmt)).first()

The UUID branch calls session.get(Flow, flow_id) and returns the flow unconditionally — the user_id argument is never consulted. The endpoint-name branch only filters by user_id when a truthy value is passed.

POST /api/v1/responses (openai_responses.create_response) authenticates the caller via api_key_security (the x-api-key header) and then resolves the flow with the authenticated user's id:

flow = await get_flow_by_id_or_endpoint_name(request.model, str(api_key_user.id))

request.model is attacker-controlled. When it parses as a UUID, the vulnerable UUID branch ignores str(api_key_user.id) and returns any flow with that UUID, regardless of ownership. The flow is then executed by run_flow_for_openai_responses, so the attacker runs the victim's flow and reads its output.

The fix (commit b0afe3d2d6, PR #12832, "fix(security): close IDOR in get_flow_by_id_or_endpoint_name (LE-639)") normalizes user_id once and enforces it on both branches:

flow = await session.get(Flow, flow_id)
if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:
    flow = None      # cross-user lookup -> treated as not found (404)

so the shared if flow is None: raise HTTPException(404) fires for cross-tenant lookups and /api/v1/responses returns error.code = "flow_not_found".

Fix commit: b0afe3d2d6 (PR #12832), file src/backend/base/langflow/helpers/flow.py.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained, idempotent).
2. What it does:
   • Builds the vulnerable Langflow 1.9.0 stack (langflow-base 0.9.0) from the repo source at commit f52d0f0072 (b0afe3d2d6^). PyPI never published langflow 1.9.0/1.9.1/1.9.2 (the 1.x series starts at 1.9.3 which already contains the fix), so the vulnerable stack must be built from source. The sandbox ships only Python 3.14 but langflow 1.9.0 requires <3.14, so a standalone CPython 3.12 is provisioned via uv.
   • Starts a real Langflow server (multi-user mode, SQLite) on 127.0.0.1:7860.
   • Registers a victim and an attacker user via the public POST /api/v1/users/ signup endpoint (both is_superuser: false).
   • Logs both in, mints API keys via POST /api/v1/api_key/.
   • The victim creates a flow (ChatInput→ChatOutput echo, no LLM) and captures the victim flow UUID (VICTIM_FLOW_ID).
   • Ownership proof: GET /api/v1/flows/{id} returns 200 for the victim and 404 for the attacker, confirming the flow is victim-owned and the attacker has no legitimate access.
   • IDOR (vulnerable): the attacker calls POST /api/v1/responses with x-api-key: <attacker> and {"model": "<VICTIM_FLOW_ID>", "input": "<probe>", "stream": false}.
   • Swaps in the fixed helpers/flow.py from commit b0afe3d2d6, restarts the server on the same SQLite DB (same flow/users), and repeats the attacker call.
3. Expected evidence of reproduction:
   • Vulnerable build: HTTP 200, object: "response", status: "completed", model equals the victim flow UUID, and output[].content[].text contains the attacker's probe string — the victim's flow was executed by the attacker.
   • Fixed build: {"error": {"code": "flow_not_found", "message": "Flow with id '<uuid>' not found"}} — the same request is blocked.
   • The only difference between the two phases is helpers/flow.py, proving the divergence is the missing ownership check.

Evidence

• bundle/logs/reproduction_steps.log — full run log with version, marker checks, and both IDOR responses.
• bundle/logs/langflow_server_vuln.log / bundle/logs/langflow_server_fixed.log — server startup/health logs for each phase.
• bundle/repro/artifacts/victim_register.json / attacker_register.json — signup responses (is_superuser: false).
• bundle/repro/artifacts/victim_flow_create.json — flow creation response containing VICTIM_FLOW_ID and user_id (victim).
• bundle/repro/artifacts/ownership_victim_get.txt / ownership_attacker_get.txt — GET /api/v1/flows/{id} status codes (200 vs 404).
• bundle/repro/artifacts/idor_response_vuln.json — vulnerable IDOR response (status: completed, probe in output).
• bundle/repro/artifacts/idor_response_fixed.json — fixed IDOR response (error.code: flow_not_found).
• bundle/repro/artifacts/summary.json — structured classification (idor_confirmed: true).
• bundle/repro/runtime_manifest.json — runtime evidence manifest (service_started/healthcheck_passed/target_path_reached = true).
• bundle/repro/validation_verdict.json — structured verdict.

Environment: Langflow 1.9.0 (langflow-base 0.9.0) built from source commit f52d0f0072; fixed control commit b0afe3d2d6; Python 3.12 (uv standalone); SQLite; uvicorn backend-only; multi-user mode (LANGFLOW_AUTO_LOGIN=false, signup enabled).

Key excerpt (vulnerable IDOR response):

{
  "object": "response",
  "status": "completed",
  "error": null,
  "model": "<VICTIM_FLOW_UUID>",
  "output": [{ "type": "message", "status": "completed",
    "content": [{ "type": "output_text", "text": "IDOR_PROBE_VULN_..." }] }]
}

Key excerpt (fixed IDOR response):

{ "error": { "message": "Flow with id '<VICTIM_FLOW_UUID>' not found",
  "type": "invalid_request_error", "code": "flow_not_found" } }

Recommendations / Next Steps

• Upgrade to Langflow >= 1.9.1 (contains the fix from PR #12832 / commit b0afe3d2d6).
• Fix approach (already applied upstream): enforce user_id on both branches of get_flow_by_id_or_endpoint_name and return the flow as not-found on cross-user lookups, so the shared 404 path fires and flow existence is not disclosed to unauthorized callers.
• Defense in depth: audit other callers of get_flow_by_id_or_endpoint_name (e.g. webhook/run endpoints) for the same ownership gap; add an integration test that asserts a cross-tenant UUID lookup returns 404 (the upstream regression tests in tests/unit/helpers/test_flow_helpers.py cover this).
• Testing recommendations: add a multi-tenant API test that creates a flow as user A and asserts user B cannot execute it via /api/v1/responses by UUID.

Additional Notes

• Idempotency: The script extracts the vulnerable source fresh each run (so the editable langflow-base install always starts from the vulnerable flow.py), reuses a cached venv at the durable project cache path when present, and uses a fresh SQLite DB each run. Consecutive runs produce the same vulnerable/completed vs fixed/flow_not_found divergence.
• Note on request field: the advisory's example curl uses "input_value", but the actual OpenAIResponsesRequest schema field is "input". The reproduction uses the correct input field; the IDOR is independent of this field (it is triggered by model = victim flow UUID).
• Note on HTTP status: both the vulnerable (flow executed) and the fixed (flow not found) responses are returned with HTTP 200 by the OpenAI-compatible endpoint; the discriminator is the response body (status: completed + output vs error.code: flow_not_found), which is a stronger signal than the status code.
• Scope: The vulnerable wt-vuln/wt-fixed worktrees provided in the project cache already contained the fix commit, so the reproduction anchors the vulnerable checkout to b0afe3d2d6^ (f52d0f0072) per the fixed-commit checkout rule, and the fixed checkout to b0afe3d2d6.