Fourteen More Langflow Flaws; 1.10.3 Affected and No Fix Version Given

[Update, August 6, 2026] Fourteen more, this time in the AI integration layer itself — and 1.10.3 is affected

Between August 5 and 6, 2026, IBM disclosed fourteen further vulnerabilities in Langflow OSS. The affected range is 1.0.0 through 1.10.3 — which means 1.10.1 and 1.10.2, the versions this article has been pointing readers toward, are both still in scope.

The heaviest is CVE-2026-8182 (CVSS 8.8). The NVD text is blunt: installations "allow anyone on the internet to execute arbitrary code on the server without any credentials via 2 HTTP requests." No username, no password, two round trips.

These fourteen also share a character. They cluster in the mechanism that connects AI to external tools (MCP), and in the assistant that builds flows automatically. The features Langflow markets are the features being broken into.

CVE-2026-9196: AI-generated code ran before a human saw it

Of the fourteen, this one says the most about where the product is. Its CVSS of 8.1 is not the highest on the list, but the substance is a different kind.

Langflow includes an assistant that assembles flow components for you when you describe what you want. According to the NVD entry, that feature executed the Python code the model generated on the backend during validation — before the user reviewed and approved it.

So if an attacker can steer what the model produces, the code has already finished running by the time anyone is asked whether it looks acceptable. Outbound network calls, file system access and data exfiltration all happen with the privileges of the Langflow backend.

As handing work to AI agents becomes ordinary, the question "may we execute the model's output before a person reads it?" has now been assigned a CVE number.

Three in the AI integration layer (MCP)

MCP is the shared convention for wiring external tools and data into an AI system. Langflow supports it, and three flaws sit in how it accepts that configuration.

CVE-2026-17623 (8.8): the "command to run" field in an MCP server definition is not validated and executes as an OS command. CVE-2026-17626 (8.8): when MCP servers run via Docker, the filtering of volume-mount and device-mapping arguments is incomplete, so files on the host itself can be read and modified. CVE-2026-9077 (8.5): a localhost-only restriction can be bypassed to write MCP configuration into the IDE config files of the machine's developer.

The third is the awkward one, because its reach extends to a developer's own workstation. Whatever was written gets loaded the next time that editor starts.

Once again, nobody says where to upgrade to

This article has repeatedly covered Langflow's habit of shipping advisories with no fixed version recorded anywhere. It happened again.

The only certainty is that everything up to and including 1.10.3 is in scope. Stay on the 1.10 line and these fourteen stay with you. So the practical move is to go to the latest 1.11 release (1.11.2 as of August 6) — not because it has been confirmed fixed, but because it is outside the range anyone has written down. That distinction is worth stating plainly.

For context, CVE-2026-9198, added to CISA's actively-exploited catalog (KEV) on August 4, carries a deadline of August 7 — tomorrow. Fourteen more landed on the same product in the same week.

If upgrading is not immediately possible, the mitigations in "What to do now" below still apply. One thing helps specifically here: if you are not using MCP integration or the AI assistant, your exposure to this batch is considerably narrower. Turning off what you do not use remains the most reliable step.

[Update, August 5, 2026] CVE-2026-9198, disclosed July 17, is now under attack — deadline August 7

On August 4, 2026, CISA added Langflow's CVE-2026-9198 (CVSS 9.8) to its catalog of actively exploited vulnerabilities (KEV). U.S. federal agencies were given until August 7 — three days. It is one of the flaws IBM disclosed in the July 17 batch, which this article already covered, and at the time we wrote that it had no report of abuse and no KEV listing. That has changed, and we have rewritten the passage below accordingly.

What stands out is that the entry point is the same one as CVE-2026-0770, the subject of this article. NVD's description says an attacker chains the endpoint that mints superuser tokens for any caller with no credentials (/api/v1/auto_login) with the validation endpoint that runs whatever code it is handed (/api/v1/validate/code), and takes over a default Langflow install outright. The latter is precisely the endpoint whose behavior we checked release by release, confirming it stopped executing code in 1.10.1.

So this KEV listing ends up corroborating our own reading of the source. NVD states CVE-2026-9198 affects 1.0.0 through 1.10.0 and is fixed in 1.10.1 (analysis completed August 4). Yet for the same endpoint, CVE-2026-0770 still carries no fixed version at all — and the only remediation target KEV offers for it is 1.9.0, a release we verified still has the hole open. For flaws in the same place, the public record now says both "fixed in 1.10.1" and "go to 1.9.0" at once.

Who observed the exploitation, and when, has not been published. CISA states only that it lists entries on evidence of active exploitation, and as of this writing we found no reporting with observation details. The KEV record marks ransomware use as unknown.

The response has not changed. Moving to 1.11.1 or later puts you outside the range of both CVE-2026-9198 and CVE-2026-0770. If you cannot upgrade immediately, disable auto-login and take the instance off the open internet. If it has been exposed, review historical requests to /api/v1/auto_login and /api/v1/validate/code, look for flows or accounts you did not create and unexpected outbound traffic, and rotate any keys and API credentials stored on that host. You can follow actively exploited flaws in our CISA KEV tracker (Japanese).

The fix for the exploited flaw shipped back on June 23

For CVE-2026-0770, the Langflow flaw under active attack, the fix was already in 1.10.1, released on June 23, 2026. We established that by pulling the source of each released version and reading it. Yet that fact is recorded in no vulnerability database as the fix for CVE-2026-0770. Up to our previous update (July 29), this article followed the public record and said no fixed version had been confirmed.

Here is what happened. On June 18, 2026 the project merged a change titled "do not execute code in validate_code" (PR #13696), and it shipped as 1.10.1 on June 23. The patched code carries a comment describing this exact flaw: that a submitted function's default arguments and decorators run at definition time, so code executes during "validation" without the function ever being called. But the advisory ID cited there, GHSA-2wcq-pvw2-xh7v, has never been published — it is not among the vendor's 25 public advisories and its page cannot be reached. Nor is it mapped to any CVE.

So every public record still reads "no fix." The public GitHub advisory has an empty patched-version field and has not been touched since February 19, 2026; OSV records not a "fixed" version but only "last affected: 1.7.3"; and NVD lists no fixed version either (last modified July 22).

We fetched the code of each published release and checked, one version at a time, whether the validation endpoint executes the code it is sent. The results:

What the table exposes is that the official remediation pointer sends you to the wrong place. The only remediation target the U.S. KEV catalog of actively exploited flaws gives for CVE-2026-0770 is the 1.9.0 release page — and 1.9.0 still has this hole wide open. On a case where U.S. federal agencies were ordered to act by July 24, anyone who followed that pointer onto the 1.9 line is still exposed while believing they are done.

The sequence of dates is the awkward part. The fix went public on June 23. Exploitation was first observed on June 27, and the KEV listing came on July 21. A fixed build was out in the world four days before the attacks started — and it never reached the records that defenders rely on, so for roughly a month everyone worked on the assumption that no fix existed. The only outside source to make the connection is an analysis Resecurity published on July 29.

That said, we are not writing that 1.10.1 resolves CVE-2026-0770. Neither the vendor, nor ZDI which issued the number, nor any vulnerability database has confirmed that mapping. What we verified with our own eyes is that code execution is gone from the validation path; we cannot verify that no other route to the same flaw remains. The practical advice is unchanged: update to the latest release, and alongside that keep Langflow off the public internet, restrict who can reach it, and disable auto-login — all three together.

For reference, the estimated probability that this flaw is exploited within the next 30 days (EPSS) stood at 0.56 on August 2, in the top 1% of all tracked flaws. Given that attacks are already being observed, the number is beside the point: this one needs handling now.

[Update, August 3, 2026] Nine more flaws, with the AI-integration (MCP) surface as the new target

More vulnerabilities have piled up since our last update. Vendor IBM registered eight with NVD between July 28 and 30, and one more was published on the project's GitHub on August 1 — nine in total. What stands out is that the target is no longer the code-validation endpoint or the public-flow endpoint that drove earlier flaws: the surface under fire now is MCP, the shared mechanism for connecting AI to outside tools and data.

CVE-2026-12940 (CVSS 9.8, unauthenticated): slipping environment variables into the AI-integration launcher

This is the only one of the nine said to reach server takeover with no login. Per NVD, the routine that launches an MCP external tool as a command lets an attacker inject environment variables. Because those values steer how the program behaves, it leads straight to OS command execution (CWE-78). Affected versions run from 1.0.0 through 1.10.1, and IBM has issued a dedicated bulletin.

CVE-2026-8446 (CVSS 8.6, unauthenticated): the AI-integration endpoint waves authentication through, exposing admin files

This is the advisory the project published on August 1. With MCP integration enabled and the target project set to external authentication (OAuth), the normal login check is skipped and unauthenticated callers reach the MCP endpoint. In testing, the advisory says, listing and reading files from outside both succeeded, and file contents belonging to other users, including administrators, could be retrieved. One of the causes it names is the design covered below, where an enabled auto-login makes the server fall back to the superuser account — a risky default breeding a fresh vulnerability. Fixed in 1.11.0. Note that this number is not yet in NVD at the time of writing; it exists only on the vendor's GitHub.

The remaining seven require a login to exploit, and most are of the "reach another user's data" kind. In a Langflow shared across several people or teams, though, that means a single ordinary account can touch other people's internal documents, search data and execution history. NVD has not finished analyzing the eight, and their fixed-version fields are empty too. Since the affected range is given as up to 1.10.1, moving to at least the current 1.11.1 is the realistic response. Flaws around the MCP endpoint run back to June's CVE-2026-7664 and CVE-2026-7663 (both authorization gaps), covered later in this article.

Six Langflow flaws are now on KEV, including CVE-2026-9198

Before CVE-2026-0770, CVE-2026-55255 had already been added to KEV on July 7, 2026 (deadline July 10). It is an authorization bypass through a user-controlled key: a logged-in user can name another user's flow ID and run that flow. We cover it further down under "Four more flaws added to NVD." That July 7 batch was the one with four CVEs alongside Adobe ColdFusion (CVE-2026-48282) and two Joomla-ecosystem flaws.

Then on August 4, 2026, CVE-2026-9198 from the July 17 batch was added as well, with an August 7 deadline. That brings the count of Langflow vulnerabilities on KEV to six. Few individual products have accumulated that many.

* For CVE-2026-55255, the KEV entry points to the vendor's security advisory (GHSA-qrpv-q767-xqq2); the fix is in 1.9.1 (we previously wrote 1.9.2; the advisory text states the fix shipped in 1.9.1 and NVD's affected range ends below 1.9.1, so we have corrected it).

