Langflow: Unauthenticated Flow Execution via Webhook Authentication BypassCVE-2026-8505

### 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`.

Quoted source text, attributed separately from HOL analysis.