Skip to content

GHSA-qrpv-q767-xqq2 CVE-2026-55255 PYSEC-2026-221

Langflow: IDOR Vulnerability in `/api/v1/responses` Endpoint Allows Authenticated Attackers to Access Another User's Flow

High Known exploited PyPI
Severity
8.4 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.89%
Chance of exploitation in the next 30 days. Higher than 59.29% of scored vulnerabilities.
Known exploited
Yes
In CISA's catalog since Jul 7, 2026
Weakness
CWE-639 Authorization Bypass Through User-Controlled Key
Fix
1.9.1
Upgrade langflow to this version or later
Exploited in the wild. Langflow Authorization Bypass Through User-Controlled Key Vulnerability (Langflow Langflow). Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines. Due for U.S. federal agencies by Jul 10, 2026.

Description

Summary

Insecure Direct Object Reference (IDOR) vulnerability in /api/v1/responses endpoint allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request.

Details

The vulnerability exists in the get_flow_by_id_or_endpoint_name helper function in src/backend/base/langflow/helpers/flow.py (lines 399-414).

When a flow is accessed via UUID (flow_id), the function queries the database directly without verifying if the authenticated user owns that flow:

# src/backend/base/langflow/helpers/flow.py:399-414
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 user_id check!
        except ValueError:
            endpoint_name = flow_id_or_name
            stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)
            # Only when using endpoint_name is user_id checked
            if user_id:
                stmt = stmt.where(Flow.user_id == uuid_user_id)

This function is used by the /api/v1/responses endpoint (defined in src/backend/base/langflow/api/v1/openai_responses.py:589).

PoC (Proof of Concept)

# Attacker (user A) with API_KEY_A tries to execute victim (user B)'s flow
curl -X POST "http://localhost:7860/api/v1/responses" \
  -H "x-api-key: sk-ATTACKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "VICTIM_FLOW_ID",
    "input_value": "test",
    "stream": false
  }'
# Returns 200 and executes the victim's flow

Impact

Any authenticated user can:

  1. Execute any flow in the system by knowing its flow ID
  2. Access potentially sensitive data processed by victim's flows
  3. Consume victim's resources

Fixes

Fixed in PR #12832 (fix(security): close IDOR in get_flow_by_id_or_endpoint_name), merged 2026-04-22, released in Langflow 1.9.1.

The helper normalizes user_id once and enforces ownership on both lookup branches (UUID and endpoint_name):

flow_id = UUID(flow_id_or_name)
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 falls through to the shared 404

Key points:

  • Cross-user lookups return 404 (not 403), so flow existence is not disclosed via a 403-vs-404 oracle.
  • /api/v1/responses and /api/v2/workflow pass user_id explicitly, so fixing the helper closes them directly; the /api/v1/run* routes were additionally moved from a bare Depends(get_flow_by_id_or_endpoint_name) to auth-aware wrapper dependencies (defense in depth).
  • A malformed user_id now fails closed (404 instead of a raw 500).
  • Webhook routes intentionally keep the unscoped lookup (public by design / explicit ownership check elsewhere).
  • Regression tests cover the cross-user UUID case and reproduce the original PoC against /api/v1/responses.

Acknowledgements

Thanks to the security researchers who responsibly disclosed this vulnerability:

  • @yzeirnials
  • @johnatzeropath
  • @LeftenantZero
  • @Zwique

Affected versions

PyPI

PackageVulnerableFixed in
langflow
< 1.9.1
1.9.1
langflow
< 1.9.1
1.9.1
langflow
< 1.9.2
1.9.2

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

langflow PyPI → 1.9.1

pip
pip install --upgrade "langflow>=1.9.1"
poetry
poetry add "langflow>=1.9.1"
uv
uv add "langflow>=1.9.1"

Severity breakdown

CVSS 3.1 8.4

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
Low

Weakness

CWE-639: Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

How to prevent it
  • Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
  • Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
  • Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

References

Timeline

  1. Published
  2. Added to CISA's Known Exploited Vulnerabilities catalog
  3. Remediation due for U.S. federal agencies
  4. Last updated by the source
  5. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-vwmf-pq79-vjvx
Unauthenticated Remote Code Execution in Langflow via Public Flow Build Endpoint
Critical Known exploited Also affects langflow
GHSA-g22f-v6f7-2hrh
Langflow affected by Remote Code Execution via validate_code() exec()
High Known exploited Also affects langflow
GHSA-577h-p2hh-v4mv
Langflow CORS misconfiguration enables Account Takeover and RCE
Critical Known exploited Also affects langflow
GHSA-rvqx-wpfh-mfx7
Langflow Unauth RCE
Critical Known exploited Also affects langflow
GHSA-j8f7-x8jm-wmm4
Langflow: SSRF in URL-taking components (protection disabled by default / warn-only, not applied to RSS, SearXNG, Web Search, Home Assistant, Glean, Docling)
Medium Also affects langflow
GHSA-4f6c-2vvp-gw82
Langflow: IP Spoofing Bypass via `X-Forwarded-For` Allowing Remote Configuration Write
High Also affects langflow
GHSA-4hmc-cfm3-w43c
Langflow has Authenticated Cross-Project File Disclosure via Unscoped MCP Resource Handlers
High Also affects langflow
GHSA-gh98-4phw-6fmw
Langflow : Cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints
Medium Also affects langflow

Credits: Adam-Aghili, AntonioABLima, LeftenantZero, Zwique, andifilhohub, erichare, yzeirnials

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor