CVE-2026-13448 is a high severity flaw (CVSS 8.1) in Langflow OSS 1.0.0 through 1.10.1. An incomplete denylist on the public flow build endpoint lets some code execution components through, with no login. IBM says to upgrade Langflow OSS to version 1.10.2 and lists no workaround.
What's affected
IBM lists Langflow OSS 1.0.0 through 1.10.1 as affected. The record names Windows, macOS and Linux as platforms. IBM recommends upgrading to 1.10.2 and states there are no workarounds or mitigations.
The affected code is the public flow build endpoint. A function meant to block flows that can execute code uses a denylist, and it did not cover several agent components, including OpenDsStarAgent, CodeActAgentSmolagents and CSVAgent.
How to check if you're exposed
Check the installed version:
pip show langflow
langflow --version
In a container, read the image tag and the package version inside it. Then check whether any flows are marked public and whether the instance is reachable from the internet. The advisory describes the public flow build endpoint, so internet exposure and public flows are the key facts.
The free dependency scan can also flag Langflow in a requirements file.
If you cannot upgrade today, find out how the instance is exposed. Check the reverse proxy and firewall rules for the Langflow port, and see whether the API is reachable without a login from outside your network. IBM lists no workaround, so network isolation is a stopgap and not a fix.
Also review the secrets the instance holds. Langflow flows commonly hold keys for model providers and data stores, so an exposed instance puts those at risk.
What to do now
- List every Langflow instance, including test and demo ones.
- Upgrade each to 1.10.2 or later.
- Until upgraded, take the instance off the public internet or put it behind authentication at the proxy.
- Review which flows are public and unpublish any that do not need to be.
- Rotate API keys and secrets stored in Langflow if the instance was exposed.
- Keep an inventory of AI workflow tools like Langflow with version and exposure, since they are often installed by individual teams.
Why it matters
A denylist lists what is forbidden and allows everything else. Each time a new component appears, the list needs an edit, and one missed entry is enough. The record classes this as an incomplete list of disallowed inputs. An allowlist of components known to be safe would not have this failure.
The record describes the issue as unauthenticated remote code execution, yet the vector scores attack complexity as high, which keeps the number at 8.1. Do not read that as low risk for an exposed instance. The record does not flag this CVE as known exploited.
For builders of similar tools, the takeaway is to allow only components known to be safe in a public context, instead of blocking components known to be dangerous. A denylist needs an edit for every new component, and one gap is enough.
The record lists this weakness class: CWE-184 (Incomplete List of Disallowed Inputs).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a workaround?
IBM states there are none. Upgrade to 1.10.2.
Why does it matter if a flow is public?
The weakness sits in the public flow build endpoint, so an instance with no public flows and no internet exposure has less to defend.
Why is the vector complexity high if it is unauthenticated?
The vector in the record rates attack complexity as high, which lowers the score to 8.1. The description still calls it unauthenticated remote code execution, so rely on the description for risk planning.
Sources
Last reviewed: 19 October 2026.