[Update, July 17, 2026] A dozen-plus Langflow flaws at once, most leading to takeover (CVE-2026-8505, 8476 and more)

On July 17, 2026, vendor IBM disclosed more than a dozen vulnerabilities in Langflow at once. Most either take over the server (RCE) or bypass authentication, and they affect roughly 1.10.0 and earlier (a few up to 1.10.1). The fixed version differs per CVE: some were closed in 1.10.1, others needed 1.10.2 (see the table below). The safe way to avoid mixing them up is to go straight to the latest release, 1.11.1 (July 28, 2026). If you cannot upgrade immediately, of the workarounds below, disabling auto-login and removing direct internet exposure are the most effective. Because there are so many, we first explain the ones exploitable with no login (i.e. the most dangerous) and the highest-scoring CVSS 9.9 individually, and list the ones that require a login in a table further down.

CVE-2026-8505 (CVSS 9.8, unauthenticated): webhook auth off by default lets flow execution lead to takeover

Langflow's external integration (webhooks) had no authentication by default in 1.9.x and earlier. In that state, an attacker who merely knows a flow's UUID (identifier) can execute that flow with no login. Depending on the flow's contents, that can lead to code execution (RCE) on the server, making it one of the more concerning unauthenticated flaws added this time. It is rated 9.8.

That default was fixed in 1.10.0. Checking Langflow's authentication settings source tag by tag, the setting that requires API-key auth on webhooks (WEBHOOK_AUTH_ENABLE) is False in 1.9.0 and True from 1.10.0 on, "for secure-by-default behavior." If you are still on 1.9.x or earlier, either upgrade or turn the setting on explicitly.

CVE-2026-9103 (CVSS 9.8, unauthenticated): auto-login hands out an admin-level ticket with no authentication

When auto-login is enabled by default, the authentication endpoint (/api/v1/login/auto_login) issues long-lived, admin-level (superuser) tokens to callers with no credentials. Combined with permissive CORS settings that loosely allow reads from other sites, that token may even be exposed to unintended origins. The upshot: an unauthenticated external attacker can seize full administrative access, which is why it rates 9.8.

Unlike webhooks, auto-login (AUTO_LOGIN) still defaults to True in 1.11.1. The source carries only a warning — "this bypasses authentication and should only be used in development environments," and "this will default to False in v2.0" — while the default itself is unchanged. Upgrading does not move you to the safe side here, so disabling auto-login remains a required step. There is one exception: the official Docker images pin LANGFLOW_AUTO_LOGIN=false at the image layer. The exposure is when you install directly with pip and the like, where it starts up enabled. CVE-2026-8446, published on August 1, names that same auto-login superuser fallback as one of its causes.

CVE-2026-9198 (CVSS 9.8, unauthenticated): chaining auto-login and code validation into unauthenticated RCE

