CVE-2026-10134: Unauthenticated RCE in IBM Langflow OSS

Affected versions and exposure assumptions

The affected product named by NVD is IBM Langflow OSS, and the affected version range is explicitly stated as 1.0.0 through 1.9.3. That range should be treated as authoritative unless IBM publishes a correction. If your inventory says Langflow OSS is anywhere in that range, you should assume exposure exists until proven otherwise.

The fix version, however, is not confirmed from the source material available here. The vendor advisory excerpt confirms the affected range through 1.9.3, but the remediation section was not available in the retrieved text. In practical terms, defenders should assume that a version later than 1.9.3 is required, but should verify the exact target release in the official IBM bulletin or release notes before upgrading. If you cannot immediately verify the fixed version, the safest near-term position is to remove public exposure and disable workflows that rely on public flows containing code-execution-capable components.

How exploitation works

IBM’s advisory metadata identifies the core unsafe behavior as execution of attacker-controlled Python via:

exec(self.tool_code, globals(), local_namespace)

That line matters because it turns a flow definition field into an execution sink. The advisory metadata indicates two relevant paths. First, an authenticated build path exists at POST /api/v1/build/{flow_id}/flow, where a session token can trigger code execution during flow build. Second, and more seriously, IBM describes an unauthenticated path once a flow is marked PUBLIC: a flow can be set public via PATCH /api/v1/flows/{flow_id} with {"access_type":"PUBLIC"}, after which execution can occur through /api/v1/build_public_tmp/{flow_id}/flow without an Authorization header.

The practical risk is larger than “remote code execution once.” Because NVD notes that a public flow’s tool_code can be modified so later normal /api/v1/build/... operations re-execute attacker code, this creates a persistence mechanism inside expected application behavior. A malicious change to a public flow may survive long enough to repeatedly execute under legitimate user activity, complicating incident response and making log review more important than a simple patch-and-move-on approach.

Exploitation status, PoC status, and what defenders should assume

At the time of writing, exploitation in the wild is not confirmed from the sources provided here. Specifically, CVE-2026-10134 is not listed in CISA’s Known Exploited Vulnerabilities catalog, so there is no KEV-backed confirmation of active exploitation. That said, a KEV absence should not be read as safety. KEV often lags disclosure, and many critical application-layer bugs are exploited before they appear in public government tracking.

Likewise, a public proof of concept was not confirmed from the available source set. No PoC URL was present in the research note’s NVD output, and no attributable repository was verified for this exact CVE. In the absence of a confirmed PoC, defenders should still assume the bug is highly reproducible because the advisory discloses enough implementation detail, affected endpoints, and the code execution sink to materially lower reverse-engineering effort for attackers. For an internet-exposed, multi-tenant, or cloud-connected Langflow deployment, the right assumption is that exploit development time is short.

What to look for right now

Your first priority is determining whether Langflow OSS in the affected range is deployed, whether any flows are public, and whether any recent changes touched tool_code, access controls, or build endpoints. Even if your instance is not internet-exposed, the vulnerability still matters because an internal attacker or compromised user session could mark flows public and use the build path to execute code.

You should also think beyond the application itself. Because the documented impact includes reading process secrets and accessing cloud metadata endpoints, review whether the Langflow process has access to API keys, database credentials, Kubernetes service account tokens, instance metadata, or internal HTTP services. A successful exploit may look like a Langflow event at first but quickly turn into a broader credential-theft or lateral-movement incident.

Technical Notes: Detection

Start with web server, reverse proxy, WAF, or application access logs for the following endpoints:

• PATCH /api/v1/flows/
• POST /api/v1/build/
• POST /api/v1/build_public_tmp/

Concrete patterns worth hunting include unauthenticated POST requests to the public build path, especially from unusual IPs or in bursts. Example grep patterns:

grep -E 'POST /api/v1/build_public_tmp/.*/flow|PATCH /api/v1/flows/.+' /var/log/nginx/access.log

grep -E 'POST /api/v1/build_public_tmp/[A-Za-z0-9_-]+/flow' /var/log/*access*.log

If your logs capture headers, specifically hunt for requests to the public build endpoint without an Authorization header:

jq 'select(.request_uri|test("/api/v1/build_public_tmp/.*/flow")) | {ts, src_ip, method, request_uri, authorization}' /var/log/langflow-access.json

A basic Splunk search might look like this:

index=web (uri_path="/api/v1/build_public_tmp/*/flow" OR uri_path="/api/v1/build/*/flow" OR uri_path="/api/v1/flows/*")
| stats count min(_time) as firstTime max(_time) as lastTime by src_ip http_method uri_path status user_agent authorization
| sort - count

If you have database-level visibility into flow objects, review recent modifications to public flows and specifically inspect any fields named tool_code, component definitions, or serialized flow JSON. Suspicious indicators would include Python imports, shell execution helpers, network libraries, credential access code, or metadata endpoint references such as 169.254.169.254.

Bottom line for defenders

CVE-2026-10134 deserves immediate attention because it combines unauthenticated code execution, secret exposure, data tampering, lateral movement potential, and persistence in a platform that often sits close to AI workflows, APIs, and sensitive credentials. The affected range is clear: IBM Langflow OSS 1.0.0 through 1.9.3. The exact fixed version was not confirmed from the available source excerpt, so defenders should verify it directly from IBM and plan an urgent upgrade.

There is no confirmed KEV listing and no verified public PoC in the source set used for this article. Even so, the vulnerability should be treated as a top-priority remediation item, especially for internet-exposed or multi-tenant deployments. If patching cannot happen immediately, remove public exposure, block the public build path, audit flows for malicious tool_code, and rotate any secrets the Langflow process could access.

For further reading on related vulnerabilities, check out our articles on Firewall and Edge Device CVEs and the Small Business Backup Strategy.