GHSA-GH98-4PHW-6FMW

Vulnerability from github – Published: 2026-10-07 20:36 – Updated: 2026-10-07 20:36
VLAI
Summary
Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints
Details

Summary

Before Langflow 1.10.1, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:

  • POST /api/v1/build/{flow_id}/vertices (retrieve_vertices_order)
  • POST /api/v1/build/{flow_id}/vertices/{vertex_id} (build_vertex)

Any authenticated user who knows (or obtains) another user's flow_id could load that user's private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.

Both routes are declared with deprecated=True, include_in_schema=False, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses POST /api/v1/build/{flow_id}/flow), so they are only reachable by direct HTTP requests.

The issue is fixed in Langflow 1.10.1 (langflow-base 0.10.1) by #13153.

Details

In affected versions, both handlers go straight to the graph loader:

  • retrieve_vertices_order (src/backend/base/langflow/api/v1/chat.py, lines 81-159 in 1.9.1) only required authentication via dependencies=[Depends(get_current_active_user)]. The user was never injected into the handler, and the flow was loaded with build_graph_from_db(flow_id=flow_id, ...).
  • build_vertex (chat.py, lines 320-491 in 1.9.1) receives current_user, but only uses it for variable resolution (user_id=str(current_user.id)). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by flow_id, or rebuilt with build_graph_from_db on a cache miss.
  • build_graph_from_db_no_cache (src/backend/base/langflow/api/utils/flow_utils.py) does a bare primary-key lookup, session.get(Flow, flow_id), with no owner filter.

The supported replacement, POST /api/v1/build/{flow_id}/flow, already restricted the lookup to the owner or a PUBLIC flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the _read_flow fix for GHSA-8c4j-f57c-35cf.

Additional side effects in affected versions:

  • retrieve_vertices_order stores the graph in the chat-service cache under the victim's flow_id (chat_service.set_cache(str(flow_id), graph)). When the request includes a data body, the cached graph is attacker-supplied.
  • build_vertex schedules log_vertex_build for the victim's flow_id, so attacker-triggered builds are recorded in the victim flow's vertex build history.

Note on older versions: up to and including 1.7.1, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.

Attack scenario

  1. The attacker authenticates as any valid user.
  2. The attacker obtains a victim flow_id (shared URLs, exported flow files, logs, screenshots, etc.).
  3. POST /api/v1/build/{victim_flow_id}/vertices returns 200 OK with {"ids": [...], "run_id": "...", "vertices_to_run": [...]} listing the victim flow's vertex IDs (component type plus suffix, e.g. ChatInput-abc12).
  4. The attacker calls POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id} for a returned ID. The victim's graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.

Impact

  • Confidentiality (Low): Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.
  • Global variables and credentials in the variable store are not exposed, because variable resolution uses the caller's user_id.
  • The victim's stored flow definition is not returned wholesale.
  • Integrity (Low): The attacker can trigger execution of the victim's nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim's flow_id. The attacker cannot modify the stored flow.
  • Availability: None.

The attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.

Proof of concept

Observed on langflow==1.9.1 using the project's test client and in-memory SQLite fixtures (see the attached poc.zip):

Request Expected (hardened) Observed on 1.9.1
Attacker → POST /api/v1/build/{victim_flow_id}/vertices 404 Not Found 200 OK with vertex order payload
Attacker → POST /api/v1/build/{victim_flow_id}/vertices/<bogus-id> 404 Not Found 500 {"detail":"Vertex <id> not found"}: the victim graph was loaded before the vertex lookup failed
Owner (control) → same endpoints non-404 non-404

On 1.10.1 and later, the attacker requests return 404 Not Found. This is covered by regression tests in src/backend/tests/unit/test_endpoints.py:

  • test_get_vertices_returns_404_for_other_users_private_flow
  • test_get_vertices_with_supplied_data_returns_404_for_other_users_private_flow
  • test_build_vertex_returns_404_for_other_users_private_flow

Patches

Fixed in Langflow 1.10.1 (langflow-base 0.10.1) by #13153 (merge commit fb3d6ec90b). Both handlers now:

  1. inject current_user (for retrieve_vertices_order, this replaces the dependencies-only declaration),
  2. load the flow with an owner-scoped query and return 404 when it is not found, so a flow you don't own looks the same as a missing flow, and
  3. call ensure_flow_permission(current_user, FlowAction.EXECUTE, ...) before building or caching any graph.
# retrieve_vertices_order / build_vertex (1.10.1)
stmt = (
    select(Flow)
    .where(Flow.id == flow_id)
    .where((Flow.user_id == current_user.id) | (Flow.access_type == AccessTypeEnum.PUBLIC))
)
flow = (await session.exec(stmt)).first()
if not flow:
    raise HTTPException(status_code=404, detail=f"Flow with id {flow_id} not found")
