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_ownerBy 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_id for 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
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"}'
- 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.
References
AntonioABLima Analyst
windbreaker555 Reporter
manus-use Reporter
l3tchupkt Reporter
andifilhohub Remediation reviewer
erichare Remediation developer
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_ENABLEconfiguration is set toFalse. 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_ENABLEsetting was introduced in v1.7.0 (#9139) with a default ofFalse. The root cause is in the webhook authentication path,AuthService.get_webhook_user(src/backend/base/langflow/services/auth/service.py; the thin wrapper insrc/backend/base/langflow/services/auth/utils.pyjust delegates to it):By default (v1.7.0 through v1.9.0), Langflow treats
WEBHOOK_AUTH_ENABLEasFalse, meaning all webhook endpoints are public. This relies exclusively on the secrecy of theflow_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
PythonCodeStructuredToolcomponent (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
flow_idfor a flow that performs a sensitive action (e.g., sending an email, writing to a database, or executing a Python script).Authorizationheader or API Key:Impact
This is a High-severity Authentication Bypass.
Affected versions
>= 1.7.0, <= 1.9.0(the range in whichWEBHOOK_AUTH_ENABLEexisted and defaulted toFalse).Fix
Fixed in v1.9.1 by PR #12845 —
fix(security): default WEBHOOK_AUTH_ENABLE to True. The setting's default changed fromFalsetoTrue, so webhook endpoints now require API key authentication and ownership validation by default, unless an operator explicitly opts out viaLANGFLOW_WEBHOOK_AUTH_ENABLE=false.References