SURIQ
If you hardened your Langflow install by setting LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, the promise was simple: users can build flows, but they cannot make the server run arbitrary code. A new critical flaw voids that promise. IBM published CVE-2026-19295 on August 28, rated it 9.9 out of 10, and a proof-of-concept exploit is already sitting on GitHub. Any account that can build a flow can run operating-system commands on the machine that hosts Langflow, whether or not you turned custom components off.
That last part is the whole story. This is not another "if you let people run custom code, they can run custom code" finding. It is a way past the exact control operators use to say no.
What is affected
The flaw sits in IBM Langflow OSS, the open-source visual builder for wiring up large-language-model apps and agents. It affects releases from 1.0.0 up to and including 1.11.1, per IBM's advisory and the CVE record. Upgrade to the fixed release IBM names in that advisory; at the time of writing IBM had not published a public in-the-wild exploitation report, but a public proof-of-concept went up the same day the CVE was published, so treat the clock as running.
How the bypass works, at a defender's level
The weakness is an eval-injection bug (CWE-95). A signed-in user saves a workflow whose internal type value has been tampered with, then starts a build of a second, wrapper workflow that references the first. During that build, the rigged value is evaluated as a command, and it runs under the identity of the Langflow server process itself. IBM scores it 9.9 because the impact crosses a trust boundary: a low-privileged builder account ends up with full read, write, and execute on the host, not just inside the app.
The LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false setting is meant to stop users from introducing executable code through the custom-component path. This flaw reaches code execution through the flow-build path instead, which the setting does not govern. That is why a configuration many teams treat as "we locked it down" offers no protection here.
There is no public exploit code reproduced in this post, and there will not be. The takeaway a defender needs is that the precondition is only an account with permission to create and build flows, and the payoff is command execution on the box.
"Authenticated" is a thinner wall on Langflow than it sounds
It is tempting to downgrade this in your head because it needs a login. On Langflow specifically, that login is a lower bar than the CVSS vector implies, for two reasons we have documented before.
First, Langflow has shipped with an auto-login default that handed any visitor an admin session, which chained straight into code execution. If an instance still runs that way, "authenticated" is whoever can reach the port. Second, self-hosted Langflow instances are routinely exposed to the internet with weak or shared credentials, because the builder is designed to be collaborative. Combine an internet-reachable builder with a low-privilege account, and CVE-2026-19295 turns that account into a shell.
This is the fifth Langflow code-execution issue we have covered, after the validation-endpoint RCE that reached CISA's exploited list, the rigged-document file-reader takeover, the auto-login default above, and a cross-user flow-execution flaw. The pattern is consistent: a tool built to turn user input into executable pipelines keeps finding new paths from "user input" to "executable."
Patch, then assume nothing about the lockdown
The fix is to upgrade to the patched Langflow release. That is step one and it is not optional. But because the vulnerable window may already have opened on any exposed instance, and because the lockdown flag many teams relied on did not hold, do these in parallel:
- Take the builder off the open internet. Put Langflow behind a VPN or an authenticating reverse proxy, and restrict flow-create and flow-build permissions to accounts that genuinely need them. This shrinks the population that can reach the vulnerable path.
- Run it least-privileged and contained. Langflow should run as a non-root user, inside a container with a read-only root filesystem where possible, with tight egress rules. If a build does execute a command, that containment is what keeps a flow bug from becoming host and network compromise.
- Rotate anything the host could reach. Any credential, token, or model key stored on or reachable from the Langflow server should be treated as potentially exposed on an instance you cannot prove was clean during the exposure window.
How to know if a flow was weaponized
Command execution through this flaw shows up as the Langflow server process spawning a child it has no business spawning. That is your highest-signal detection. Alert when the Langflow application process (the Python interpreter running it) launches a shell or an ad-hoc interpreter:
parent: python (langflow)
child: /bin/sh | /bin/bash | sh -c | python -c
verdict: alert
On top of process ancestry, watch for unexpected outbound connections from the Langflow host, new or modified files in the app's working directories, and a burst of flow save-then-build events from a single low-privilege account. A managed detection service maps this kind of activity to MITRE ATT&CK execution and command-and-control techniques and flags it whether or not you have written the rule yourself; if you run your own monitoring, the process-ancestry alert above is the one to add today.
Low-code AI builders keep colliding with the same wall: their entire value is turning what a user types into something that runs, which is one small mistake away from turning what a user types into something that runs on the server. Langflow will not be the last tool in this category to learn it in public. Treat every one of them as an application that executes untrusted input, because that is what it is.