CVE-2026-8505 is a critical-severity (CVSS 9.8) Missing Authentication vulnerability in langflow. A fix is available for langflow — see the affected versions and patch details below.
Langflow: Unauthenticated Flow Execution via Webhook Authentication Bypass
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-8505.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-8505 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
langflowReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A vulnerability in Langflow's webhook authentication logic allows unauthenticated users to trigger the execution of any flow. The system incorrectly bypasses API key validation when the WEBHOOK_AUTH_ENABLE configuration is set to False. This allows a remote attacker who knows a flow's UUID to execute it as if they were the owner, potentially leading to Remote Code Execution (RCE) or Denial of Service (DoS).
Details
The WEBHOOK_AUTH_ENABLE setting was introduced in v1.7.0 (#9139) with a default of False. The root cause is in the webhook authentication path, AuthService.get_webhook_user (src/backend/base/langflow/services/auth/service.py; the thin wrapper in src/backend/base/langflow/services/auth/utils.py just delegates to it):
async def get_webhook_user(self, flow_id: str, request: Request) -> UserRead:
settings_service = self.settings
...
# VULNERABILITY: If this setting is False (default in <= 1.9.0), it returns
# the flow owner WITHOUT checking the API Key in the request.
if not settings_service.auth_settings.WEBHOOK_AUTH_ENABLE:
try:
flow_owner = await get_user_by_flow_id_or_endpoint_name(flow_id)
return flow_owner
By default (v1.7.0 through v1.9.0), Langflow treats WEBHOOK_AUTH_ENABLE as False, meaning all webhook endpoints are public. This relies exclusively on the secrecy of the flow_id (UUID), which is an insecure practice (Security by Obscurity).
A related report, GHSA-6g4m-v5q2-475v, demonstrated a concrete RCE chain through this same bypass using the PythonCodeStructuredTool component (exec() on flow-authored Python code). That report is a duplicate of this root cause and has been closed in favor of this advisory; credit for that PoC has been added here.
PoC
- Identify a valid
flow_idfor a flow that performs a sensitive action (e.g., sending an email, writing to a database, or executing a Python script). - Execute a POST request to the webhook endpoint without any
Authorizationheader or API Key:
curl -X POST "http://<server-ip>:7860/api/v1/webhook/<flow_id>" \
-H "Content-Type: application/json" \
-d '{"input": "payload"}'
- Verify that the flow execution is triggered and the action is performed on the server.
Impact
This is a High-severity Authentication Bypass.
- Remote Code Execution (RCE): Flows often contain components that execute arbitrary Python code. An attacker can leverage this to gain full control over the server.
- Denial of Service (DoS): Attackers can exhaust system resources by triggering heavy flows concurrently.
- Data Integrity: Unauthorized execution of flows can lead to unintended modification of databases or external systems connected via the flow.
Affected versions
>= 1.7.0, <= 1.9.0 (the range in which WEBHOOK_AUTH_ENABLE existed and defaulted to False).
Fix
Fixed in v1.9.1 by PR #12845 — fix(security): default WEBHOOK_AUTH_ENABLE to True. The setting's default changed from False to True, so webhook endpoints now require API key authentication and ownership validation by default, unless an operator explicitly opts out via LANGFLOW_WEBHOOK_AUTH_ENABLE=false.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | langflow | ≥ 1.7.0&&< 1.9.1 | 1.9.1pip install --upgrade 'langflow==1.9.1' |
Affected Products
langflowlangflowDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for langflow, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update langflow to 1.9.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-8505 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-8505 in your dependencies?
Find it across PyPI, including transitive dependencies.