Langflow 1.11.2: eight flaws from A2A and MCP to remote code execution
CVE-2026-19286 and CVE-2026-19295 show how a public agent, type evaluation and inconsistent authorization can compromise an AI platform server.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 29 August 2026
- READING TIME
- 21 min read
- TOPIC
- AI Security
Eight CVE records affecting Langflow OSS entered NVD just after midnight on 29 August in Warsaw. The most severe are CVE-2026-19295, scored 9.9, and CVE-2026-19286, scored 9.8. The former lets an authenticated user bypass the policy that disables custom components and run operating-system commands. The latter exposes unauthenticated Python execution through the public Agent-to-Agent path.
Today’s development is publication and indexing of coherent CVE records. IBM issued its bulletins on 21 and 24 August. That distinction matters: these flaws were not discovered today, but on 29 August scanners, risk registers and vulnerability-management processes received unambiguous identifiers. Every issue covered here affects Langflow OSS 1.0.0 through 1.11.1. IBM recommends upgrading to 1.11.2 and provides no workaround that replaces the fix.
The group is a useful lesson in agent-platform engineering. A single filter did not fail. Consistent policy enforcement failed across public A2A, MCP, legacy flow-build endpoints, an input-schema function and model clients with configurable base URLs.
Two critical code-execution paths
CVE-2026-19286 affects public Agent-to-Agent execution. Other public Langflow surfaces invoked validate_public_flow_no_code_execution, intended to reject flows containing code-execution components. The A2A path did not call the same control. If an operator published an agent flow with auth_type=none and enabled A2A, a remote unauthenticated client could execute Python in the backend process.
The prerequisites need to be read accurately. Merely installing an affected package does not automatically expose public RCE. A2A must be enabled and a suitable unauthenticated flow must be published. When those conditions hold, the attack needs neither an account nor user interaction, explaining the CVSS 3.1 score of 9.8.
CVE-2026-19295 crosses a different boundary. A user able to save a flow supplies a crafted type field and triggers a wrapper flow that references it. The controlled value reaches Pydantic ForwardRef handling, where eval() processes it with Python built-ins available. The result is arbitrary operating-system commands in the Langflow process context.
The path bypasses LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false because it does not modify a field recognised as explicit code. The protection examined the input name rather than whether its value would eventually reach an interpreter. That is why the CVSS score is 9.9: a low-privilege account is required, but successful execution crosses a security boundary and compromises server confidentiality, integrity and availability.
A third code-execution flaw, CVE-2026-18729 (8.8), concerns the PythonFunction component and the private tweak channel of RunFlow. IBM describes inconsistent enforcement: this path filtered the literal field name code without applying the shared code-field control used elsewhere. An authenticated user could bypass the same hardening setting through an alternate route.
Five flaws at identity, file and network boundaries
The remaining issues should not be dismissed because their scores are lower. They may supply data, secrets or the foothold required for a later incident stage.
- CVE-2026-18891, 8.2: the MCP project authentication function omitted the default
auth_type=nonevalue from the modes requiring an API key. On Streamable HTTP and SSE-message transports, an unauthenticated client could resolve to the system superuser when MCP Composer was enabled. IBM describes this as an incomplete prior fix. - CVE-2026-18899, 7.5: a public flow-build endpoint passed an unvalidated
filesparameter to storage. Traversal travelled through the uncheckedflow_idsegment and bypassed the existing path-containment guard, enabling unauthenticated reads of files accessible to the process. - CVE-2026-18904, 8.2: public flow metadata exposed the owner’s
user_id. An anonymous client could reuse it asclient_id, collide with the owner’s virtual session namespace, read public-playground history and inject messages into it. - CVE-2026-19294, 6.4: legacy build endpoints remained routed but lacked the object-ownership check present in the current endpoint. One signed-in tenant could enumerate and execute another tenant’s private flow components and read values embedded in the graph.
- CVE-2026-18545, 4.3: the unified model-instantiation path accepted tenant-controlled base URLs for providers such as ChatOllama and ChatOpenAI without invoking the connector SSRF guard. An authenticated user could direct backend requests to loopback, internal services or cloud metadata.
The common architectural cause is duplication of security decisions. When every route independently decides whether to validate code, ownership, authorization and a destination address, a new or compatibility endpoint can easily omit one rule.
Who is exposed and how to establish scope
Inventory instances, container images, application dependencies and notebook environments containing Langflow OSS. A version shown in the UI may not identify the image currently scheduled by an orchestrator, so confirm the image digest and package version inside the active workload. IBM identifies 1.0.0–1.11.1 as affected.
Then evaluate functional conditions. Is A2A reachable from an untrusted network? Are any flows published with auth_type=none? Are MCP Composer and HTTP/SSE transports active? Is user registration broad, and can accounts create or import flows? Can the process access cloud secrets, model tokens, the Langflow database, shared directories or a container socket?
That last question determines the practical blast radius. Code running as an isolated, secretless user in a container with constrained egress has a different impact from the same code in a process holding an AI-provider key, workload identity, write access to a shared volume and internal API reachability.
Upgrade and post-fix actions
Move to Langflow OSS 1.11.2 or a later vendor release first. Test the update against representative flows because the fixes change validation and authorization across several paths. Regression testing should confirm A2A, MCP, public flows, model clients and imported schemas without restoring unsafe exceptions.
Until the upgrade is complete, restrict network exposure of A2A, MCP and public endpoints, disable unused features and close open account registration. Do not treat that as a complete remedy: IBM lists no official workaround, and the flaws span multiple surfaces. Process egress should pass through a controlled proxy or network policy that rejects loopback, link-local, private ranges and metadata endpoints unless explicitly required.
After patching, invalidate sessions and review accounts and published flows. If the instance was public or suspicious graph builds are present, rotate secrets available to the process: model keys, JWT material, database credentials, cloud tokens and connector credentials. Updating the package does not revoke a secret already disclosed.
Detection and incident analysis
Search logs for public A2A calls that reach code components, unusual type values, wrapper-flow builds by accounts that do not normally perform them and use of the private tweak channel. For MCP, focus on sessions without an API key that received a system identity. For traversal, examine unusual files and flow_id values without copying exposed file contents into a broadly accessible log platform.
SSRF is best observed at egress: connections from Langflow to loopback, link-local, RFC1918 or unapproved model hosts. For session-namespace collisions, correlate client_id, user_id, source address and the read/write message sequence. A public flow by itself is not an indicator; unexpected execution context is what matters.
Preserve configuration history, deployment manifests, image digests, flow inventory, proxy and orchestrator logs, and identity events. If code execution occurred, treat the server or container as potentially compromised and rebuild it from a trusted artifact instead of relying only on deletion of a suspicious flow.
Source facts and Breachroad conclusions
Mechanisms, prerequisites, CVSS scores, affected versions and the 1.11.2 fix come from IBM bulletins and CVE records. Feature segmentation, rotation order and detection ideas are Breachroad’s defensive conclusions. Vendor sources do not report active exploitation of these eight flaws in a specific attack. An affected instance is evidence of exposure, not automatic proof of compromise.
Primary sources
- IBM: authentication, authorization, traversal and SSRF flaws
- IBM: three remote-code-execution paths
- Langflow 1.11.2 on PyPI
- NVD: CVE-2026-19286
- NVD: CVE-2026-19295
An agent platform joins code, models, data and credentials, so its trust boundaries need to be tested as one system. Our secure AI implementation workshops cover threat modelling for these flows and consistent policy enforcement. Organisations that need technical validation can assess public flows, MCP, A2A and egress through a controlled AI red-team engagement.


