CVE-2026-8505

IBM Langflow OSS 1.0.0 through 1.10.0 has 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 (which is the default setting). 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).

IBM Langflow OSS 1.0.0 through 1.10.0 has 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 (which is the default setting). 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).

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-cf6m-vc3m-7cgm. This link is maintained to preserve external references.

Original Description

IBM Langflow OSS 1.0.0 through 1.10.0 has 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 (which is the default setting). 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).

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

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:

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 — 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.

IBM Langflow OSS 1.0.0 through 1.10.0 has 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 (which is the default setting). 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).

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-cf6m-vc3m-7cgm. This link is maintained to preserve external references.

Original Description

IBM Langflow OSS 1.0.0 through 1.10.0 has 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 (which is the default setting). 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).

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

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:

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 — 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):

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:

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 — 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.