The attacker first grabs a legitimate admin-level token from the endpoint that hands out tickets with no authentication (/api/v1/auto_login). They then hit the code-validation endpoint (/api/v1/validate/code), which runs submitted code directly through Python's exec(), to execute arbitrary commands. Chaining just those two lets an attacker fully take over a default Langflow install with no authentication, which is why it rates 9.8. IBM's advisory points to updating to the latest version.

CVE-2026-9202 (CVSS 9.8, unauthenticated): unauthenticated, unlimited account creation leading straight to takeover

When Langflow's setting that activates new users immediately (NEW_USER_IS_ACTIVE=true) is enabled, an attacker can create any number of user accounts with no login and reach the code-execution endpoints immediately after. This, too, becomes a foothold for taking over the server past the authentication wall.

CVE-2026-13446 (CVSS 9.8, unauthenticated): credentials for auth and encryption were hard-coded

Langflow had the keys used for login authentication and data encryption hard-coded — the same value baked into the program for everyone. Because the key is shared across all users, an attacker who knows it can forge authentication with no login or decrypt encrypted data. It affects up to 1.10.1, so upgrading only to 1.10.1 leaves it open — you need 1.10.2 or later.

CVE-2026-8476 (CVSS 9.9, login required): loading disk cache without validation yields code execution

This is the highest-scoring in the batch (CVSS 9.9). When Langflow reloads cache it saved to disk, it restored the contents without validation using Python's pickle.loads(). Feeding in a crafted cache runs arbitrary code. Exploitation requires a logged-in account, but the impact when it succeeds is severe.

CVE-2026-9135 (CVSS 9.9, login required): a component's code field runs Python on the backend

