Langflow CVE-2026-5027: How a file-upload path traversal and unauthenticated auto-login turn exposed AI app builders into remote code execution

TL;DR — 90 seconds

Affected?

Self-hosted Langflow installations below 1.9.0, especially when reachable from the internet. The default configuration with auto-login enabled (no login enforced) makes it worse. Censys counts around 7,000 publicly exposed instances, mostly in North America.

Risk?

Unauthenticated remote code execution. A path traversal in the POST /api/v2/files endpoint (CVE-2026-5027, CVSS 8.8) writes files to arbitrary locations via an unchecked filename parameter; combined with auto-login, a single request without credentials suffices for code execution.

Immediate action?

Upgrade to Langflow ≥ 1.9.0 (released 15 April 2026). Until then: take the instance off the open internet, enforce authentication (LANGFLOW_AUTO_LOGIN=false), restrict access to known sources.

Recommendation?

Mid-market and enterprise: treat every Langflow instance as a production, internet-facing service, not an internal tinkering tool. First check whether one is reachable at all — most operators underestimate exactly that.

Criticality?

critical (active in-the-wild exploitation since 10 June; unauthenticated vector). With an honest caveat: the patch has been available since 15 April and the payloads observed so far only write test files — the pressure is on the exposed, unpatched instance, not the software itself.

 

What is the problem?

Langflow is an open-source visual builder for assembling AI applications and agents by drag-and-drop — prompts, models, tools and data sources are wired into a flow and then served as an API. Precisely because that is so convenient, Langflow often ends up on a server quickly and just as often directly on the open internet. CVE-2026-5027 sits in this service's file upload. Tenable, which found the flaw, describes it plainly: the POST /api/v2/files endpoint does not sanitise the filename parameter from the multipart form, so path-traversal sequences (../) let files be written to arbitrary locations on the filesystem. This is a classic vulnerability class, known for decades — landing here in a component that accepts foreign files and writes them to disk.

The second building block makes it sharp. By default Langflow enables an unauthenticated auto-login: whoever reaches the service gets a valid session without credentials. Caitlin Condon of VulnCheck puts it succinctly: because no login is enforced, a single unauthenticated request is enough to obtain a valid session token before the actual exploitation. The file-write thus becomes a complete, precondition-light path to remote code execution: an attacker writes a file to a location from which it is executed or loaded at the next start, and the service does the rest. The path is so dangerous because both building blocks — missing input validation and missing authentication enforcement — come together in the default delivery.

Important for an honest assessment: CVE-2026-5027 is not newly discovered. By its own account Tenable tried three times in January and February 2026 to report the flaw to the maintainers and disclosed it on 27 March (advisory TRA-2026-26); it was fixed in Langflow 1.9.0 on 15 April. What is fresh is the escalation: VulnCheck has observed active in-the-wild exploitation since 10 June. So this is not a zero-day but a patched bug now under broad attack — the most uncomfortable category for anyone who slept through the update.

Who is affected?

The dividing line runs along „exposed and unpatched“. Fully hit are self-hosted instances below 1.9.0 that are reachable from the open internet and have kept the default auto-login — and per the Censys data that is around 7,000 of them, mostly in North America. Anyone running Langflow purely internally has a lower acute risk but closes the flaw with the same update; the traversal itself does not disappear just because an attacker has to get onto the network first. This flaw also does not stand alone: Langflow was repeatedly targeted by active exploitation in 2026, including via CVE-2026-0770, CVE-2026-33017, CVE-2026-21445 and CVE-2025-34291 — the last reportedly used by the state-aligned group MuddyWater. Anyone with an old Langflow version open on the network is therefore exposed not just to a single flaw but to a whole series.

Impact

The reliably reachable worst case is code execution in the runtime context of the Langflow service — and that is rarely sparsely equipped. An AI app builder typically holds API keys for the connected models, tokens for data sources, database access and the flow definitions themselves, that is the business logic of the built application. Whoever takes over the service inherits those permissions. The exploitation observed so far is, per VulnCheck, restrained — test files are written, apparently to measure reach and reachability. That is the typical first wave: attackers map where the lever sits before they use it. Benign test files, experience shows, quickly become more once exploitation pays off.

