Langflow's Critical Authenticated RCE Flaw Targeted in 1,423 Honeypot Exploit Attempts

Authenticated remote code execution means a user who has successfully logged in can make the application run commands on its underlying server. The flaw is especially serious because authentication alone does not restrict the user to safe application functions. It can become a path to the operating system.

CVE-2026-105740 affects Langflow versions before 1.9.0. A user can add an MCP server using the stdio transport and provide a command. Langflow passes that command directly to bash -c "exec {command}" without validation, allowlisting, or sandboxing. The command runs when the server list is fetched.

The vulnerability has a CVSS score of 9.9 and affects non-admin users, not only administrators. Successful exploitation can compromise the server, inject environment variables, support lateral movement, and install a persistent backdoor. The stored configuration can execute again whenever the server list loads.

The observed activity is already broad and international. Previdian recorded 1,423 exploitation attempts against its honeypot sensors beginning September 19, 2026. Those attempts came from 27 unique attacker IP addresses.

The sources were located across Belgium, China, Germany, Hong Kong, Japan, Nigeria, the Philippines, Russia, Seychelles, Singapore, South Korea, Taiwan, Tanzania, the United States, and Vietnam. The activity was not steady. It intensified on October 11, when 333 attempts were registered. By October 15, 66 attempts had been observed.

The figures come from honeypot data, so they measure recorded attempts rather than confirmed compromises of production systems. Still, the timing shows active exploitation while vulnerable Langflow installations may remain exposed. Previdian also linked one address, 192.255.229[.]92, to brute-force activity and exploitation of several Flowise and Langflow vulnerabilities.

The attack does not require administrator privileges. Any authenticated Langflow user can add an MCP server through the application’s configuration endpoint. That makes an ordinary account dangerous when the application accepts commands as configuration data.

The user sends a crafted POST request to /api/v2/mcp/servers/{server_name}. Its command field contains a malicious payload, such as a reverse shell. Langflow stores the command without checking it. The attacker then sends a GET request to /api/v2/mcp/servers?action_count=true. Fetching the server list causes the stored command to execute.

The key mechanism is the stdio transport for MCP servers. Langflow passes the supplied command directly to bash -c "exec {command}". There is no validation, approved-executable list, or sandbox. The command therefore runs with the privileges of the Langflow process, giving the user operating-system command execution.

Authentication proves that someone supplied accepted credentials, but it does not prove that the person is trustworthy. In this case, every authenticated user, including non-admin accounts, can reach the vulnerable MCP configuration feature. The security boundary is therefore only as strong as account credentials and access controls.

Previdian described one sequence in which attackers checked the Langflow version, tried auto-login, and received a 403 because it was disabled. They then successfully authenticated using a common username and password. The attackers immediately used the resulting bearer token to access the vulnerable MCP server configuration endpoint.

Previdian also reported that 192.255.229[.]92 had engaged in generic brute-force attacks. These observations show why weak, reused, or easily guessed credentials can turn an authenticated-only flaw into an internet attack path. Strong unique passwords, disabled auto-login, trusted-user access, and authentication-log review reduce that risk.

Command execution gives attackers the same operating-system access available to the Langflow process. The article reports possible full server compromise, environment-variable injection, lateral movement, and persistent backdoor deployment. The malicious MCP configuration can remain stored and run again whenever the server list loads.

Captured payloads attempted to extract environment variables and Langflow settings, including LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD, and send them to a remote address. Other commands tried to use Docker to access the host filesystem and read /etc/passwd. Attackers also tested commands such as id and whoami.

Secret keys and passwords are valuable because they can expose application settings or enable further access, although the article does not describe every possible use. Environment variables can also alter execution through values such as LD_PRELOAD or PATH. That combination can deepen compromise beyond the initial command and help attackers maintain access or reach other systems.

The article recommends several immediate safeguards for organizations that cannot patch at once. Set LANGFLOW_AUTO_LOGIN=false, avoid exposing Langflow directly to untrusted networks, and allow accounts only for trusted users. These steps reduce the number of ways attackers can obtain or use access.

Organizations should also enforce strong, unique passwords. They should review authentication logs and requests to /api/v2/mcp/servers/ for suspicious activity. This can help identify unusual login attempts, unexpected bearer-token use, or malicious MCP configurations. Auto-login should remain disabled, since the article reports attackers tried that path before authenticating another way.

These measures reduce exposure but do not remove the vulnerability. The recommended long-term action is upgrading Langflow to a patched version. Teams should also investigate suspicious configurations and credentials, because observed payloads targeted secret keys and passwords. If compromise is suspected, the article’s evidence supports treating the server and stored MCP settings as potentially unsafe.

Input validation checks whether supplied data has the expected form and rejects unsafe values. Allowlisting goes further by permitting only specifically approved commands or executables. Together, they prevent a web application from treating arbitrary user text as an operating-system instruction. This is especially important because Langflow accepted a command without validation or an approved-executable list.

Sandboxing places code in a restricted environment. It can limit files, networks, devices, and other resources, reducing what an executed command can reach. Process privileges provide another boundary. Running the application as a narrowly permissioned account limits access to sensitive files and administrative operations.

These controls are strongest when layered. Validation and allowlisting reduce the chance of command execution. Sandboxing limits the command’s surroundings if it runs. Least-privilege process access limits its impact. The article reports that Langflow commands run with the privileges of the Langflow process, showing why that final boundary matters.