Exploiting it requires a logged-in account that can create flows, but in Langflow's "ToolGuard" safeguard component a dynamically specified code field was insufficiently validated, so an attacker can bypass the restrictions on custom components and run arbitrary Python code on the backend. Via the MCP (AI tool-integration) update tool, it can even reach other users' (tenants') flows.

Besides these, the same July 17 disclosure includes many flaws that require a login (such as flow-creation privileges) to exploit. That precondition makes them less pressing than the unauthenticated ones, but several still lead to takeover once an attacker has one legitimate account.

The fixes split across 1.10.1 and 1.10.2

The easiest thing to get wrong about the July 17 batch is that the fixes do not land in one release. IBM's advisories show some closed in 1.10.1, and others whose affected range extends through 1.10.1 and therefore required 1.10.2. Upgrading to 1.10.1 does not clear the batch.

CVE-2026-13446, described above, also runs through 1.10.1 and likewise needs 1.10.2 or later. If tracking versions per CVE is not worth the effort, going to 1.11.1 puts you past the entire July 17 batch. One more note: every one of these IBM advisories carries a change history of a single line, "Initial Publication" — none of them was revised after July 21.

All of these belong to the same family Langflow has been hit by repeatedly: an authentication gap combined with server-side code execution (see also "Langflow has been hit through the same hole again and again," later in this article). Because the product is widely pulled in as an open-source component, its blast radius is hard to gauge; we cover how to find such risks in our guide to risks hidden in open-source components. One of them, CVE-2026-9198, was added to the U.S. CISA catalog of actively exploited vulnerabilities (KEV) on August 4, 2026, confirming it is being used in real attacks (deadline August 7 — see the update at the top). The rest of the batch has no report of abuse and no KEV listing as of this writing. Langflow has seen attacks appear right after disclosure before, so you should update quickly. You can check whether attacks have begun in our tracker of actively exploited vulnerabilities (Japanese).

Langflow, a popular tool that lets you build AI agents and chatbots by dragging and connecting visual blocks instead of writing much code, keeps getting hit with serious vulnerabilities. On July 17, 2026, more than a dozen flaws were added (CVE-2026-8505, 8476 and more, covered at the top of this article). Shortly before that, IBM disclosed a set of 8 flaws together on June 30, 2026. Among those, the most dangerous is a CVSS 10.0 code execution that needs no login and no user interaction to take over the server over the network (CVE-2026-10134). Alongside it are two more flaws that run programs on the server without authentication (CVE-2026-7803 and CVE-2026-7871, both CVSS 9.8), and one that leaks all stored credentials at once (CVE-2026-7874).

These follow a wave of flaws disclosed in June 2026 (CVE-2026-10561 and others, covered later in this article). Because Langflow is designed to run user code on the server, an authentication gap maps directly to a full takeover, and real-world attacks have been observed right after disclosure. From here on we walk through the eight disclosed on June 30 and the June wave that preceded them, newest first. Scope varies by flaw, but the eight disclosed on June 30 affect up to 1.10.0 and are resolved by 1.10.1 or later (parts of the July 17 batch need 1.10.2, and CVE-2026-0770 has no fix at all — see the top of this article). If you can't upgrade right away, the stopgaps in "What you should do now" below apply directly.

* The table above summarizes CVE-2026-10561, a representative flaw from the June wave. Start with the "8 new flaws disclosed in July" below.

The 8 flaws disclosed on June 30, 2026 (CVE-2026-10134 and others)

On June 30, 2026, IBM disclosed 8 new Langflow vulnerabilities. Sorted by severity, the ones to watch most are the 5 "unauthenticated knockouts" that let an attacker take over the server, or steal stored data wholesale, with no login and no user interaction. The remaining 3 require a logged-in user, but they cannot be ignored in multi-tenant, shared deployments. Here is the full list, followed by notes on the key ones.

CVE-2026-10134 (CVSS 10.0): unauthenticated code execution via a public flow's Python block

The most severe of the eight, rated the maximum. According to the NVD writeup, a block placeable in a flow ("PythonCodeStructuredTool") runs Python the attacker supplies on the server. Once a legitimate user marks a flow "PUBLIC," that code execution becomes reachable through an unauthenticated endpoint (/api/v1/build_public_tmp), so anyone who knows the flow's ID can read secrets on the server, read and modify stored data, reach internal services, and establish persistence. It is classified as code injection (CWE-94). This is the same "public flow + Python execution" lineage as June's CVE-2026-10561 and CVE-2026-33017 — the very weakness Langflow has been hit on repeatedly. Affected up to 1.9.3.

CVE-2026-7803 / CVE-2026-7871 (both CVSS 9.8): unauthenticated code execution

CVE-2026-7803 stems from weak validation of flow nodes whose type field is empty or missing, allowing arbitrary code execution without authentication (improper input validation, CWE-20). CVE-2026-7871 lets anyone who can reach Langflow's internal data store "Redis" exploit unsafe deserialization (CWE-502) to run code with the application's full privileges. Not exposing Redis to outside access is an effective defense against it. Both affect versions up to 1.10.0.

CVE-2026-7874 (CVSS 9.1): all stored credentials leak at once

CVE-2026-7874 used a weak, reversible key-derivation scheme for encryption at rest (weak PRNG, CWE-338), so all credentials (API keys and access tokens) stored in Langflow can be decrypted and disclosed. If the keys for connected AI models or external services leak, that leads straight to fraudulent use and billing abuse. Even after updating, it's safest to revoke and reissue any stored API keys and tokens. Relatedly, CVE-2026-7663 (CVSS 9.1) is an authorization gap on the "MCP" endpoint (which connects external tools to AI), letting an unauthenticated party access protected MCP resources and operations (improper authorization, CWE-285).

Three flaws that require a login (CVE-2026-7873 and others)

The remaining three need a login to exploit. CVE-2026-7873 (CVSS 9.9) lets a logged-in attacker hit the code-validation endpoint to run OS commands, leading to credential theft and lateral movement. CVE-2026-10140 (CVSS 9.6) is flawed cache management in voice mode that mixes up requests between tenants, so processing runs under someone else's API keys and billing gets confused. CVE-2026-10129 (CVSS 8.5) bypasses SSRF protection (an attack that uses the server as a stepping stone to reach internal resources). In shared, multi-user Langflow deployments, all three can spread impact from an ordinary account.

The response is the same for all: updating to 1.10.1 or later resolves these eight together. Per-flaw details and fixed versions are in the Langflow releases and the respective IBM security bulletins. If you can't upgrade right away, the exposure cut-off and access restrictions in "What you should do now" below apply directly.

Who is at risk, and what is the damage

This is not an attacker who picks a specific target. It is an attacker who uses automated tools to constantly scan the internet for exposed Langflow servers. The most dangerous setup is a quick test environment, spun up during the AI rush, that ends up reachable from the outside and then forgotten.

Against a server they find, the attacker skips the login entirely and runs commands and programs of their choice on that server. No ID, no password, and no careless click from a user is needed. Simply sending crafted data to the exposed endpoint makes the server obey.

The aftermath is severe and comes in two stages. Langflow often stores API keys and access tokens for the AI models and external services it connects to, and these are stolen at once. End users may have personal data or conversations exposed; the operating company faces fraudulent charges using the stolen keys, destruction of stored data, and the server being used as a stepping stone into other internal systems. That is why the update and exposure review below are urgent.

This is not hypothetical. Earlier Langflow flaws of the same kind were abused by a self-spreading botnet called "Flodrix" and by the Iran-linked group "MuddyWater," and have repeatedly appeared on the U.S. Known Exploited Vulnerabilities (CISA KEV) catalog. CVE-2026-10561 is the latest in that same lineage.

What Langflow actually is

Langflow lets you assemble AI agents and document-grounded answering systems (known as RAG) by dragging blocks on a canvas and connecting them with lines. Because even people who do not write code can build AI pipelines, it spread quickly. Its public GitHub repository has nearly 150,000 stars, making it one of the most active open-source AI tools. It is now developed under IBM.

Behind the convenience is a structural weakness. Some of the blocks let users write and run their own Python (a programming language widely used in AI development), and that code runs directly on the Langflow server. In other words, "run a program on the server" is a built-in capability by design. The moment the front-door lock comes off, that capability becomes the takeover tool. The developers are aware of the risk; they are discussing fundamental fixes such as running user code inside hardware-isolated virtual machines.

What is happening, technically

According to vulnerability database records, CVE-2026-10561 combines a "builtins injection" in the Python execution block (PythonREPLComponent), which reaches internal functions it should not be able to touch, with an "authentication bypass" that slips past the login check. It is classified as CWE-94, "Improper Control of Generation of Code (Code Injection)."

The root cause is consistent: Langflow runs user-written Python directly in the server process with no sandbox. Endpoints exposed to the outside should always require a login, but when an authentication check is missing on some path, an attacker only needs to send crafted data to that endpoint to execute code on the server. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — over the network, low complexity, no privileges or user interaction, and impact that spreads beyond the component itself: every worst-case factor is present.

For reference, a separate Langflow flaw disclosed in March 2026 (CVE-2026-33017) was analyzed as a path where code sent to an unauthenticated "public flow build" endpoint reaches an unprotected exec() during graph construction. The endpoint and block differ, but the route — bypass the login, arrive at Python execution — is the same.

A second critical flaw disclosed the same day (CVE-2026-7664)

On the same June 22, 2026, IBM disclosed a second critical Langflow flaw (CVE-2026-7664, CVSS 9.8). This one is an authorization gap — the check of who is allowed to do what — on the "MCP" endpoint. MCP (Model Context Protocol) is a common standard for safely connecting AI agents to external tools and data, and Langflow supports it.

Through this flaw, an unauthenticated third party can access protected MCP project resources and execute MCP operations that should require a login. It is classified as CWE-287, "Improper Authentication." Unlike the arbitrary code execution of CVE-2026-10561 it is a different class of bug, but having a workflow's internal data and connections reachable without authentication is serious in its own right. It affects versions 1.0.0–1.8.4 and is fixed in 1.9.1 and later.

In other words, June 22 brought two critical Langflow flaws at once — one around code execution (CVE-2026-10561) and one around authentication/authorization (CVE-2026-7664). The good news: the update to 1.9.4 described below closes both at the same time.

Four more flaws added to NVD (CVE-2026-48519 and others)

On June 24, 2026, four more critical Langflow vulnerabilities were added to the vulnerability database (NVD). All are in the 9-point CVSS range, and every one affects versions before 1.9.4. In other words, updating to 1.9.4 or later, as this article recommends, resolves these four together with CVE-2026-10561 and CVE-2026-7664. Among them, CVE-2026-48519 is the same "unauthenticated remote code execution (RCE)" we have been discussing, and a proof-of-concept (PoC) is already public.

CVE-2026-48519 (CVSS 9.6): unauthenticated code execution on the server

The "Shareable Playground (public flows)" endpoint /api/v1/build_public_tmp processes attacker-supplied flow data without authentication (the vendor's security advisory). If even one public flow exists and its ID (UUID) can be learned from a shared link, a third party can run arbitrary code on the server. It is the same "public-flow build" lineage as CVE-2026-33017 — the very weak spot Langflow has been hit at repeatedly. Fixed in 1.9.2.

CVE-2026-55255 (CVSS 9.9): hijack and run another user's AI flow

A logged-in user can specify another user's flow ID — which they should not be able to touch — and run that flow (a privilege hijack, IDOR, CWE-639). The endpoint is /api/v1/responses. In multi-user Langflow setups, a regular account reaching into others' processes and connections is the danger. Fixed in 1.9.1. CISA added this flaw to KEV on July 7, 2026, confirming it is used in real attacks (deadline July 10).

CVE-2026-55447 (CVSS 9.6): read server files via an ingested file

By crafting a file to be ingested into a document-reading setup (RAG), an attacker can make the node read arbitrary files on the server by absolute path (symlink following, CWE-61/200). Components that read files (the BaseFileComponent family) are broadly affected. Fixed in 1.9.2.

CVE-2026-55450 (CVSS 9.3): unauthenticated unlimited upload causes outage

Files can be uploaded without authentication and without limit (missing authentication / resource exhaustion, CWE-306/400). It can be used to exhaust server storage and stop the service, or to leak storage path information. Not a takeover itself, but serious for availability. Fixed in 1.9.1.

The response is the same for all of them: updating to 1.9.4 or later closes all four. If you cannot upgrade immediately, the interim steps (cut off external exposure, restrict access) in the "What to do now" section below apply unchanged.

Langflow has been targeted again and again

The frightening part is that this is not the first time. Critical RCE flaws in Langflow have surfaced repeatedly over the past year or so, and several were exploited in the wild shortly after disclosure. In 2025, an initial unauthenticated RCE (CVE-2025-3248) made it onto CISA's KEV catalog. In March 2026, a flaw in the public-flow endpoint (CVE-2026-33017) was exploited within about 20 hours of disclosure. Around May–June 2026, CVE-2025-34291 (CVSS 9.4) was added to KEV after reported abuse by MuddyWater, with U.S. federal agencies told to remediate by June 4. July 2026 added two more KEV entries — CVE-2026-55255 on July 7 and CVE-2026-0770 on July 21 — and August 4 added CVE-2026-9198, bringing the Langflow total to six.

Two entries belong in that history that no public record carries. On June 18, 2026 the project merged the change that stops the validation endpoint from executing code, and shipped it in 1.10.1 on June 23 — four days before exploitation of CVE-2026-0770 began, and a month before the KEV listing. Because the advisory ID it cites was never published and no CVE was attached, none of the databases registered it. Then, between July 28 and August 1, nine more flaws arrived, with the MCP integration surface as the new focus.

The pattern shows Langflow is not a one-time target but a recurring one that attackers go after right after disclosure. Each new flaw drew attacks within hours to a day. As of this writing we cannot confirm that CVE-2026-10561 itself has been exploited, but given that track record, the window to respond should be assumed to be short. We also track major vulnerabilities across IBM products, including Langflow, in our IBM vulnerability roundup.

Confirmed vs. still unknown

What to do now

The top priority is to update Langflow to the latest release, 1.11.1 (July 28, 2026; also the latest on PyPI). The June flaws alone need 1.9.4 or later, and covering the July 17 batch needs 1.10.2 or later — going to the newest release beats counting versions. Note that 1.11.2 only reached the tag stage on July 31 — there is no release and nothing on PyPI yet (the newest thing published is the 1.11.2rc2 test build), so 1.11.1 is what to install as of this writing. If you run anything from 1.0.0 to 1.9.3, treat it as affected without exception, whether it is a test or internal instance.

Two things the update will not do for you. One is CVE-2026-0770: we confirmed the fix code itself is in 1.10.1, but neither the vendor nor the bodies that issue the numbers say so, which means an upgrade cannot be treated as having closed it (see the top of this article). The other is auto-login (AUTO_LOGIN), which is still enabled by default in 1.11.1. For production, set AUTO_LOGIN=false explicitly and configure your own superuser password. If you are still on 1.9.x or earlier, webhook authentication (WEBHOOK_AUTH_ENABLE) is also off by default and needs to be enabled — it defaults to on from 1.10.0. The settings are documented in Langflow's authentication docs.

If you cannot update right away, the practical stopgap is to cut off outside access. Langflow was never designed to be exposed directly to the open internet. Keep it behind your internal network or a VPN, restrict source IP addresses, or place an authentication layer in front of it (such as a reverse proxy) — any of these closes the attack surface. If you were already running it exposed, do not rely on the update alone: revoke and reissue any stored API keys and access tokens, and check for traces of suspicious processes or traffic.

You can find whether any of your Langflow servers are exposed to the internet with asset inventory tools or network scans. Test environments multiplied by the AI rush are often left open and unmanaged, so the starting point is simply knowing where your Langflow runs and how exposed it is.

Summary

Serious vulnerabilities in the popular AI development tool Langflow keep coming. Most recently, fourteen more arrived between August 5 and 6, 2026, affecting 1.0.0 through 1.10.3 — a range that still includes 1.10.1 and 1.10.2, the versions readers have been pointed toward. The heaviest, CVE-2026-8182, lets anyone execute code on the server with no credentials and two HTTP requests. The batch clusters in MCP integration and the AI assistant; CVE-2026-9196 in particular ran AI-generated code before the user approved it. The day before, on August 4, CISA added CVE-2026-9198 — disclosed only on July 17 — to its KEV catalog with an August 7 deadline; NVD puts its fix in 1.10.1. Together with CVE-2026-0770 (July 21) and CVE-2026-55255 (July 7), that makes six Langflow flaws on KEV. Nine more landed between July 28 and August 1, of which CVE-2026-12940 and CVE-2026-8446 need no login at all. For CVE-2026-0770 we confirmed from the source of each release that the fix code was already in 1.10.1, released June 23 — yet the public record still says "no fixed version," and the 1.9.0 that KEV points to remains vulnerable. On July 17, IBM disclosed more than a dozen at once, and their fixes split across the 1.10.1 and 1.10.2 lines. The eight from June 30 (worst: CVSS 10.0 CVE-2026-10134) are closed in 1.10.1 or later, and June 22's CVE-2026-10561 and its siblings in 1.9.4 or later — so going to the latest release is more reliable than counting versions (1.11.2 as of August 6, 2026). For the fourteen from August 5–6, no fixed version is recorded in NVD, GitHub or OSV. All that can be said is that 1.10.3 and below are affected; moving to the 1.11 line is not a confirmed fix but a way out of the range anyone has written down. That said, CVE-2026-0770 has no fix, and the auto-login default has not been changed, so the update has to be paired with an exposure review and configuration changes. Because Langflow is designed to run user code on the server, an authentication gap maps directly to a full takeover, and flaws of the same kind have been targeted right after disclosure before.

In AI app development, handy tools spun up quickly tend to sit exposed on the internet and get forgotten. Use this as a prompt to review updates, exposure scope, and — above all — where your instances are actually running.

References

• ・NVD — CVE-2026-10134 (July, CVSS 10.0, unauthenticated code execution)
• ・NVD — CVE-2026-7803 (CVSS 9.8, unauthenticated code execution)
• ・NVD — CVE-2026-7871 (CVSS 9.8, code execution via Redis)
• ・NVD — CVE-2026-7874 (CVSS 9.1, stored-credential disclosure)
• ・NVD — CVE-2026-7663 (CVSS 9.1, MCP authorization gap)
• ・NVD — CVE-2026-7873 (CVSS 9.9, authenticated OS command execution)
• ・NVD — CVE-2026-10140 (CVSS 9.6, cross-tenant cache mix-up)
• ・NVD — CVE-2026-10129 (CVSS 8.5, SSRF protection bypass)
• ・IBM Security Bulletins (Langflow, July disclosures)
• ・CISA — Known Exploited Vulnerabilities Catalog (checked at version 2026.07.27)
• ・NVD — CVE-2026-0770 (unauthenticated RCE as root) / ZDI-26-036
• ・GitHub Security Advisory — CVE-2026-55255 (GHSA-qrpv-q767-xqq2)
• ・Langflow — auth settings source (AUTO_LOGIN and WEBHOOK_AUTH_ENABLE defaults)
• ・Langflow 1.11.1 release (July 28, 2026, latest) / all releases
• ・NVD — CVE-2026-10561
• ・IBM Security Bulletin (CVE-2026-10561)
• ・NVD — CVE-2026-7664 / IBM Security Bulletin (CVE-2026-7664)
• ・CIRCL Vulnerability-Lookup — CVE-2026-10561
• ・GitHub Security Advisory — CVE-2026-48519 (unauthenticated RCE via public-flow endpoint)
• ・NVD — CVE-2026-55255 (flow hijack / IDOR, CVSS 9.9)
• ・NVD — CVE-2026-55447 (arbitrary file read, CVSS 9.6)
• ・NVD — CVE-2026-55450 (unauthenticated unlimited upload, CVSS 9.3)
• ・Langflow official site / GitHub repository
• ・Sysdig — How CVE-2026-33017 was exploited in 20 hours
• ・SecurityWeek — Langflow flaw exploited hours after disclosure
• ・The Hacker News — CISA adds Langflow to KEV
• ・runZero — Finding affected Langflow assets
• ・Langflow PR #13696 — fix(security): do not execute code in validate_code (merged June 18, 2026; shipped in 1.10.1)
• ・GitHub Security Advisory — GHSA-g22f-v6f7-2hrh (CVE-2026-0770; patched-version field still empty) / OSV
• ・Resecurity — analysis of the validate_code endpoint exploitation (July 29, 2026)
• ・NVD — CVE-2026-12940 (CVSS 9.8; unauthenticated RCE via environment-variable injection in the MCP launcher)
• ・Langflow security advisory — CVE-2026-8446 (MCP endpoint auth bypass; fixed in 1.11.0)
• ・IBM Security Bulletin — CVE-2026-12940
• ・FIRST EPSS — exploitation probability estimates
• ・CISA KEV dashboard (Japanese, this site)