HIGH: Langflow Path Traversal CVE-2026-5027 Lets Unauthenticated Attackers Plant Code on Roughly 7,000 Exposed AI Servers

If you run Langflow anywhere on the public internet, stop reading this and go check your version. Then come back.

The open source AI orchestration platform that thousands of data teams use to wire up large language model workflows is in the middle of an active exploitation event, and the entry point requires exactly zero credentials. CVE-2026-5027 is a path traversal flaw in the file upload endpoint that, when chained against a Langflow instance running with default settings, hands an unauthenticated attacker arbitrary file write and a clean path to remote code execution. Tenable disclosed the bug in late March after the maintainers ignored three separate contact attempts in January and February, and VulnCheck honeypots have been catching test payloads against vulnerable hosts ever since. Censys counts roughly seven thousand publicly exposed Langflow instances right now, the majority of them sitting in North America. That is the size of the target list.

The technical story is depressingly simple. The POST /api/v2/files endpoint accepts a multipart form upload and uses the filename parameter from that form to decide where to drop the file on disk. There is no sanitization. There is no canonicalization. There is no allowlist. A filename of "../../../../etc/cron.d/anything" goes exactly where you would expect. Tenable rated the bug 8.8 on the CVSS scale, which feels conservative once you account for the second half of the problem. Langflow ships with AUTO_LOGIN set to true by default, which means a single unauthenticated request to the platform will mint a valid session token before the attacker ever touches the vulnerable endpoint. The "authentication" in the threat model exists only on paper. From an attacker's point of view this is a network-reachable, low-complexity, no-privileges, no-interaction primitive that writes files anywhere on the host filesystem. From there, getting code execution is a creativity exercise rather than an engineering challenge. Drop a shell script into a cron directory and wait. Overwrite a Python module that the Langflow process will import next. Write a public key into the running user's authorized_keys file. Pick your poison.

This is not Langflow's first dance with file paths and unauthenticated endpoints. Earlier this year Iranian state-sponsored actors associated with MuddyWater were observed leveraging CVE-2025-34291 against Langflow deployments to drop loaders for the SPECTRALVIPER backdoor. CVE-2026-0770, CVE-2026-33017, and CVE-2026-21445 all earned their own exploitation campaigns over the past six months, which tells you something about both the platform's attack surface and the kind of attention it is now receiving. Once threat actors find a soft target ecosystem, they tend to stick around. Langflow has joined that unfortunate club.

Affected versions are everything before Langflow 1.10.0 on the application side, and everything before 0.8.3 on the langflow-base package. The patch landed yesterday, June 10, 2026, and the official advisory on GitHub lists the file upload endpoint fix alongside a related critical RCE in the public flow build endpoint that scores a 9.3. If you are reading the changelog for 1.10.0 you will see both issues quietly bundled into the release. Anyone running a self-hosted Langflow instance against a stale tag should treat this as the kind of upgrade that does not wait for the next maintenance window. Cloud-hosted Langflow customers should confirm the upgrade with their provider in writing, because the bug touches the application layer rather than the underlying infrastructure, and a misconfigured tenant is still your problem.

The mitigation conversation gets uncomfortable for anyone who cannot patch immediately. The honest answer is to take the instance off the public internet. Langflow was never designed to be a hardened public-facing service. It is a developer tool that grew up inside research labs and proof of concept demos, and the default configuration reflects that origin. Putting it behind a reverse proxy with strong authentication, locking it to a VPN or Tailscale network, or simply firewalling the port to a known IP allowlist eliminates the trivial exploitation path even on unpatched versions. If you absolutely must keep it exposed, at minimum disable AUTO_LOGIN by setting LANGFLOW_AUTO_LOGIN to false and require real authentication, then enforce a strong superuser password through LANGFLOW_SUPERUSER_PASSWORD. Neither of those flags makes the file upload endpoint safe, but they raise the cost of reaching it from "send one curl command" to "actually obtain a credential first."

Detection deserves the same blunt treatment. The exploitation pattern shows up in HTTP logs as POST requests to /api/v2/files with multipart form payloads containing filename fields that include parent directory traversal sequences. Any web access log entry where the filename contains "../" or its URL-encoded equivalent "%2e%2e%2f" is a near-certain indicator. VulnCheck has been seeing innocuous test files written to predictable locations, which suggests the early waves are still in the reconnaissance and validation stage. Threat hunters should look for files written outside Langflow's own data directory in the past forty eight hours, particularly anything inside cron directories, systemd unit paths, SSH key locations, or Python site-packages directories that Langflow's process user has write access to. Process telemetry showing the Langflow Python interpreter spawning shells, curl, wget, or any compiled binary it did not previously execute is the higher-fidelity signal, and worth a SIEM rule of its own.

The broader story here is one that should be familiar to anyone who has been paying attention to the AI tooling ecosystem. The platforms that data teams are racing to deploy were almost universally built by people optimizing for developer experience inside a trusted research environment. Authentication is an afterthought, sandboxing is minimal, and the default configuration assumes that whoever can reach the service is allowed to control it. That assumption breaks the moment someone in marketing spins up a Langflow demo on a Hetzner box to show a customer, then forgets about it. Multiply that by the seven thousand exposed instances Censys is currently watching and the math gets ugly fast. The vendors building these tools will eventually figure out the security model. The organizations deploying them right now do not have time to wait.

For MSPs and security partners, this is a layup. Any client with a data science or AI initiative is statistically likely to have a Langflow instance, an Ollama deployment, a vector database, or some combination of all three running somewhere their network team has not seen. Most of those deployments were stood up by developers without a security review. A simple external attack surface scan filtered against the Langflow fingerprint will find them, and a thirty minute conversation with the client's data team will surface another half dozen tools the SOC has never heard of. Packaging that into an "AI infrastructure security baseline" assessment, priced as a one-time discovery engagement with a recurring vulnerability monitoring add-on, writes itself. The CVE-2026-5027 story is the headline that gets you in the door. The recurring revenue comes from being the team that already knows where the shadow AI lives.

Patch to Langflow 1.10.0 today if you can. Pull the instance off the public internet if you cannot. Search your logs for the path traversal pattern either way, because seven thousand exposed instances and an active exploitation campaign means "somebody got to your environment first" is not a hypothetical anymore. And if you are an MSP reading this, the next two weeks are the right window to call every client with a data team and ask them what they have running. The answer will surprise both of you.