What Happened

On July 7, 2026, CISA added three vulnerabilities to the Known Exploited Vulnerabilities (KEV) catalog based on confirmed active exploitation. One of them is worth a closer look for anyone running internal AI tooling: CVE-2026-55255, an authorization bypass in Langflow, the open-source visual builder for LLM workflows.

The other two entries in that same KEV batch, CVE-2026-48908 (JoomShaper SP Page Builder) and CVE-2026-56290 (Joomlack Page Builder), are CMS plugin file upload and access control issues. Standard WordPress-adjacent fare. Langflow is the interesting one here because it sits inside a growing category of software that most security teams haven't fully inventoried yet: internal LLM orchestration platforms with API keys, stored credentials, and direct access to whatever data the flows touch.

Why This Matters for Defenders

Langflow is deployed by a lot of teams prototyping or running production LLM pipelines. It's the kind of tool that gets stood up by a data science or platform engineering group, often with less security scrutiny than a customer-facing app gets, because "it's internal" and "it's just an AI builder." That assumption is exactly what makes an IDOR here dangerous.

If your organization runs Langflow and any of the following are true, this is a same-week patch, not a next-sprint patch:

  • Multiple users or teams share a single Langflow instance
  • Flows contain embedded credentials, API keys to other systems, or connections to internal data sources
  • The /api/v1/responses or /api/v2/workflow endpoints are reachable by anyone other than the flow's owner
  • You don't currently log or monitor API key usage against flow ownership

CVSS 9.9. Network attack vector, low complexity, low privileges required (you just need any valid API key on the instance), no user interaction. Confidentiality and integrity impact both rated high.

Technical Detail on the Flaw

This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key), also known as IDOR. The bug lives in the get_flow_by_id_or_endpoint_name helper in src/backend/base/langflow/helpers/flow.py. When a flow is looked up by its UUID, the function queries the database directly and never checks whether the requesting user actually owns that flow:

# src/backend/base/langflow/helpers/flow.py:399-414 (pre-1.9.1)
async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead:
    async with session_scope() as session:
        try:
            flow_id = UUID(flow_id_or_name)
            # When using UUID, query directly WITHOUT checking user_id
            flow = await session.get(Flow, flow_id)  # no ownership check
        except ValueError:
            endpoint_name = flow_id_or_name
            stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)
            if user_id:
                stmt = stmt.where(Flow.user_id == uuid_user_id)

Note the asymmetry: lookup by endpoint_name checks user_id, lookup by UUID doesn't. The /api/v1/responses endpoint calls this helper with a flow ID, so any authenticated user who knows (or guesses, or enumerates) a victim's flow UUID can execute that flow under their own API key.

Attacker Perspective

# Attacker (user A) holding their own valid API key executes
# victim (user B)'s flow by ID alone. No ownership check occurs
# server-side, so any authenticated key + any known flow UUID works.
curl -X POST "https://langflow.internal.example.com/api/v1/responses" \
  -H "x-api-key: sk-ATTACKER_OWN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "b7e2a9c4-1f3d-4a8e-9c21-6d5f0e8a2b17",
    "input_value": "test",
    "stream": false
  }'
# Returns HTTP 200 and runs the victim flow, returning its output

Flow UUIDs aren't secret by design in most deployments (they show up in share links, logs, and the UI itself), so the practical barrier here is just having any valid credential on the instance, not the target's.

Defender Perspective

There's no clean Event ID for this one, Langflow doesn't ship Windows Event Log integration, and this isn't an AD or Windows-native attack surface. The honest answer per the house rule here: if you're logging Langflow API traffic to a SIEM (reverse proxy access logs or an application log forwarder), the detection is a mismatch between the API key's owning user and the flow ID's owning user, which requires you to join proxy/access logs against Langflow's internal flow-ownership table. Langflow itself doesn't emit that correlation as a log field prior to the fix, which is the actual gap. If you have reverse proxy logs (nginx, Traefik, an API gateway) sitting in front of Langflow, a Sigma-style rule against /api/v1/responses calls where the x-api-key prefix doesn't match the expected owner for the requested flow ID is the closest workable detection, but it depends on you already maintaining that key-to-user mapping outside Langflow. Absent that, your realistic move is patch first, hunt second.

# Sigma rule (generic HTTP proxy log source, vendor-neutral)
# Requires an external key-owner-to-flow-owner join; not a native
# Langflow log field. Treat this as a starting point, not a
# drop-in detection.
title: Langflow Cross-User Flow Execution via /api/v1/responses
id: 8f2c1e40-langflow-idor-cve-2026-55255
status: experimental
logsource:
  category: proxy
  product: reverse_proxy
detection:
  selection:
    cs-uri-path|contains: '/api/v1/responses'
    cs-method: 'POST'
  condition: selection
falsepositives:
  - Legitimate shared-flow use cases where cross-user execution is by design
level: medium
fields:
  - x-api-key
  - requested_flow_id
  - source_ip
note: >
  This rule flags all calls to the endpoint for manual review against
  a flow-ownership table maintained outside Langflow. It cannot, on
  its own, distinguish authorized from unauthorized cross-user access
  pre-patch.

The actual fix, and it's the priority action:

pip install --upgrade "langflow>=1.9.1"

Langflow 1.9.1 closes both lookup branches, enforces ownership on UUID and endpoint-name lookups alike, and returns a uniform 404 for cross-user lookups instead of leaking existence via a 403-vs-404 oracle. It also moves the /api/v1/run* routes off the bare unscoped dependency as defense in depth.

Remediation Guidance

  • Patch to Langflow >= 1.9.1 immediately. This is the fix, not a mitigation. There is no reasonable compensating control that closes an IDOR at this severity without the code fix.
  • If you cannot patch same-day, restrict network access to the Langflow instance to known internal ranges only, and treat every API key on the instance as equally privileged until patched (because right now, they effectively are).
  • Rotate API keys post-patch if you have any reason to believe the flaw was exploited. There's no reliable retroactive log signal to confirm this from Langflow's side alone, so if audit certainty matters, rotation is the pragmatic move.
  • Inventory whether you're actually running Langflow. This is worth saying plainly: a lot of orgs have it running somewhere via a data science team's proof-of-concept that never got decommissioned. Check your container registries and internal DNS for it.
  • If federal: CISA's KEV entry sets a remediation due date under BOD 26-04. Check the catalog entry directly for the exact deadline.