CVE-2026-55255: Langflow IDOR in /api/v1/responses Allows Authenticated Attackers to Execute Arbitrary User Flows

Background

Langflow is an open-source, low-code framework for building AI agent workflows and LLM-powered applications. It provides a visual graph-based interface for chaining together AI models, data sources, tools, and output handlers into deployable flows. Langflow is widely used in enterprise environments for prototyping and production deployment of multi-agent AI systems, including internal tools handling sensitive business data.

Multi-user Langflow deployments are common in enterprise settings, where different users build and deploy flows that may access sensitive internal systems, proprietary data, or external services via configured API keys. The expectation is that a user’s flows are private — other users cannot see, access, or execute flows they do not own unless explicitly shared.

CVE-2026-55255 breaks this isolation. An Insecure Direct Object Reference (IDOR) in the /api/v1/responses endpoint allows any authenticated Langflow user to execute a flow belonging to any other user simply by supplying the victim’s flow identifier in the API request. No admin privileges are required. The vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and carries a CVSS score of 9.9 (Critical). CISA added it to the Known Exploited Vulnerabilities catalogue, and both CISA and VulnCheck confirm active exploitation.

Technical Mechanism

The vulnerability exists in the get_flow_by_id_or_endpoint_name helper function located in src/backend/base/langflow/helpers/flow.py (approximately lines 399–414 in affected versions). This function is called by the /api/v1/responses endpoint to resolve a flow before executing it.

Under vulnerable versions, the function retrieves the flow matching the supplied identifier without verifying that the requesting authenticated user is the owner or has been granted access to that flow. The ownership check is absent — the endpoint validates that the caller is authenticated (has a valid JWT) but not that they are authorised to act on the specific resource identified by the caller-supplied flow ID.

# Vulnerable code path (simplified, pre-1.9.2)
# src/backend/base/langflow/helpers/flow.py

async def get_flow_by_id_or_endpoint_name(
    flow_id_or_name: str,
    user_id: UUID | None = None,
    db: AsyncSession = None
) -> Flow:
    # Retrieves flow by ID from database
    # BUG: Does not verify requesting user owns this flow
    flow = await db.get(Flow, UUID(flow_id_or_name))
    if not flow:
        flow = await get_flow_by_endpoint_name(flow_id_or_name, db)
    return flow  # Returns any user's flow without ownership check

# Fixed code path (1.9.2+)
async def get_flow_by_id_or_endpoint_name(
    flow_id_or_name: str,
    user_id: UUID | None = None,
    db: AsyncSession = None
) -> Flow:
    flow = await db.get(Flow, UUID(flow_id_or_name))
    if not flow:
        flow = await get_flow_by_endpoint_name(flow_id_or_name, db)
    # FIX: Verify that requesting user owns or is authorised to access this flow
    if flow and user_id and flow.user_id != user_id:
        raise HTTPException(status_code=403, detail="Not authorized to access this flow")
    return flow

The exploit requires only a valid Langflow authentication token and the UUID of a target flow. Flow UUIDs are referenced in API responses and URLs within the Langflow UI, so any user who has legitimate access to the system can observe flow IDs from their own UI session and attempt them against the vulnerable endpoint.

# CVE-2026-55255: Execute another user's flow using only their flow_id
# Attacker has a valid Langflow account but does not own the target flow

# Step 1: Authenticate as attacker user, obtain JWT
curl -s -X POST "https://langflow.company.com/api/v1/login" \
  -H "Content-Type: application/json" \
  -d '{"username": "attacker@company.com", "password": "attacker_password"}' \
  | jq '.access_token'

# Step 2: Execute a flow owned by another user by supplying their flow_id
# (flow_id obtained from API responses, URL, or enumeration)
curl -X POST "https://langflow.company.com/api/v1/responses/[VICTIM_FLOW_UUID]" \
  -H "Authorization: Bearer [ATTACKER_JWT]" \
  -H "Content-Type: application/json" \
  -d '{"input_value": "Attacker-controlled input", "tweaks": {}}'

# The server executes the victim's flow with attacker input and returns results
# This exposes flow logic, connected data sources, API keys in flow config, and output data

The impact extends beyond reading flow outputs. Depending on the flow’s configuration, executing it may:

• Query internal databases or APIs that the victim user is authorised to access
• Invoke LLM chains with system prompts containing proprietary instructions
• Exfiltrate data from connected data sources (vector databases, document stores, SQL databases)
• Trigger actions in connected external systems (CRM updates, email sends, API calls)
• Expose API keys configured in flow component credentials (embedded in flow configuration returned by some API endpoints)

Real-World Exploitation Evidence

Both CISA and VulnCheck confirm active exploitation of CVE-2026-55255 in the wild. Langflow’s relevance to enterprise AI deployments makes it a high-value target — compromising one user’s flow in a shared Langflow deployment can expose data from any system that user’s flows connect to.

Observed exploitation patterns focus on multi-user enterprise Langflow deployments where:

