langflow vulnerabilities: Two Critical 9.8s and One Fix

If you run Langflow to build AI agents or workflows, the langflow vulnerabilities published in IBM's latest security bulletin need your attention this week. The bulletin, first published on October 28, 2026 and updated the next day, lists four flaws in Langflow OSS versions 1.0.0 through 1.12.8: two rated 9.8 Critical, one of them an unauthenticated remote code execution reachable through the Model Context Protocol, and one an authentication bypass tied to Langflow's auto-login control. The only fix IBM offers is an upgrade to Langflow 1.13.0, and it explicitly lists no workaround. This post walks through what each flaw does, what is and is not known about exploitation, and the exact upgrade path, with the caveats that matter before you schedule the work. Source

What IBM's bulletin lists

The headline pair is the two 9.8 Critical flaws, both scored by IBM. CVE-2026-93680 lets a remote attacker bypass security restrictions because of improper authentication (CWE-287), with no account required. IBM describes it as an incomplete remediation of an auto-login security control. CVE-2026-110186 also needs no account and allows arbitrary code execution due to improper control of code generation (CWE-94); IBM says it is exploitable through model context protocol tool enumeration, which matters because Langflow can offer its flows as tools to AI apps over MCP. Source

The other two flaws need an account. CVE-2026-110193 is rated 8.8 High: a remote attacker with a low-privileged authenticated account can cause the Agentic Assistant to generate or submit component code using unblocked patterns, resulting in arbitrary operating system command execution on the server. CVE-2026-110192 is rated 6.5 Medium: a remote authenticated attacker can obtain sensitive information due to insufficiently protected credentials, which in practice means exposed API keys. The bulletin also covers known vulnerabilities in bundled open-source dependencies, including three flaws in the Hono web framework fixed in Hono 4.13.5. All four Langflow flaws affect every release from 1.0.0 through 1.12.8. Source

The auto-login problem underneath it

The context that makes the authentication bypass worse is Langflow's own default. When automatic login is enabled, Langflow logs users in as superusers without prompting them to sign in, and in version 1.12.8 the LANGFLOW_AUTO_LOGIN setting is enabled by default. Langflow's own code description warns that it bypasses authentication and should only be used in development environments, but a default is what most deployments actually run. The bulletin does not say whether servers with automatic login turned off are vulnerable to the bypass, so the safe reading is that the version range, not the setting, defines exposure. Langflow 1.13.0 turns automatic login off by default, which is why the release's breaking change matters as much as its patches. Source

What is known about exploitation

None of these four flaws is in CISA's Known Exploited Vulnerabilities catalog as of the catalog's October 30 update, though six other Langflow flaws are listed there, most recently CVE-2026-9198, added in August. Public exploit tooling does exist in a limited form: a module in the Metasploit Framework already references CVE-2026-93680. It connects to a Langflow server's MCP endpoint without credentials, starts a session, and lists the tools the server offers. It does not run code or commands. Its author lists Langflow 1.5.0 through 1.11.4 as affected, a narrower range than IBM's 1.0.0 through 1.12.8, and tested on version 1.8.4 with automatic login turned on. The honest summary is that a reconnaissance-grade public tool exists and full exploitation is publicly plausible given the CVE descriptions, but we did not find confirmed reports of in-the-wild exploitation. Source

This is part of a larger patch wave

These four are not the whole story. On October 29, IBM also published CVE records for 29 other Langflow flaws and named versions 1.12.4 and 1.12.5 as their fixes. One of them, CVE-2026-104339, is another unauthenticated arbitrary code execution flaw that IBM rates 9.8. None of the 33 records, the four in the new bulletin included, lists 1.13.0 as affected. Teams that patched to 1.12.4 or 1.12.5 for the earlier wave are still exposed to the new criticals and need to move again, this time to 1.13.0. Source

How to check your exposure quickly

Start with the version string, because IBM defines the affected range as every release from 1.0.0 through 1.12.8 with no carve-outs for configuration. If pip show langflow or your Docker image tag says anything in that range, the four flaws apply and the upgrade is the only remediation IBM offers. Then check reachability: an unauthenticated attacker needs network access to the server, and for CVE-2026-110186 specifically to its MCP endpoint, so a Langflow instance bound to localhost or behind a private network is a different risk from one with a public URL. Finally, check whether LANGFLOW_AUTO_LOGIN is set in your environment files, since 1.12.8 enables it by default and the setting logs users in as superusers without a sign-in prompt. Source

How to upgrade to 1.13.0 safely

Langflow 1.13.0 was released on October 22, 2026. Alongside the security fixes it adds audit logging (an append-only record of who changed which flow or project, enabled with LANGFLOW_AUDIT_ENABLED=true), reusable connections for Google Workspace, Microsoft 365, and Slack accounts, and concurrent editing protection so one user's save cannot silently replace another's. The breaking change is the one to plan around: official packages and Docker images now set LANGFLOW_AUTO_LOGIN to false, so you must set a superuser password before starting 1.13 or you may not be able to sign in. Source

The upgrade sequence from the vendor guidance: back up the database, the secret key, and uploaded files first. If the deployment uses automatic login, prepare the existing account for password sign-in before upgrading, as Langflow's installation instructions describe. Then upgrade the Python package with pip install --upgrade "langflow==1.13.0", or for Docker move to the langflowai/langflow:1.13.0 image while preserving the deployment's persistent data. If you cannot sign in after upgrading, follow Langflow's documented recovery steps, and do not delete or reinstall Langflow to get access back, because the documentation warns this can permanently remove your flows. IBM provides no workaround for servers that cannot upgrade, so exposed 1.12.8 instances should be taken off the public network until they can move. Source

What this means for agent builders, in our assessment

This section is our read, separate from the sources. Langflow sits in a sensitive position: it is a tool for wiring agents to tools, credentials, and MCP endpoints, so an unauthenticated RCE on the builder is a compromise of everything the agents can reach. The pattern is the same one we flagged in our DB-GPT CVE-2026-77932 post: agent frameworks ship developer-friendly defaults that become attack surface in production. Three actions follow. First, inventory every Langflow instance, including the one a data team spun up for a demo, and check its version today. Second, treat the MCP tool enumeration path as a network-exposure question: anything that can reach the MCP endpoint can list your tools without credentials on an unpatched server. Third, use the upgrade to turn on the new audit logging, because knowing who changed a flow is a control we recommend in our AI agent security checklist and our AI agent tool permissions guide for exactly this class of incident. The window between public Metasploit modules and broad exploitation is usually measured in days, so patch before the weekend. Source