CVE-2026-17633: Langflow OSS RCE via custom_component endpoint in versions 1.0.0–1.10.3

What happened

A high-severity remote code execution vulnerability, tracked as CVE-2026-17633, affects the open-source version of Langflow from 1.0.0 through 1.10.3. According to a technical write-up on dev.to, which builds on an IBM security advisory dated August 5, 2026, the flaw is reachable through the POST /api/v1/custom_component API route. It carries a CVSS score of 8.5 and is classified as CWE-94, improper control of code generation.

Langflow is a low-code platform for visually building LLM applications and agent workflows. Its custom components feature accepts Python code that defines how a component behaves, and that code runs on the server. The preconditions are modest: the dev.to analysis states that any authenticated account, regardless of privilege, is enough, provided the deployment sets LANGFLOW_ALLOW_CUSTOM_COMPONENTS to true — a setting the author describes as common in production.

How the flaw works

The problem is not a total absence of checks but that the existing check answers the wrong question. As the dev.to write-up explains, the only gate on the vulnerable handler in langflow/api/v1/endpoints.py verifies whether the custom-component feature is switched on. It never inspects what the submitted code actually does, and a separate AST-based security scanner shipped by Langflow is never invoked on this path.

Deeper in the stack, the request flows through build_custom_component_template() into create_class(), which calls prepare_global_scope() in lfx/custom/validate.py. That function parses the submitted code into an abstract syntax tree and keeps only selected node types: imports, class definitions, function definitions and assignments. Anything else — including a bare top-level call such as an os.system invocation — is a plain expression statement at the AST level and is quietly discarded.

That filtering logic creates the opening. A payload at module level gets thrown away, but a payload placed inside a class body is part of the class definition node. When the collected code is compiled and handed to Python's exec(), the class body runs the moment the class is defined. An attacker only needs to place the malicious statement inside the class — no encoding tricks or filter gymnastics required.

The exploit chain

End to end, the attack works like this: an authenticated user posts a Python class containing the payload to /api/v1/custom_component. The code travels through build_custom_component_template() and create_class(), prepare_global_scope() collects the ClassDef node, and exec() runs the class body, achieving code execution. The dev.to write-up stresses that a single HTTP request suffices and that no LLM interaction is involved at any point in the chain.

Why the built-in scanner did not help

Langflow ships scan_code_security(), an AST-based scanner located in langflow/agentic/helpers/code_security.py. According to the analysis, it is wired only into the Agentic Assistant path, where it validates component code generated by an LLM. The vulnerable endpoint never calls it, so this is not a case of defeating a scanner — the code path simply had no scanner attached in the first place.

The scanner itself also has a separate weakness, involving missing coverage of vars() calls that can produce a false safe verdict. That issue is tracked as CVE-2026-17632 and emerged from analysis of the same codebase, but it is distinct from the RCE.

Patch and mitigation

The dev.to write-up recommends several steps:

• Upgrade to Langflow 1.10.4 or later, which adds content validation to the custom_component endpoint.
• Keep LANGFLOW_ALLOW_CUSTOM_COMPONENTS set to false in production unless the feature is genuinely needed.
• If custom components must stay enabled, restrict which accounts can reach the feature.
• Audit the group memberships of the container's runtime user — the analysis specifically flags gid=0 membership — to reduce lateral-movement and container-escape surface.

Why it matters

Langflow exists to let users submit Python, so the line between a designed-in feature and arbitrary code execution is unusually thin. This vulnerability shows what happens when a capability check — is the feature switched on — stands in for a safety check — is this code safe to run. Any self-hosted instance running an affected version with custom components enabled and multiple authenticated users should treat the endpoint as exposed and patch as a priority. The fix in 1.10.4 adds the missing content validation, but the broader lesson extends to every extensible platform: when a product's core function is executing user-supplied code, validation has to cover every code path, and a security scanner that guards only one route leaves the rest of the surface open.