await ensure_flow_permission(
    current_user,
    FlowAction.EXECUTE,
    flow_id=flow_id,
    flow_user_id=flow.user_id,
    workspace_id=flow.workspace_id,
    folder_id=flow.folder_id,
)

Related hardening in later releases:

  • #14342 (1.11.2) applies the same guard to the sibling GET /api/v1/build/{flow_id}/{vertex_id}/stream route.
  • #14497 (1.12.0) makes all three deprecated vertex routes owner-only, dropping the PUBLIC exception, because their graph cache is keyed by flow UUID rather than by the executing user.

Users should upgrade to 1.10.1 or later. The latest release is recommended.

Workarounds

If upgrading is not immediately possible, block POST /api/v1/build/*/vertices and POST /api/v1/build/*/vertices/* (and GET /api/v1/build/*/*/stream) at a reverse proxy. The Langflow UI does not use these routes.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow-base"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:36:25Z",
    "nvd_published_at": "2026-10-05T21:16:35Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nBefore **Langflow 1.10.1**, two deprecated but still-routed endpoints in the chat API did not check that the authenticated caller owns the flow referenced in the URL path:\n\n- `POST /api/v1/build/{flow_id}/vertices` (`retrieve_vertices_order`)\n- `POST /api/v1/build/{flow_id}/vertices/{vertex_id}` (`build_vertex`)\n\nAny authenticated user who knows (or obtains) another user\u0027s `flow_id` could load that user\u0027s private flow graph, enumerate its vertex IDs, and build (execute) individual vertices of it, receiving the vertex results in the response.\n\nBoth routes are declared with `deprecated=True, include_in_schema=False`, so they do not appear in the OpenAPI docs, but they remained registered on the router. The Langflow UI no longer calls them (it uses `POST /api/v1/build/{flow_id}/flow`), so they are only reachable by direct HTTP requests.\n\nThe issue is fixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153).\n\n### Details\n\nIn affected versions, both handlers go straight to the graph loader:\n\n- `retrieve_vertices_order` (`src/backend/base/langflow/api/v1/chat.py`, lines 81-159 in 1.9.1) only required authentication via `dependencies=[Depends(get_current_active_user)]`. The user was never injected into the handler, and the flow was loaded with `build_graph_from_db(flow_id=flow_id, ...)`.\n- `build_vertex` (`chat.py`, lines 320-491 in 1.9.1) receives `current_user`, but only uses it for variable resolution (`user_id=str(current_user.id)`). It is never used to scope the flow lookup. The graph is taken from the chat-service cache keyed by `flow_id`, or rebuilt with `build_graph_from_db` on a cache miss.\n- `build_graph_from_db_no_cache` (`src/backend/base/langflow/api/utils/flow_utils.py`) does a bare primary-key lookup, `session.get(Flow, flow_id)`, with no owner filter.\n\nThe supported replacement, `POST /api/v1/build/{flow_id}/flow`, already restricted the lookup to the owner or a `PUBLIC` flow (added in #12305 for GHSA-qj98-rhf8-v93f). The deprecated siblings were not covered by that fix, nor by the `_read_flow` fix for GHSA-8c4j-f57c-35cf.\n\nAdditional side effects in affected versions:\n\n- `retrieve_vertices_order` stores the graph in the chat-service cache under the victim\u0027s `flow_id` (`chat_service.set_cache(str(flow_id), graph)`). When the request includes a `data` body, the cached graph is attacker-supplied.\n- `build_vertex` schedules `log_vertex_build` for the victim\u0027s `flow_id`, so attacker-triggered builds are recorded in the victim flow\u0027s vertex build history.\n\nNote on older versions: up to and including **1.7.1**, these two routes had no authentication dependency at all. Authentication was added in 1.7.2 by #10977, but no ownership check was added. This advisory covers the missing ownership check, which is present in every release from 1.0.0 (when the routes were introduced) through 1.10.0.\n\n### Attack scenario\n\n1. The attacker authenticates as any valid user.\n2. The attacker obtains a victim `flow_id` (shared URLs, exported flow files, logs, screenshots, etc.).\n3. `POST /api/v1/build/{victim_flow_id}/vertices` returns **200 OK** with `{\"ids\": [...], \"run_id\": \"...\", \"vertices_to_run\": [...]}` listing the victim flow\u0027s vertex IDs (component type plus suffix, e.g. `ChatInput-abc12`).\n4. The attacker calls `POST /api/v1/build/{victim_flow_id}/vertices/{vertex_id}` for a returned ID. The victim\u0027s graph is loaded and the vertex is built. Its results, outputs and artifacts are returned to the attacker.\n\n### Impact\n\n- **Confidentiality (Low):** Discloses the structure of private flows (vertex IDs and component types) and the outputs of vertices the attacker chooses to build. That includes values hardcoded in node configuration, such as prompt text or fixed inputs.\n  - Global variables and credentials in the variable store are **not** exposed, because variable resolution uses the caller\u0027s `user_id`.\n  - The victim\u0027s stored flow definition is not returned wholesale.\n- **Integrity (Low):** The attacker can trigger execution of the victim\u0027s nodes, including any side effects baked into their configuration (fixed endpoints, webhooks, hardcoded API keys). Build records are written under the victim\u0027s `flow_id`. The attacker cannot modify the stored flow.\n- **Availability:** None.\n\nThe attacker must be authenticated and must know the target flow UUID. Flow UUIDs are random v4 values, so blind enumeration is not practical.\n\n### Proof of concept\n\nObserved on `langflow==1.9.1` using the project\u0027s test client and in-memory SQLite fixtures (see the attached `poc.zip`):\n\n| Request | Expected (hardened) | Observed on 1.9.1 |\n|---|---|---|\n| Attacker \u2192 `POST /api/v1/build/{victim_flow_id}/vertices` | `404 Not Found` | `200 OK` with vertex order payload |\n| Attacker \u2192 `POST /api/v1/build/{victim_flow_id}/vertices/\u003cbogus-id\u003e` | `404 Not Found` | `500` `{\"detail\":\"Vertex \u003cid\u003e not found\"}`: the victim graph was loaded before the vertex lookup failed |\n| Owner (control) \u2192 same endpoints | non-404 | non-404 |\n\nOn 1.10.1 and later, the attacker requests return `404 Not Found`. This is covered by regression tests in `src/backend/tests/unit/test_endpoints.py`:\n\n- `test_get_vertices_returns_404_for_other_users_private_flow`\n- `test_get_vertices_with_supplied_data_returns_404_for_other_users_private_flow`\n- `test_build_vertex_returns_404_for_other_users_private_flow`\n\n### Patches\n\nFixed in **Langflow 1.10.1** (`langflow-base` 0.10.1) by [#13153](https://github.com/langflow-ai/langflow/pull/13153) (merge commit `fb3d6ec90b`). Both handlers now:\n\n1. inject `current_user` (for `retrieve_vertices_order`, this replaces the dependencies-only declaration),\n2. load the flow with an owner-scoped query and return `404` when it is not found, so a flow you don\u0027t own looks the same as a missing flow, and\n3. call `ensure_flow_permission(current_user, FlowAction.EXECUTE, ...)` before building or caching any graph.\n\n```python\n# retrieve_vertices_order / build_vertex (1.10.1)\nstmt = (\n    select(Flow)\n    .where(Flow.id == flow_id)\n    .where((Flow.user_id == current_user.id) | (Flow.access_type == AccessTypeEnum.PUBLIC))\n)\nflow = (await session.exec(stmt)).first()\nif not flow:\n    raise HTTPException(status_code=404, detail=f\"Flow with id {flow_id} not found\")\nawait ensure_flow_permission(\n    current_user,\n    FlowAction.EXECUTE,\n    flow_id=flow_id,\n    flow_user_id=flow.user_id,\n    workspace_id=flow.workspace_id,\n    folder_id=flow.folder_id,\n)\n```\n\nRelated hardening in later releases:\n\n- [#14342](https://github.com/langflow-ai/langflow/pull/14342) (1.11.2) applies the same guard to the sibling `GET /api/v1/build/{flow_id}/{vertex_id}/stream` route.\n- [#14497](https://github.com/langflow-ai/langflow/pull/14497) (1.12.0) makes all three deprecated vertex routes owner-only, dropping the `PUBLIC` exception, because their graph cache is keyed by flow UUID rather than by the executing user.\n\nUsers should upgrade to **1.10.1 or later**. The latest release is recommended.\n\n### Workarounds\n\nIf upgrading is not immediately possible, block `POST /api/v1/build/*/vertices` and `POST /api/v1/build/*/vertices/*` (and `GET /api/v1/build/*/*/stream`) at a reverse proxy. The Langflow UI does not use these routes.",
  "id": "GHSA-gh98-4phw-6fmw",
  "modified": "2026-10-07T20:36:25Z",
  "published": "2026-10-07T20:36:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-gh98-4phw-6fmw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105698"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/pull/13153"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/commit/fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langflow-ai/langflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/releases/tag/v1.10.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…