On this page (7 sections)
IBM has published a security bulletin covering Langflow OSS, and one of the listed flaws, CVE-2026-18894, affects public workflows. A remote attacker with no account could trigger Python component code that is already stored in a public flow, and that code would run inside the Langflow server process under the flow owner's runtime context.
If you self-host Langflow and expose any flow publicly, this is worth a look. The score is medium, but the issue breaks a trust boundary that is meant to keep public execution paths limited to server-trusted code.
What happened
The IBM security bulletin describes Langflow OSS as affected by multiple vulnerabilities, including remote code execution and security scanner control issues. CVE-2026-18894 is one entry in that list. The GitHub advisory and the NVD record, published October 29, 2026, repeat the same description. The NVD page is a copy of that text, so it is not separate confirmation.
The description says a remote attacker could trigger pre-existing stored Python component code in a public workflow. It then runs under the flow owner's runtime context within the server process.
Technical details in plain terms
Langflow lets people build workflows from components, and some components contain Python code. Public workflows are meant to be callable by anyone, so the design restricts public execution to component code the server itself trusts. Code that a user wrote and stored in a flow is not in that trusted set.
According to the advisory, that restriction can be bypassed. An outsider can cause stored Python component code to run through a public path, with the permissions and context of the person who owns the flow. The weakness class is code injection (CWE-94): code runs in a place where the application should have kept control over what is allowed to execute.
The sources describe running code that is already stored in the flow, not uploading new code. The CVSS vector reflects limited impact (low confidentiality, low integrity, no availability), but real impact depends on what the stored component does and what the flow owner can reach, such as API keys, databases or connected services. The sources do not describe specific attack outcomes, so treat that as a risk to assess rather than a known result.
Who is affected
- Self-hosted deployments of Langflow OSS from 1.0.0 through 1.12.4.
- Instances where at least one workflow is shared publicly or reachable without authentication.
- Flows that contain Python code components, especially ones that touch credentials, files, databases or outbound services.
- Teams that run Langflow on a server reachable from the internet rather than only on an internal network.
How to check your exposure
Start by finding out which version you run and whether anything is public. The first command shows the installed Langflow package if you installed it with pip. Run it in the same Python environment that runs Langflow, and compare the reported version to 1.12.4.
pip show langflowIf you run Langflow in a container, this command lists running containers and their image tags so you can see which version is deployed. Run it on the Docker host.
docker ps --format '{{.Names}} {{.Image}}'- Confirm the version is within 1.0.0 through 1.12.4.
- In the Langflow interface, list which flows are set to public or shared.
- Open each public flow and note any Python code components and what they can access.
- Check whether the Langflow server is reachable from the internet, and who can reach it.
- Review server and reverse proxy logs for unexpected requests to public flow endpoints.
What to do now
The sources reviewed do not name a fixed version. The GitHub advisory lists patched versions as unknown, and the IBM bulletin is the vendor reference listed for patch information. Read it for the remediation guidance that applies to your release before you change anything.
0 of 7 done
Detection and monitoring
No source reports exploitation, and the GitHub advisory shows an EPSS score of 0.488% (42nd percentile), which estimates the probability of exploitation in the next 30 days. That is a prediction, not a guarantee, so keep watching.
This command searches a web server access log for lines containing "run" and shows the last 100, so you can review who called flow endpoints and how often. Replace the path with your own access log. It is read-only, and the pattern is an example you should adjust to your setup.
grep -i 'run' /var/log/nginx/access.log | tail -n 100- Watch for unusual spikes of requests to public flows from unfamiliar IP addresses.
- Alert on unexpected outbound connections from the Langflow host.
- Monitor for new processes or files created by the Langflow service account.
- Track the IBM bulletin for updates to fixed version information.
Because Langflow often sits on a public hostname, monitoring that hostname's certificate and DNS for unexpected changes is a useful extra signal. Webforta Monitor covers uptime, certificate, DNS and header changes, and the free SSL checker gives a quick look at the certificate. Neither detects this flaw; they help you notice changes around the service.
Timeline
| Date | Event |
|---|---|
| 2026-10-29 | CVE-2026-18894 published to NVD and the GitHub Advisory Database |
| 2026-10-29 | GitHub advisory last updated; IBM bulletin listed as the vendor reference |
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.