PYSEC-2026-4233
Vulnerability from pysec - Published: 2026-10-15 10:22 - Updated: 2026-10-15 14:37Summary
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.
| Name | purl | langflow | pkg:pypi/langflow |
|---|
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langflow",
"purl": "pkg:pypi/langflow"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.9.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.7.0",
"1.7.1",
"1.7.2",
"1.7.3",
"1.8.0",
"1.8.0rc0",
"1.8.0rc1",
"1.8.0rc2",
"1.8.0rc3",
"1.8.0rc4",
"1.8.0rc5",
"1.8.0rc6",
"1.8.1",
"1.8.2",
"1.8.3",
"1.8.3rc0",
"1.8.4",
"1.9.0"
]
}
],
"aliases": [
"CVE-2026-8505",
"GHSA-cf6m-vc3m-7cgm"
],
"details": "### Summary\nA vulnerability in Langflow\u0027s 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\u0027s UUID to execute it as if they were the owner, potentially leading to Remote Code Execution (RCE) or Denial of Service (DoS).\n\n### Details\nThe `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):\n\n```python\nasync def get_webhook_user(self, flow_id: str, request: Request) -\u003e UserRead:\n settings_service = self.settings\n ...\n # VULNERABILITY: If this setting is False (default in \u003c= 1.9.0), it returns\n # the flow owner WITHOUT checking the API Key in the request.\n if not settings_service.auth_settings.WEBHOOK_AUTH_ENABLE:\n try:\n flow_owner = await get_user_by_flow_id_or_endpoint_name(flow_id)\n return flow_owner\n```\n\nBy 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).\n\nA 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.\n\n### PoC\n1. Identify a valid `flow_id` for a flow that performs a sensitive action (e.g., sending an email, writing to a database, or executing a Python script).\n2. Execute a POST request to the webhook endpoint without any `Authorization` header or API Key:\n```bash\ncurl -X POST \"http://\u003cserver-ip\u003e:7860/api/v1/webhook/\u003cflow_id\u003e\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"input\": \"payload\"}\u0027\n```\n3. Verify that the flow execution is triggered and the action is performed on the server.\n\n### Impact\nThis is a **High-severity Authentication Bypass**.\n- **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.\n- **Denial of Service (DoS)**: Attackers can exhaust system resources by triggering heavy flows concurrently.\n- **Data Integrity**: Unauthorized execution of flows can lead to unintended modification of databases or external systems connected via the flow.\n\n### Affected versions\n`\u003e= 1.7.0, \u003c= 1.9.0` (the range in which `WEBHOOK_AUTH_ENABLE` existed and defaulted to `False`).\n\n### Fix\nFixed in **v1.9.1** by [PR #12845](https://github.com/langflow-ai/langflow/pull/12845) \u2014 `fix(security): default WEBHOOK_AUTH_ENABLE to True`. The setting\u0027s 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`.",
"id": "PYSEC-2026-4233",
"modified": "2026-10-15T14:37:45.128373Z",
"published": "2026-10-15T10:22:44.220122Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-cf6m-vc3m-7cgm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8505"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/pull/12845"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/commit/cb6f7508dda83ead9c3e4417e96e4b5bd9a260c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/releases/tag/v1.9.1"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7278921"
},
{
"type": "PACKAGE",
"url": "https://pypi.org/project/langflow"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-cf6m-vc3m-7cgm"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Langflow: Unauthenticated Flow Execution via Webhook Authentication Bypass"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.