An honest assessment of severity: the CVSS score is 8.8 (High), not 9+, and a patch has existed for two months. What nonetheless lifts the flaw into the critical category is the combination of an unauthenticated vector, trivial exploitability (a single request) and active in-the-wild exploitation across around 7,000 reachable targets. Censys and VulnCheck thus paint the picture the industry has been warning about for months: attackers increasingly aim not at the AI models themselves but at the infrastructure and tooling with which organisations build and run their AI applications. The vulnerability class is ancient; what is new is the place where it hurts.

Mitigation / immediate steps

Immediately: move to the patched line

# Python install (pip)
pip install -U "langflow>=1.9.0"

# or with uv
uv pip install -U "langflow>=1.9.0"

# Container deployment: pull the patched image and pin the tag
docker pull langflowai/langflow:1.9.0
# then pin the Compose/K8s manifest to >=1.9.0 and roll out again

# Verify the installed version
python -m langflow --version
pip show langflow | grep -E 'Name|Version'

Immediately, if an update is not possible short-term

# 1) Disable unauthenticated auto-login — removes the unauth. entry
export LANGFLOW_AUTO_LOGIN=false
export LANGFLOW_SUPERUSER=<admin>
export LANGFLOW_SUPERUSER_PASSWORD=<strong-password>

# 2) Take the service off the open internet:
#    behind a reverse proxy with auth, VPN or IP allowlist;
#    do not bind directly to 0.0.0.0:7860 on the network.

# 3) Additionally restrict the upload endpoint at the reverse proxy
#    where it is not needed (POST /api/v2/files).

Principle

# The patch (>=1.9.0) is the actual fix — it sanitises the file name.
# Auto-login=false and the network restriction are stopgaps that remove
# the unauthenticated mass entry but do not fix the traversal.
# Order: first take it off the net / enforce auth, then patch,
# then expose again in a controlled way.

The order matters more here than with a purely internal flaw: because the attack is active and unauthenticated, reachability counts first. An instance no one can reach from outside is removed from the mass scan, even before the update lands. The update remains mandatory — but closing the open door first buys the time for it.

Detection / verification

Establish inventory: is Langflow running here at all, and is it reachable?

# Running processes / containers
ps aux | grep -i '[l]angflow'
docker ps --format '{{.Image}} {{.Ports}}' | grep -i langflow

# Is the service listening externally? (default port 7860)
ss -tlnp | grep -E ':7860'

# Search repos / manifests for Langflow as a dependency
grep -rniE 'langflow' --include='requirements*.txt' --include='pyproject.toml' \
  --include='docker-compose*.yml' --include='*.yaml' path/to/repos

Check version and configuration

# Version (target: >= 1.9.0)
python -m langflow --version 2>/dev/null || pip show langflow | grep Version

# Is unauthenticated auto-login active?
env | grep -i LANGFLOW_AUTO_LOGIN     # empty/true => default auto-login active

Look for exploitation traces in the access log

# Suspicious uploads to the vulnerable endpoint, especially with
# traversal patterns in the file name (../ or URL-encoded %2e%2e%2f)
grep -E 'POST /api/v2/files' access.log \
  | grep -Ei '\.\./|%2e%2e'

# Unexpected new files outside the upload directory
# (limit the time window, e.g. since 10 June); inspect only copies/test
find / -newermt '2026-06-10' -type f 2>/dev/null \
  | grep -vE '^/(proc|sys|run)/' | head -100

Anyone who finds a hit on the vulnerable endpoint with a traversal pattern should treat the instance as potentially compromised: rotate the API keys and tokens stored in the flows and inspect the written files in an isolated environment, not on the production system. Absence of log hits is no free pass — many default setups do not fully log the upload body.

Operator recommendation

Operational decision block:

