Langflow is designed to make building AI agents easier. Developers can connect language models, external APIs, databases, retrieval systems, and Model Context Protocol (MCP) tools through visual workflows. That flexibility becomes a security problem when a configuration intended to launch an MCP tool can also launch arbitrary operating-system commands.
CVE-2026-105740 is a critical remote code execution vulnerability in Langflow’s MCP Stdio integration, carrying a CVSS v3.1 score of 9.9. The vulnerability allows an authenticated user to supply commands through MCP server configuration and have them executed by the Langflow backend. The affected functionality does not require the attacker to obtain administrator privileges, and execution can occur during an ordinary MCP server listing operation.
The issue was published in the National Vulnerability Database on October 5, 2026, following the publication of the original GitHub security advisory in September. The recorded weakness is CWE-78, OS command injection. Langflow versions earlier than 1.9.0 are affected by the specifically documented configuration vulnerability, although a related execution-path vulnerability remained in subsequent releases and required additional fixes in 1.10.3. These details are confirmed by the NVD vulnerability record and Langflow’s original security advisory.
For organizations operating Langflow as part of an AI application platform, the significance extends beyond one vulnerable endpoint. Langflow instances may have access to model-provider credentials, internal databases, vector stores, cloud APIs, and private application networks. A remote code execution vulnerability in the orchestration layer can therefore become an entry point into the infrastructure supporting multiple AI applications.
CVE-2026-105740 Vulnerability Overview
CVE-2026-105740 affects how Langflow processes user-controlled MCP server configurations when the Stdio transport is selected. The vulnerable implementation accepts command and environment settings from a user who can manage MCP connections, stores those settings, and uses them to start a subprocess on the server.
Unlike a conventional authentication bypass, the original vulnerability does not necessarily give an anonymous user access to Langflow. It gives an already authenticated user substantially more execution authority than a conventional MCP configuration operation should provide. Where authentication is disabled, automatically bypassed, or improperly configured, the practical exposure can become much greater.
| Attribute | Details |
|---|---|
| CVE ID | CVE-2026-105740 |
| Product | Langflow |
| Vulnerability type | OS Command Injection / Remote Code Execution |
| Severity | Critical |
| CVSS v3.1 | 9.9 |
| CWE | CWE-78 |
| Attack vector | Network |
| Attack complexity | Low |
| Privileges required | Low |
| User interaction | None |
| Affected versions | Langflow versions earlier than 1.9.0 |
| Original fix | Langflow 1.9.0 |
| Related vulnerability | CVE-2026-105697 |
| More comprehensive MCP execution fix | Langflow 1.10.3 |
| NVD publication | October 5, 2026 |
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. It describes a remotely reachable issue with low exploitation complexity, low required privileges, no victim interaction, and potentially severe consequences for confidentiality, integrity, and availability. The 9.9 score comes from the GitHub CNA assessment; NVD had not independently assigned its own score in the record reviewed for this article.
The important operational detail is that the vulnerability crosses a trust boundary between an application configuration and a privileged process-launch operation. Users who should be configuring connections can potentially influence what the backend operating system executes.
Why Langflow MCP Stdio Creates a High-Risk Execution Boundary
To understand CVE-2026-105740, it is necessary to distinguish the role of MCP from the operating-system execution mechanism used to start MCP servers.
The Model Context Protocol provides a standardized interface through which AI applications can discover and use external tools. An AI agent might connect to a document retrieval service, a development tool, a database interface, or a local application that exposes capabilities through MCP. Instead of maintaining a custom integration for every external tool, an application can communicate with compatible MCP servers through a common protocol.
MCP supports several transport arrangements. In remote transports, an application communicates with a separately running service over a network connection. In a Stdio configuration, the client starts a local subprocess and communicates with that process through standard input and standard output.
That distinction has major security implications.
A Stdio MCP connection is not merely a reference to a remote service. It can involve instructing the host machine to launch executable code. When a platform allows users to configure Stdio servers, it must decide which executable can run, what arguments it can receive, what environment variables can be supplied, and which operating-system privileges the process should inherit.
Langflow supports MCP in both client and server roles, as described in its official MCP documentation. CVE-2026-105740 concerns the client-side functionality that launches configured Stdio MCP servers, rather than a flaw in MCP’s wire protocol itself.
In the vulnerable implementation, an MCP server configuration could contain a command selected by the user. Instead of treating that command as a privileged operation requiring strict authorization and validation, Langflow could pass it into a shell-execution path.
The result was a confused security boundary: configuration privileges became operating-system execution privileges.
This is particularly concerning in AI infrastructure because the execution environment is often connected to sensitive systems. Langflow is not simply a chatbot frontend. It is an orchestration environment that may execute tools, handle credentials, retrieve internal documents, and coordinate actions across services.
Root Cause of CVE-2026-105740: Unvalidated Commands Reach Bash
The core vulnerability lies in the treatment of user-supplied command data.
In the affected implementation, Langflow exposed an MCP configuration API that accepted fields such as command, args, and env. The application then used those values when establishing a connection to an MCP server.
The relevant configuration endpoint was:
POST /api/v2/mcp/servers/{server_name}
The endpoint was accessible to authenticated users without restricting the operation to administrators. The original security advisory identified insufficient validation of the command and environment settings supplied through this API.
At a lower level, the vulnerable MCP connection code used a shell to execute a constructed command. The essential execution pattern can be represented by the following simplified example:
server_params = StdioServerParameters( command="bash", args=[ "-c", f"exec {command_str}" ], env=env_data,)This excerpt illustrates the relevant shell-execution mechanism and intentionally omits unrelated implementation details.
The dangerous operation is the insertion of command_str into an argument interpreted by bash -c.
When the shell receives a string through -c, the string is parsed as shell syntax. If untrusted data can control that string without effective restrictions, the shell can interpret it as an instruction to execute an operating-system command.
This creates a direct path from a user-controlled application field to server-side command execution.
The vulnerability also involved insufficient restrictions on the supplied executable arguments and subprocess environment. Consequently, the security problem was broader than a single missing character filter.
The original GHSA-7w94-79vh-5mr2 advisory documents the affected endpoint, command construction, execution sink, and environment-handling behavior.
Why shell execution is fundamentally different from safe process launching
Applications frequently need to start subprocesses. The dangerous part is not the existence of subprocess execution itself; it is allowing untrusted input to determine what the operating system should execute.
A restricted implementation might select an approved executable internally and provide independently validated arguments. In contrast, a vulnerable implementation can let user input determine both the executable and its behavior.
A shell introduces another layer of interpretation. Characters, command separators, variable expansion, redirection, and other shell features may change the meaning of an input string. Filtering a few suspicious characters is therefore not equivalent to creating a safe execution boundary.
Even direct process execution without a shell is not automatically secure if the caller can select an arbitrary executable or supply unrestricted arguments. An interpreter, package runner, or container runtime may itself provide powerful execution capabilities.
For this reason, the durable solution requires both carefully constrained process-launch inputs and validation at the actual point where the process is created.
That distinction explains why the later Langflow security fix was important: the remediation needed to enforce the execution policy consistently rather than relying only on an API request validator.
How CVE-2026-105740 Can Be Triggered Without Running a Flow
One of the most distinctive properties of CVE-2026-105740 is its execution trigger.
An observer might assume that an attacker-controlled MCP command would execute only when a particular AI workflow or agent actively invokes the MCP tool. The original advisory describes a different and more dangerous behavior.
Langflow could start a configured Stdio server while fetching the MCP server list with action counting enabled.
The relevant request takes the form:
GET /api/v2/mcp/servers?action_count=true
Authorization: Bearer <authorized-token>When the backend tries to determine the capabilities of a configured MCP server, it may attempt to establish a connection. Establishing a Stdio connection involves launching the configured process.
This means that a stored command can execute when the MCP settings interface is opened or the server list is refreshed. No separate flow execution by the administrator is necessarily required.
An attacker who can store a malicious configuration may therefore create a delayed execution condition. The payload can remain in the configuration until another operation causes Langflow to initialize the MCP connection.
This behavior changes the defender’s understanding of the attack surface. A settings page is normally regarded as a relatively passive administrative interface, but in the vulnerable execution flow, loading that interface could trigger backend subprocess creation.
It also complicates incident investigation. The user whose action triggers the process may not be the same user who created the malicious configuration. The meaningful forensic evidence may be the earlier configuration change, not simply the later process launch.
The original advisory explicitly identifies the server-list operation as an execution trigger and describes the potential for repeated execution when stored configurations are loaded.
Environment Variable Injection Expands the Attack Surface
The env field introduced another security consideration.
MCP Stdio subprocesses often need environment variables. For example, a legitimate MCP server might require an API endpoint, an authentication token, or a configuration option.
However, environment variables are also capable of influencing how programs load libraries, locate executables, and initialize their runtime.
In the vulnerable Langflow implementation, user-controlled environment settings could be passed into the spawned process without sufficiently restrictive validation.
Consider two relevant categories of environment variables.
On Unix-like systems, PATH controls where executable names are resolved. Manipulating this variable can change which executable is selected when a program invokes a command by name.
On Linux, LD_PRELOAD can influence dynamic library loading for compatible dynamically linked programs. If an attacker can control both the variable and the referenced library content, the result may provide another route to attacker-controlled code execution.
Other environment variables can affect language runtimes, dependency resolution, and subprocess behavior.
These mechanisms do not mean that setting an environment variable always results in a successful exploit. Practical impact depends on the launched executable, operating system, runtime behavior, available files, and attacker control.
Nevertheless, the original vulnerability crossed two related security boundaries: it allowed unsafe control over the command being executed and unsafe influence over the execution environment.
The appropriate defense is not merely to block one environment-variable name. It is to define which environment variables are required for approved MCP integrations and reject other tenant-controlled values.
Modern Langflow documentation includes LANGFLOW_MCP_SERVER_ENV_ALLOWLIST for restricting which environment-variable names an MCP Stdio configuration may set. This should be considered alongside package restrictions and process isolation.
CVE-2026-105740 Attack Scenarios in Real AI Infrastructure
Understanding the practical consequences requires examining how Langflow is commonly deployed.
The presence of a vulnerable version does not prove that an attacker has compromised the system. Exploitation depends on access to a reachable configuration or execution path, and subsequent impact depends on the privileges and resources available to the Langflow process.
However, several deployment patterns can turn this vulnerability into a serious security incident.
Scenario 1: A low-privileged Langflow user compromises the backend
Consider a company operating a shared Langflow environment for internal AI development.
Several employees have accounts that allow them to create flows, configure tools, and experiment with MCP integrations. The server is deployed inside a container with network access to internal model services and a database.
One user account is compromised through credential theft or another authentication-related incident.
Ordinarily, the compromised account should remain constrained by the permissions assigned to that user. The attacker might be able to view or modify certain application resources, but should not automatically gain arbitrary command execution against the application server.
In a vulnerable Langflow installation, the attacker may be able to configure an MCP Stdio server and exploit the execution path.
Commands would execute with the privileges of the Langflow process, not necessarily those of the compromised application account. This distinction is critical because the operating-system identity may have access to resources that the application’s user-permission model was intended to protect.
The result could include access to application files, locally available credentials, database connections, or other services reachable from the Langflow environment.
Scenario 2: An exposed development instance weakens the authentication boundary
Development environments are frequently deployed with permissive settings to reduce setup friction. A visual AI workflow editor might be exposed through a temporary public address, a development VM, or a container with a published port.
Langflow’s authentication behavior is especially relevant here.
The LANGFLOW_AUTO_LOGIN setting controls automatic login to the visual editor. Current documentation distinguishes visual-editor auto-login from API-key authentication, while the related CVE-2026-105697 advisory also describes vulnerable deployment configurations in which automatic login makes the MCP attack path reachable without ordinary account credentials.
The exact exposure depends on the installed version and authentication-related settings. It is therefore inaccurate to claim that every deployment with automatic login enabled exposes precisely the same unauthenticated API behavior.
The broader lesson remains: a CVE classified as authenticated RCE may become practically accessible to an unauthenticated external user when the surrounding application automatically grants an authenticated session or fails to enforce the intended authentication boundary.
Langflow’s authentication documentation explains these settings, while the related MCP vulnerability advisory discusses how they affect this execution path.
For administrators, the immediate question should not simply be whether the instance uses a login screen. It should be whether an untrusted visitor can obtain permissions to manage MCP connections or execute flows containing Stdio configurations.
Scenario 3: AI agent infrastructure exposes cloud and API credentials
A more consequential scenario involves Langflow deployments connected to production AI services.
An AI workflow may need access to a language model provider, a vector database, an internal REST API, and a storage system. Each integration introduces credentials or network permissions into the execution environment.
An attacker who achieves server-side command execution may attempt to discover credentials available to the Langflow process.
Potentially exposed assets include model API keys, service-account credentials, database connection information, local configuration files, and credentials injected through environment variables or mounted secret files.
Possession of those credentials could support further unauthorized access outside the original Langflow application.
For example, a stolen model-provider API key might enable unauthorized consumption of paid inference services. A database credential might expose internal application data. A cloud workload identity could permit access to resources beyond the compromised container, depending on its assigned permissions.
Not every Langflow deployment has these privileges. Well-designed environments can substantially reduce the impact through credential scoping, network segmentation, and isolated execution.
However, the orchestration role of Langflow means that defenders should assess the surrounding AI infrastructure, rather than treating the vulnerability as a problem limited to one container.
Scenario 4: A stored MCP configuration becomes a delayed execution mechanism
A stored malicious configuration can be harder to investigate than a single exploit request.
If the configuration persists and is automatically used whenever Langflow reconnects to an MCP server, the attacker may not need to repeat the original configuration operation.
Subsequent legitimate activity could cause additional execution attempts.
From the defender’s perspective, an unusual backend process might appear during a routine settings-page visit or workflow operation. Without correlating that event to earlier configuration changes, investigators could miss the initiating action.
This behavior creates an additional reason to preserve MCP configuration history and record who changed executable-related settings.
Removing a malicious server configuration is essential during incident response, but it may not be sufficient if the attacker has already modified the host, obtained credentials, or established another persistence mechanism.
CVE-2026-105740 vs CVE-2026-105697: Why Langflow 1.9.0 Is Not the Whole Story
The relationship between CVE-2026-105740 and CVE-2026-105697 deserves particular attention.
The original CVE-2026-105740 record identifies Langflow versions earlier than 1.9.0 as affected and 1.9.0 as the fixed release.
That statement is accurate for the specific configuration path described in the original advisory. However, security researchers subsequently documented a related OS command injection issue, CVE-2026-105697, that affected a wider range of MCP Stdio execution paths.
The later advisory explains that Langflow 1.9.0 introduced restrictions for commands submitted through the MCP configuration API. The problem was that not every route to the subprocess execution mechanism was subject to the same restrictions.
An MCP configuration embedded in a flow, or supplied through another supported configuration mechanism, could bypass the earlier validation layer.
The more complete fix arrived with Langflow 1.10.3, where validation was applied to the process-execution boundary itself and the vulnerable shell-based launch pattern was replaced.
| Langflow version | Security interpretation |
|---|---|
| Earlier than 1.9.0 | Affected by CVE-2026-105740 and the overlapping MCP command execution weakness |
| 1.9.0 through 1.10.2 | Original MCP settings API vector addressed, but related MCP execution paths remained vulnerable under CVE-2026-105697 |
| 1.10.3 and later | More comprehensive MCP Stdio command validation and execution-boundary fixes |
| Later maintained releases | Preferred for production use after reviewing additional security advisories and compatibility requirements |
This is not simply a difference in CVE naming. It reflects two levels of remediation.
The earlier fix restricted what could enter through a particular API. The later fix enforced restrictions across multiple ways of reaching the execution mechanism.
The distinction is documented in the original Langflow fix PR #12290 and the subsequent GHSA-w794-rj3p-xv45 advisory.
GitHub
+1
For vulnerability management teams, this has an important consequence. A scanner that evaluates only CVE-2026-105740 may classify a server running Langflow 1.9.0 as patched for that CVE. That does not establish that the deployment is safe against the broader MCP Stdio command execution weakness.
Administrators should inventory both CVEs and verify the actual execution protections provided by the installed release.
For production deployments, upgrade to a maintained Langflow release that includes the 1.10.3 execution-boundary fixes or later security hardening. Do not stop at 1.9.0 merely because it is the originally recorded patched version for CVE-2026-105740.
Understanding the Langflow Patch and Security Architecture
The two-stage remediation illustrates an important principle in secure software design: validation should occur at every relevant trust boundary, with final enforcement at the sensitive operation.
An API validator can reject suspicious incoming configurations, but it cannot guarantee security when the same internal execution function is accessible through other interfaces.
Complex AI workflow platforms frequently have multiple sources of configuration. A component might receive settings from a visual editor, a saved workflow, an API request, an imported file, or runtime parameter overrides.
If each of these paths eventually invokes the same subprocess creation function, the security policy must apply regardless of which path supplied the configuration.
The later Langflow remediation introduced shared MCP Stdio validation at additional execution points, including the final subprocess-launch boundary.
Conceptually, a more secure execution path follows this pattern:
def prepare_mcp_process(command, args, env): validate_allowed_command(command) validate_command_arguments(command, args) validate_environment_variables(env) return { "command": command, "args": args, "env": env, }This is illustrative security pseudocode, not an exact copy of Langflow’s patched implementation.
The critical property is that execution cannot proceed without satisfying the relevant policy checks. The checks must also account for interpreters, package launchers, shell wrappers, and other executable types that may allow the caller to perform additional operations.
Avoiding bash -c eliminates an unnecessary shell-interpretation layer, but an allowed executable may still be dangerous if its arguments remain unrestricted.
For example, package managers and interpreter runtimes are legitimate tools for launching MCP servers. Yet the ability to run an arbitrary package or script can also provide a route to code execution.
This is why Langflow’s more recent security documentation exposes options to restrict package runners, block tenant-controlled interpreter entrypoints, and limit Docker-based MCP execution.
The vendor’s guidance recognizes that safe MCP operation requires more than a fixed application version. It requires policy decisions that match the trust level of the people and applications using the deployment.
GitHub
+1
How to Check Whether Your Langflow Deployment Is Affected
The safest initial validation is to identify the installed package versions and examine how the deployment exposes MCP configuration and execution functionality.
Version inspection does not modify the running application and can usually be performed without interacting with potentially dangerous MCP configurations.
For a Python installation, the following commands provide package-version information:
python -m pip show langflow
python -m pip show lfx
python -m pip show langflow-baseThe output should be compared with the official advisories relevant to the installed package.
If the application runs in Docker, inspect the deployed image rather than relying only on a local development environment:
docker ps
docker inspect <langflow-container-name> \
--format '{{.Config.Image}}'The image identifier is useful for inventory, but a mutable image tag alone is not definitive evidence of the packaged code version. Where possible, verify the installed package inside the actual container or inspect the image’s immutable digest and build manifest.
In Kubernetes environments, administrators should inspect the running workload images, configuration, and application inventory across all namespaces where Langflow may be deployed.
A Helm chart version should not automatically be treated as the application version. The deployed image and installed packages remain the authoritative information for determining exposure.
Check authentication and MCP configuration permissions
Once the installed version is known, review the authentication configuration.
The assessment should determine whether automatic login is enabled, whether untrusted users can reach the visual editor, and whether normal users can create or modify MCP server configurations.
Inspect relevant environment settings in the deployment manifest, secret-management system, or container configuration.
LANGFLOW_AUTO_LOGIN=false
LANGFLOW_MCP_SERVERS_LOCKED=trueThese values are examples of a restrictive deployment posture, not a complete remediation for vulnerable software.
Where supported, locking MCP server management prevents non-superusers from modifying MCP server connections. Disabling automatic login helps ensure that access requires an explicit authentication process.
However, access controls alone do not eliminate the risk from other code-execution features, compromised privileged accounts, or vulnerable flow-execution paths.
Review stored MCP server configurations
Administrators should inspect MCP server configurations for unexpected commands, unusual arguments, unfamiliar packages, or environment-variable overrides.
Pay particular attention to configurations that launch shell interpreters, generic script runtimes, package downloaders, or container runtimes without a documented business requirement.
A normal MCP integration may legitimately use an interpreter or a package runner. Therefore, the presence of these executables is not sufficient to establish compromise.
The investigation should correlate executable selections with configuration ownership, creation timestamps, expected business use, and the packages or scripts being invoked.
For systems suspected of compromise, collect and preserve relevant records before removing suspicious configurations. Investigators should avoid repeatedly opening or refreshing stored MCP connections on an unpatched instance because the operation itself may trigger execution.
Safe Validation of CVE-2026-105740 in an Authorized Environment
Security teams often want to go beyond version detection and establish whether the relevant security boundary actually rejects unauthorized commands.
For CVE-2026-105740, testing should be performed in an isolated lab or authorized staging deployment. It is important not to mistake the creation of an MCP configuration for an entirely passive operation.
A poorly chosen test may cause the application to launch a subprocess immediately or when another interface retrieves the MCP server list.
A defensible validation strategy separates three different questions.
The first question is whether an authenticated, non-administrative user can submit arbitrary MCP executable configurations through the REST API. This tests the originally disclosed entry point.
The second question is whether alternative configuration paths, such as flow-embedded MCP settings, are subject to equivalent restrictions. This addresses the broader issue highlighted by CVE-2026-105697.
The third question is whether the final subprocess creation mechanism enforces a security policy even when earlier validation is bypassed.
To validate these properties safely, test with deliberately disallowed but non-destructive configurations in a disposable environment. Confirm that the application rejects the configuration before creating an operating-system process.
Testing should also include permitted MCP integrations to ensure that stricter validation has not silently broken legitimate workflows.
A successful security validation needs evidence of both negative and positive behavior: forbidden execution paths are blocked, while authorized MCP operations continue to function correctly.
Security engineers should document the tested Langflow version, the configuration entry point, the expected policy, the observed server response, and any corresponding subprocess activity.
A successful rejection at one API endpoint does not demonstrate that every possible route to the execution sink is protected.
That is precisely why CVE-2026-105740 should be examined alongside the later related advisory rather than in isolation.
Detecting Possible Exploitation in Langflow Logs and Host Telemetry
Detection for CVE-2026-105740 requires visibility across application and operating-system activity.
Traditional web application monitoring may identify suspicious API requests but miss command execution initiated later by background MCP connection logic. Conversely, endpoint monitoring may identify an unusual subprocess without revealing which stored MCP configuration caused it.
The strongest detection approach correlates both layers.
At the application layer, examine requests involving MCP server creation, modification, and listing operations. Particular attention should be given to configuration changes made by users who do not normally administer MCP integrations.
The relevant paths include:
POST /api/v2/mcp/servers/{server_name}
PATCH /api/v2/mcp/servers/{server_name}
GET /api/v2/mcp/servers?action_count=trueThese requests can be legitimate. Their significance increases when they occur in suspicious sequences or correspond to unexpected executable configurations.
For example, an unusual MCP configuration modification followed by a server-list request and an unexpected child process from the Langflow backend provides a more compelling investigation signal than any single event in isolation.
At the operating-system layer, defenders should monitor subprocess creation originating from the Langflow service.
Depending on the affected release, relevant events may involve a Python Langflow process launching a shell and that shell initiating additional commands.
The most useful fields include the parent process, executable path, command-line arguments, process identity, working directory, container identity, and creation time.
On hosts that support appropriate endpoint telemetry, suspicious process activity can be correlated with network connections and file operations occurring shortly afterward.
Behavioral indicators worth investigating
An investigator should examine unexplained subprocesses launched by Langflow, particularly when they are inconsistent with the organization’s approved MCP integrations.
Unexpected shell launches, unfamiliar interpreter arguments, access to sensitive files, or outbound connections from the Langflow execution context may indicate suspicious activity.
Additional signals may include modifications to startup files, unusual writes inside application directories, or changes to MCP configurations that cannot be explained by authorized development.
These are behavioral indicators, not confirmed indicators of compromise unique to CVE-2026-105740.
A legitimate MCP server may launch Node.js, Python, Docker, or another runtime. Detection rules that alert indiscriminately on those executable names may create substantial false positives.
The better approach is to define what each production Langflow deployment is allowed to launch and detect deviations from that baseline.
Why HTTP logs alone may not reveal the full attack
A web server log can show that a configuration endpoint was accessed, but it may not contain the submitted MCP command or its environment settings.
Even when a configuration change is recorded, a subsequent execution event may occur under a separate request or background task.
For investigations, correlation across configuration history, application audit events, and subprocess telemetry is therefore essential.
Organizations should also avoid logging complete MCP environment dictionaries into broadly accessible systems. Those dictionaries can contain credentials or other confidential values.
An effective audit record can preserve metadata, policy decisions, and safely redacted configuration details without exposing secrets.
How to Fix CVE-2026-105740 and Harden Langflow
The immediate corrective action is to upgrade affected Langflow installations.
For the original CVE-2026-105740 configuration path, 1.9.0 was the first fixed release. However, because related command execution weaknesses remained through 1.10.2, administrators should deploy a maintained release containing the 1.10.3 fixes or later security updates.
Package upgrades should be tested against existing MCP integrations, particularly those that use custom interpreters, Docker, npx, or uvx.
Once the upgrade is complete, organizations should also review the privileges assigned to the Langflow process and the resources accessible from its execution environment.
A patched application can still expose substantial risk if untrusted users are allowed to execute arbitrary custom components or if the runtime has broad access to production secrets and infrastructure.
Disable automatic login in production
Production deployments should require explicit authentication and use appropriately configured credentials.
LANGFLOW_AUTO_LOGIN=falseThis should be combined with secure superuser credentials, a suitable reverse proxy or API gateway, and network controls that prevent unauthorized access to development interfaces.
The official Langflow authentication guidance provides additional information about the relevant settings and their behavior across deployment modes.
Authentication reduces unauthorized entry but does not automatically make every authenticated user safe. Organizations should still restrict who can configure executable MCP connections.
Restrict MCP server administration
Where supported, administrators can lock MCP server management:
LANGFLOW_MCP_SERVERS_LOCKED=trueThis reduces the number of users who can modify MCP connection configurations through the UI or API.
It does not replace patching or restrict every other code-execution capability in Langflow. Instead, it forms part of a broader least-privilege policy.
Apply MCP package and interpreter restrictions
For multi-user deployments, the executable packages and runtimes available to MCP connections deserve special consideration.
Langflow supports environment variables for controlling permitted package runners and tightening interpreter and Docker execution.
An illustrative restrictive configuration is:
LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES=
LANGFLOW_MCP_SERVER_ENV_ALLOWLIST=
LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true
LANGFLOW_MCP_SERVER_DOCKER_HARDENING=trueIn the documented behavior, an empty allowed-packages value prevents the corresponding package runners from accepting arbitrary tenant-selected packages, and an empty environment allowlist prevents tenant-supplied environment-variable overrides. The interpreter and Docker hardening options impose additional restrictions.
These settings should be evaluated against the installed release, because configuration support and enforcement can differ between versions. They can also intentionally disable previously working integrations.
For organizations with approved MCP packages, explicitly listing the permitted packages may provide a more usable policy than blocking all package runners.
The Langflow MCP server configuration documentation describes these controls and their intended behavior.
Langflow Documentation
Restrict runtime overrides
API callers may also be able to supply runtime overrides for flow component settings.
This matters because an application with several configuration entry points must not enforce strict policies only when a value is entered through the visual editor.
Langflow provides LANGFLOW_TWEAKS_POLICY to restrict which flow fields API callers may override.
For a production application that requires explicitly declared runtime parameters, an operator may use:
LANGFLOW_TWEAKS_POLICY=declaredFor a flow-serving environment that does not require component overrides, the more restrictive off policy may be appropriate.
The precise behavior should be verified against the flow’s design and the installed Langflow release. The setting is not a general-purpose sandbox and does not replace command validation or infrastructure isolation.
See the official documentation for restricting API tweaks for the distinctions between the supported policies.
Langflow Documentation
Isolate the Langflow execution environment
A secure Langflow deployment should operate with the minimum privileges required for its actual workloads.
The container or service account should not have unnecessary filesystem access, host-level execution privileges, or broad permissions to cloud services.
Sensitive credentials should be scoped to specific applications and capabilities. Production databases should use separate accounts with narrowly defined permissions.
Network policies should limit outbound connections from the Langflow workload to the endpoints required by approved integrations.
Where different users or organizations run untrusted flows, infrastructure-level tenant isolation is necessary.
Langflow’s own security documentation explains that Langflow is a code-execution platform and does not inherently provide complete isolation between users sharing a single Langflow process.
Langflow Documentation
This limitation should influence architecture decisions even after all known CVEs have been patched.
A shared runtime with access to multiple tenants’ secrets is fundamentally different from isolated execution environments with separate identities, filesystems, and network permissions.
Incident Response After Potential Langflow RCE Exposure
Organizations that discover an unpatched Langflow instance should determine whether exploitation was possible and whether suspicious activity occurred.
The initial investigation should establish the vulnerable version’s deployment period, its network exposure, the users who could access MCP settings, and the authentication configuration in use.
Next, investigators should preserve relevant application, reverse-proxy, container, and endpoint logs.
If suspicious MCP configurations are present, the affected workload should be contained before those configurations are inspected through functionality that might initialize the connections.
A potentially compromised Langflow instance should also trigger review of credentials accessible to the service.
Depending on the deployment, this may include model-provider tokens, database passwords, API keys, cloud credentials, and integration secrets.
Credential rotation should be informed by the scope of plausible exposure. Rotating only the Langflow login password will not address compromised service credentials available to the backend.
If evidence indicates that arbitrary commands ran, investigators should examine the affected filesystem, process activity, network connections, and any shared resources accessible to the workload.
They should also consider whether the attacker changed flows, modified configurations, introduced unauthorized components, or accessed connected databases.
Restoring the application from a trusted image and verified configuration may be preferable to attempting to clean an environment whose integrity cannot be established.
The central incident-response principle is that successful RCE can invalidate assumptions about the confidentiality of credentials and the integrity of the affected runtime.
Patching the original vulnerability prevents the corresponding future exploitation path, but it does not undo changes made during an earlier compromise.
Is CVE-2026-105740 Being Exploited in the Wild?
Public proof-of-concept exploitation and confirmed active exploitation are different evidentiary categories.
The original Langflow security advisory includes a reproduction demonstrating the command-execution weakness. The CVE record also contains CISA Vulnrichment information indicating proof-of-concept exploitation.
This establishes that exploitability has been demonstrated and documented.
It does not, by itself, prove an active campaign targeting organizations or establish that the vulnerability appears in CISA’s Known Exploited Vulnerabilities catalog.
As of October 15, 2026, the sources reviewed for this article do not establish a confirmed, widespread in-the-wild exploitation campaign specifically attributed to CVE-2026-105740.
The related CVE-2026-105697 advisory reports that its researcher identified vulnerable internet-facing Langflow deployments, which supports the importance of exposure management but is not equivalent to confirmed exploitation of those systems.
OpenCVE
+1
Organizations should not interpret the absence of confirmed campaign reporting as evidence that a vulnerable deployment is safe.
The disclosed mechanics are sufficiently direct that an attacker with the necessary access would not need to develop a sophisticated exploit chain to abuse the original configuration path.
A combination of critical impact, available technical details, and potentially exposed AI development infrastructure makes prompt remediation appropriate.
Why CVE-2026-105740 Matters for AI Agent Security
CVE-2026-105740 is an example of a broader security challenge emerging in AI agent platforms.
Traditional application security often treats configuration interfaces, business logic, and operating-system execution as distinct areas.
Agent systems increasingly connect these areas.
An agent platform may allow users to define workflows, select tools, supply execution parameters, install MCP packages, connect external services, and authorize model-driven operations.
Each capability may be legitimate in isolation. The security risk appears when the platform fails to preserve boundaries between lower-trust inputs and higher-privilege actions.
In the case of CVE-2026-105740, the failure did not require an AI model to produce a malicious response. The problem existed in the infrastructure used to connect and execute MCP tools.
That distinction is important because not every AI agent vulnerability is prompt injection.
Prompt injection manipulates instructions interpreted by a model or agent. MCP command injection targets the code and configuration that launch tool processes. The two classes can interact in complex systems, but they are not interchangeable.
A secure system must address both model-level manipulation and deterministic backend execution vulnerabilities.
For example, defenses that screen prompts for malicious language will not prevent an authenticated user from submitting an unsafe MCP configuration directly through an application API.
Likewise, strong command validation does not automatically prevent an agent from invoking an authorized tool with harmful parameters.
The appropriate security architecture combines authenticated and authorized configuration changes, constrained tool execution, restricted subprocess creation, runtime isolation, and monitoring of actual tool behavior.
This broader execution-boundary problem is also examined in MCP STDIO RCE, The Agent Execution Boundary Failed, which analyzes how Stdio-based agent integrations can introduce local command-execution risks across different platforms.
From Vulnerability Scanning to AI Workflow Security Validation
A conventional vulnerability scanner may identify the installed Langflow version and flag CVE-2026-105740.
That is valuable, but it does not answer every operational question.
For example, a version check alone may not determine whether an exposed Langflow instance allows automatic login, whether untrusted users can modify MCP configurations, or whether the deployment still contains another vulnerable execution path.
A complete assessment should connect dependency information to actual application behavior.
For Langflow, this means examining the management API, configuration permissions, runtime overrides, MCP execution policies, and the privileges of the underlying workload.
The most useful validation evidence establishes whether a lower-privileged actor can cross a meaningful security boundary.
Security teams should also distinguish a vulnerability finding from confirmed exploitation. Discovering Langflow 1.8.x in a software inventory is evidence of an affected version; it is not evidence that arbitrary commands were executed.
This distinction helps avoid both exaggerated incident reporting and false confidence in superficial scanning results.
Applying AI-driven penetration testing to agent infrastructure
AI-driven security testing can be useful when it combines vulnerability intelligence, application-specific configuration review, and controlled verification of reachable attack paths.
For example, an authorized assessment of a Langflow environment could correlate its installed release with disclosed CVEs, determine which MCP management interfaces are exposed, examine the authorization model, and evaluate whether unsafe subprocess configurations are rejected.
The assessment should then produce reproducible evidence and remediation guidance rather than simply reporting that an MCP integration exists.
This approach is particularly relevant for platforms that support many configurable tools and execution paths, where the same underlying capability may be accessible through different workflows.
Penligent’s earlier analysis of CVE-2026-33017 and the Langflow AI pipeline attack surface explores the consequences of code execution within an AI orchestration environment. The same principle applies here: the security impact is determined not only by the initial vulnerability but by the systems, permissions, and credentials connected to the compromised execution context.
For teams evaluating AI agent infrastructure, Penligent’s approach to AI-native penetration testing provides additional context for assessing application security beyond traditional endpoint and dependency checks.
CVE-2026-105740 and the Future of MCP Security
The broader lesson from this disclosure is that MCP integration functionality must be treated as part of an application’s privileged execution surface.
The convenience of adding a new tool connection can conceal a complicated chain of security decisions.
A platform must determine whether a user is authorized to configure a tool, whether the selected executable is permitted, whether the arguments introduce prohibited behavior, whether the environment contains unsafe overrides, and whether the subprocess can access resources outside its intended scope.
Those questions become more difficult in shared AI development environments, where multiple users may build independent workflows against the same underlying process.
They also become more important as AI agents gain access to tools that can modify files, execute software, deploy applications, and interact with production infrastructure.
An MCP connection is therefore not merely a communication integration. In Stdio deployments, it can be an executable workload.
Production security policies should reflect that reality.
Organizations should maintain inventories of MCP integrations, approve permitted executable packages, constrain environment-variable injection, and ensure that process execution occurs inside appropriately isolated environments.
They should also test negative security cases. A platform that successfully runs legitimate MCP tools is not necessarily secure; it must also demonstrate that unauthorized or malformed configurations cannot trigger privileged execution.
Finally, application teams should monitor security advisories for the entire AI orchestration stack, including supporting packages and runtime components.
CVE-2026-105740 and CVE-2026-105697 demonstrate that security fixes can evolve as researchers discover additional paths to the same vulnerable execution mechanism.
Frequently Asked Questions About CVE-2026-105740
What is CVE-2026-105740 in Langflow?
CVE-2026-105740 is a critical OS command injection vulnerability affecting Langflow’s MCP Stdio server configuration functionality. An authenticated user can supply executable-related configuration values that reach an unsafe backend subprocess execution path. The vulnerability has a CVSS v3.1 score of 9.9 and is classified as CWE-78.
Which Langflow versions are affected by CVE-2026-105740?
The CVE record identifies Langflow versions earlier than 1.9.0 as affected. Version 1.9.0 introduced the fix for the original vulnerability. However, the related CVE-2026-105697 affected additional MCP execution paths through Langflow 1.10.2, with more comprehensive fixes delivered in 1.10.3. Production deployments should therefore use a maintained release that includes those later protections.
Is CVE-2026-105740 an unauthenticated RCE vulnerability?
The original vulnerability is classified as authenticated remote code execution because it can be exploited by a user with access to the relevant Langflow MCP configuration functionality. However, actual exposure depends on deployment settings. Environments that permit automatic login or otherwise grant configuration access without meaningful authentication may expose the execution path to external users who do not possess separate account credentials.
Does CVE-2026-105740 require administrator privileges?
No. The original advisory describes exploitation by authenticated users who do not require Langflow administrator privileges. The resulting subprocess runs with the privileges of the Langflow backend process, which may differ substantially from the permissions associated with the application-level user.
Can CVE-2026-105740 be triggered without running an AI workflow?
Yes. The original advisory describes execution during MCP server listing when Langflow attempts to connect to configured Stdio servers. As a result, opening the MCP settings interface or fetching the server list with action counting enabled can be sufficient to trigger the execution path under the vulnerable conditions.
Is Langflow 1.9.0 sufficient to fix MCP command injection completely?
No. Langflow 1.9.0 addresses the originally reported configuration API path associated with CVE-2026-105740, but the related CVE-2026-105697 identifies additional vulnerable execution paths in later releases. Langflow 1.10.3 introduced broader validation at the subprocess execution boundary. Administrators should also apply subsequent supported security releases and hardening guidance.
Does this vulnerability affect every MCP server?
No. CVE-2026-105740 is a vulnerability in specific Langflow implementations of MCP Stdio configuration and execution. It is not a universal flaw in the MCP protocol and does not establish that every MCP server or MCP client is vulnerable.
Other implementations may have different security properties and should be assessed independently.
Can CVE-2026-105740 expose API keys and cloud credentials?
Potentially. If an attacker achieves remote code execution, the resulting access may include secrets, files, environment variables, or network resources available to the Langflow process. The precise impact depends on the deployment’s privileges, secret-management design, network controls, and isolation boundaries.
Is there a public proof of concept for CVE-2026-105740?
Yes. The original GitHub security advisory contains reproduction details demonstrating the vulnerable MCP command-execution behavior. A public proof of concept establishes technical exploitability but does not necessarily indicate confirmed active exploitation against production organizations.
How should organizations prioritize CVE-2026-105740?
Organizations should prioritize internet-accessible Langflow deployments, shared environments with untrusted users, and installations connected to sensitive cloud, database, or model infrastructure. Immediate priorities include identifying vulnerable versions, reviewing authentication and MCP configuration permissions, upgrading to a maintained secure release, and investigating suspicious subprocess or configuration activity.
Conclusion
CVE-2026-105740 reveals a critical security failure at the boundary between MCP configuration and operating-system execution in Langflow.
The vulnerability allows authenticated users to influence commands launched by the backend through the MCP Stdio transport, creating the possibility of remote code execution without administrator privileges. Its impact is especially serious when Langflow operates as an orchestration layer connected to sensitive APIs, internal applications, cloud infrastructure, and AI development workflows.
The original vulnerability was addressed in Langflow 1.9.0, but the related CVE-2026-105697 demonstrated that configuration validation alone was insufficient. The more comprehensive execution-boundary protections introduced in Langflow 1.10.3 illustrate why security policy must be enforced consistently across every route to a sensitive operation.
For defenders, the priority is clear: identify affected deployments, upgrade the software, restrict MCP configuration privileges, harden subprocess execution, isolate untrusted workloads, and correlate application configuration changes with host-level activity.
As AI agent platforms expand their ability to invoke external tools, the fundamental security question is no longer just whether an agent can access a tool. It is whether the surrounding infrastructure can reliably prevent lower-trust input from becoming unauthorized code execution.
CVE-2026-105740 shows what happens when that boundary fails.
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew