IBM Langflow CVE-2026-9135

Exploitation requires an authenticated account with flow-creation privileges (CVSS PR:L) and a deployment that uses the Policies component's ToolGuard integration where allow_custom_components=false is relied upon as the security boundary. The specific abusable primitive is the dynamic CodeInput field storing generated ToolGuard Python (persisted in Flow.data), which is not validated the way node_template["code"]["value"] is; the payload only executes when a guarded tool is actually invoked through the ToolGuard runtime. Cross-tenant escalation additionally requires access to the agentic MCP update_flow_component_field tool, which accepts an attacker-controlled user_id. Limiting factors: an authenticated flow-creation account is needed, and the target must run ToolGuard-guarded tools - however, the misconfigurations AUTO_LOGIN=true and NEW_USER_IS_ACTIVE=true combined with publicly accessible flows substantially lower the authentication barrier.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 9.9) reflects network-reachable, low-complexity exploitation requiring only low privileges, with a scope change justified by cross-tenant flow manipulation and full confidentiality/integrity/availability impact from backend RCE - a genuinely high-priority issue rather than an inflated score. No EPSS score, KEV listing, or public POC was provided, so exploitation is not confirmed in the wild and probability data is missing; the SSVC exploitation status is best treated as 'none/POC-unknown' pending better data. The one caveat worth flagging: exploitation does require an authenticated account with flow-creation rights (PR:L), so the practical attack surface narrows to environments that expose Langflow to semi-trusted users - though the described AUTO_LOGIN=true / NEW_USER_IS_ACTIVE=true misconfigurations plus publicly accessible flows can effectively lower that barrier toward unauthenticated. Overall this is a real priority to patch, especially on multi-tenant or internet-exposed deployments.

An authenticated user with flow-creation rights builds a flow using the Policies/ToolGuard component and embeds malicious Python not in the main component code but in a dynamic CodeInput field that escapes validation. When a guarded tool in that flow is later invoked, the ToolGuard runtime executes the attacker's code server-side, yielding arbitrary command execution on the backend; using the MCP update_flow_component_field tool with a spoofed user_id, the attacker can plant the payload into a victim tenant's flow. No public POC is identified at time of analysis, but the low attack complexity makes exploitation straightforward once a foothold account exists.