• Act now (today) if: a Langflow instance below 1.9.0 is reachable from the internet — first take it off the open network or enforce authentication, then patch.
• Within the running patch cycle (this week) if: Langflow runs purely internally, without external reachability — apply the update, disable auto-login, then restrict access further.
• Only verify if: the instance is already on ≥ 1.9.0, auto-login is disabled and there is no direct internet access.

Mittelstand

The first and most important question is not „Which version?“ but „Is there a Langflow open on the network anywhere in our estate?“. AI build tools are often set up quickly by individual teams and just as quickly forgotten — as a proof of concept that then keeps running in production after all. Treat every such instance like an exposed web service: authentication in front, no direct internet access, regular updates. Anyone who builds AI applications themselves is running infrastructure, not just a tool.

Enterprise / multiple teams

Proceed by inventory rather than spot check: Langflow shows up in container images, internal platforms and data teams, often without central tracking. Scan your own address space specifically for the default port and the characteristic endpoint, capture version levels via the image registry and enforce LANGFLOW_AUTO_LOGIN=false as policy. Langflow's repeated exploitation history in 2026 makes a single-case view inappropriate — this belongs under permanent inventory and exposure control.

Kubernetes / declarative stacks

Roll out the patched image (≥ 1.9.0) via the registry and pin it by digest. Do not expose the service via a public ingress without auth; put a NetworkPolicy and an authenticating reverse proxy in front. Remember: a rolling restart is needed for the pods to actually load the patched image, and secrets that sat in compromised flows must be rotated.

What we did

We checked the report against our estate on the day of the escalation. The first question was not „Which Langflow version?“ but „Is there a Langflow instance running anywhere in our estate or on managed platforms, and is it reachable from outside?“. Because our services are inventoried via image digests and manifests and our own address space is scanned regularly for exposed ports, the answer was there in minutes rather than via a round of calls. Where Langflow is in use, it runs behind enforced authentication and without direct internet access, the version level is on the patched line, and auto-login is disabled by policy.

The lesson learned is the same one we formulated a layer deeper with the LangGraph chain, here only at the outer boundary: an AI build tool is not an internal toy but a production, internet-facing service with privileged secrets in its belly. Patching closes the concrete spot; lasting hardening closes the class — exposure control (is it open on the network?), enforced authentication (no auto-login) and inventory (do we even know where it runs?). This is exactly where it pays off that we build self-hosted AI for the Mittelstand as sovereignty and not as convenience: whoever owns the service has to protect it as an exposed identity — and can, because network, access and secrets are within their own reach.

Conclusion

CVE-2026-5027 is not an exotic bug but a textbook flaw in exactly the wrong place: a path traversal in the file upload, combined with a default unauthenticated login, in a tool that builds AI applications and holds privileged secrets in doing so. The severity is to be assessed honestly: CVSS 8.8, a patch has existed since 15 April, and the exploitation observed so far is restrained. What nonetheless makes the flaw critical is the combination of an unauthenticated vector, trivial exploitability and active in-the-wild exploitation across around 7,000 reachable targets. Anyone running an unpatched or openly reachable instance acts today; anyone running Langflow internally and patched merely verifies. The lasting lesson is not in this one version number: an AI build tool is a production, internet-facing service. Patching closes the spot; exposure control, enforced authentication and inventory close the class.

Sources

• The Hacker News — „Langflow Vulnerability CVE-2026-5027 Exploited for Unauthenticated RCE“ (10 June 2026, Ravie Lakshmanan) — secondary source, escalation/active exploitation, VulnCheck and Tenable quotes
• Tenable Research — advisory TRA-2026-26 (CVE-2026-5027, Langflow path traversal) — primary source, technical description of the upload endpoint
• NVD — CVE-2026-5027 — CVSS 8.8, path traversal classification
• Langflow 1.9.0 release notes (patch version, 15 April 2026) — fix evidence
• VulnCheck — note on active exploitation (Caitlin Condon, LinkedIn) — source of the exploitation and auto-login statements
• Langflow — project page / documentation — context on function and default configuration