CVE-2026-8505

IBM heeft meerdere kwetsbaarheden verholpen in IBM Langflow OSS versies 1.0.0 tot en met 1.10.0.

Ein Angreifer kann mehrere Schwachstellen in IBM Langflow Desktop OSS ausnutzen, um Administratorrechte zu erlangen, beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren und offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.

### 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): ```python 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 1. 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). 2. Execute a POST request to the webhook endpoint without any `Authorization` header or API Key: ```bash curl -X POST "http://<server-ip>:7860/api/v1/webhook/<flow_id>" \ -H "Content-Type: application/json" \ -d '{"input": "payload"}' ``` 3. 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](https://github.com/langflow-ai/langflow/pull/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`.

### 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): ```python 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 1. 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). 2. Execute a POST request to the webhook endpoint without any `Authorization` header or API Key: ```bash curl -X POST "http://<server-ip>:7860/api/v1/webhook/<flow_id>" \ -H "Content-Type: application/json" \ -d '{"input": "payload"}' ``` 3. 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](https://github.com/langflow-ai/langflow/pull/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`.