• Different business units share a Langflow server with isolated flow namespaces
• Flows are connected to internal databases, knowledge bases, or sensitive document repositories
• Flow configurations contain embedded API keys for external AI services or internal APIs

In authenticated multi-tenant environments, a low-privilege user account (potentially obtained through credential stuffing or phishing) is sufficient to access every flow on the server, enumerate connected data sources, and execute arbitrary AI workflows.

Impact Assessment

• Cross-user flow execution — any authenticated user can invoke any other user’s flows, bypassing all access isolation in the Langflow permission model
• Data exfiltration via flow execution — flows connected to internal data sources (databases, document stores, APIs) will return data in response to attacker-controlled queries
• Proprietary AI logic exposure — system prompts, chain configurations, and proprietary AI workflow designs are exposed when flows are executed
• API key exposure — flow configurations may contain API keys for external services; these are accessible via the flow execution response or through API endpoints that return flow configuration data
• Privilege escalation via connected tools — flows belonging to users with higher system access can be invoked by lower-privileged users, effectively escalating the attacker’s access to whatever systems those flows connect to
• Regulatory and compliance implications — if the exposed flows process personal data, health records, financial data, or other regulated categories, exploitation constitutes a reportable data breach

Affected Versions

Langflow 1.9.2 adds ownership and authorisation checks to the /api/v1/responses endpoint so that flows can only be executed by their owners or users who have been explicitly granted access.

Remediation Steps

1. Upgrade Langflow to version 1.9.2 or later:

# pip upgrade
pip install --upgrade langflow

# Verify installed version
python -c "import langflow; print(langflow.__version__)"
# Expected: 1.9.2 or higher

# Docker deployment — update image tag
docker pull langflowai/langflow:1.9.2
docker stop langflow && docker rm langflow
docker run -d --name langflow -p 7860:7860 langflowai/langflow:1.9.2

# Kubernetes deployment
kubectl set image deployment/langflow langflow=langflowai/langflow:1.9.2
kubectl rollout status deployment/langflow

2. Audit flow access logs — review Langflow server logs for API calls to /api/v1/responses/[flow_id] where the authenticated user does not own the referenced flow ID:

# Search Langflow logs for cross-user flow execution
# Compare authenticated user identity in JWT with flow owner in database
grep "api/v1/responses" /var/log/langflow/access.log | grep -v "200"

# Check for unusual access patterns (users accessing many different flow IDs)
awk '/api\/v1\/responses/{print $1, $7}' /var/log/langflow/access.log \
  | sort | uniq -c | sort -rn | head -20

3. Rotate all API keys stored in Langflow flow configurations — if exploitation is suspected, any API keys embedded in flow components should be considered compromised and rotated in the respective external services

4. Review connected data source permissions — evaluate what data was accessible through each flow that may have been invoked without authorisation; assess regulatory notification obligations if personal or sensitive data was exposed

5. Enable authentication and access controls — for self-hosted Langflow deployments, ensure authentication is enabled and restrict access to the Langflow server to only authorised network segments:

# Langflow startup with authentication enforced
langflow run --host 0.0.0.0 --port 7860 --no-skip-auth

# Environment variable
LANGFLOW_AUTO_LOGIN=false langflow run

6. Restrict Langflow to internal network only — if Langflow is exposed to the internet, move it behind a VPN or network access control layer; the attack requires a valid authenticated session, but credential theft or weak passwords lower the bar significantly

Detection Guidance

Monitor Langflow API access logs for requests to the responses endpoint where the JWT user does not match the flow owner:

• API calls to /api/v1/responses/[uuid] from user accounts that do not own the referenced flow UUID
• Unusually high volume of requests to different flow UUIDs from a single user (enumeration)
• API calls to /api/v1/flows without subsequent expected UI interactions (suggests automated enumeration)
• Successful flow executions from IP addresses that have no prior access to the Langflow UI

# Splunk — detect cross-user flow execution (requires correlating JWT user with flow ownership)
index=langflow sourcetype=access_log
| rex field=_raw "POST /api/v1/responses/(?P<flow_id>[a-f0-9-]{36})"
| rex field=_raw "\"user\":\"(?P<requesting_user>[^\"]+)\""
| join type=left flow_id [
    search index=langflow sourcetype=flow_metadata
    | rename owner as flow_owner, id as flow_id
  ]
| where requesting_user != flow_owner
| stats count, values(flow_id) as accessed_flows by requesting_user, src_ip, _time
| sort -count

# Suricata — detect high-volume flow ID enumeration
alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"CVE-2026-55255 Langflow Responses Endpoint Access"; flow:established,to_server; content:"POST"; http_method; content:"/api/v1/responses/"; http_uri; pcre:"/\/api\/v1\/responses\/[0-9a-f-]{36}/"; threshold:type threshold, track by_src, count 10, seconds 60; sid:2026552551; rev:1;)

Timeline

References

• NVD — CVE-2026-55255
• CISA KEV — CVE-2026-55255
• GitHub Security Advisory — GHSA-qrpv-q767-xqq2
• Langflow Release Notes — 1.9.2
• GitLab Advisory — CVE-2026-55255