This article was originally published on aifoss.dev
TL;DR: A path-traversal flaw in Langflow's file-upload endpoint (CVE-2026-5027, CVSS 8.8) lets an unauthenticated attacker write arbitrary files anywhere on your server and turn that into remote code execution. It is under active exploitation as of June 2026, and Langflow's default auto-login makes a single HTTP request enough. Upgrade to 1.9.0 or later, then close the gaps below.
What you'll have running after this guide:
- A Langflow instance on a patched build (≥ 1.9.0) with auto-login disabled and a real superuser
- The editor and API bound to localhost behind a reverse proxy with TLS and authentication
- A firewall and an audit checklist that tells you whether you were already hit
Honest take: If your Langflow is reachable from the public internet on its default port right now, assume it was probed. Patch first, then audit for files you didn't put there — in that order.
What CVE-2026-5027 Actually Does
Langflow is a low-code builder for AI agents and RAG pipelines — MIT-licensed, north of 100,000 GitHub stars, and increasingly the thing teams stand up on a spare box to prototype workflows. That popularity is exactly why it keeps showing up in exploitation reports.
CVE-2026-5027 lives in the POST /api/v2/files endpoint. The upload_user_file() handler takes the filename field from a multipart form and never sanitizes it. Send a filename full of ../ sequences and you can write the uploaded bytes to any path the Langflow process can reach — outside the upload directory, into a cron directory, over a config file, wherever.
Writing a file is not, by itself, code execution. The jump from "arbitrary file write" to "arbitrary code run" is the part security researchers demonstrated: drop a job into a cron path, overwrite a script that something else executes, or plant a startup file. EQSTLab's public proof-of-concept chains the traversal into cron-job injection to land a shell.
Here is the part that makes it ugly. Langflow ships with LANGFLOW_AUTO_LOGIN=True by default. With auto-login on, the visual editor signs every visitor in as a superuser, and a single unauthenticated request will hand back a valid session token. So the "you need to be authenticated" mitigation most people assume protects them is off out of the box. One request gets a token; the next request writes the file.
VulnCheck confirmed in-the-wild exploitation on June 9, 2026, with honeypots catching attackers dropping test files via the traversal. VentureBeat put the number of exposed, attackable servers in the thousands. This is not theoretical.
The Pattern: This Is Langflow's Fourth Critical RCE
CVE-2026-5027 is not a one-off. Langflow has a track record of unauthenticated code-execution bugs, and the lesson for self-hosters is that the endpoint surface needs to be off the public internet regardless of which CVE is current this month.
| CVE | CVSS | Root cause | Fixed in |
|---|---|---|---|
| CVE-2025-3248 | 9.8 |
/api/v1/validate/code ran exec() on unauthenticated input (Flodrix botnet) |
1.3.0 |
| CVE-2025-34291 | 9.4 | Account takeover + RCE via malicious page (linked to MuddyWater) | 1.5.x |
| CVE-2026-33017 | 9.3 |
/api/v1/build_public_tmp executed Python in node definitions |
1.9.0 |
| CVE-2026-5027 | 8.8 |
/api/v2/files path traversal → arbitrary file write → RCE |
1.9.0 |
Notice the lower CVSS on the newest one. CVE-2026-5027 scores 8.8, below the three before it, yet it is the one VulnCheck flagged as actively exploited in June. Severity score and real-world risk are not the same number — a slightly "lower" bug that's trivially scriptable against thousands of exposed boxes is the one that gets hit.
CVE-2026-5027 affects every Langflow release up to and including 1.8.4. The fix landed in 1.9.0 on April 15, 2026, with langflow-base 0.8.3 patched in parallel. Version 1.10.0 (June 10, 2026) and later also carry the fix.
Step 1: Find Out What Version You're Running
Do this before anything else. You cannot decide whether you're exposed until you know your build.
# pip / uv install
langflow --version
# → Langflow version: 1.8.4 ← vulnerable, anything ≤ 1.8.4 is
# Docker
docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.version" }}' \
$(docker ps -qf "ancestor=langflowai/langflow")
# or just check the tag you pulled
docker images | grep langflow
If you pinned langflowai/langflow:latest, you do not actually know what you're running — latest drifts. Pin an explicit tag so the next person (probably you, in three months) can answer this question in one command.
Anything at or below 1.8.4 is vulnerable. Upgrade now.
Step 2: Patch
# pip
pip install --upgrade "langflow>=1.10.0"
# uv (the install method Langflow now recommends)
uv pip install --upgrade "langflow>=1.10.0"
# Docker
docker pull langflowai/langflow:1.10.0
# then update your compose file's image tag and recreate
docker compose up -d --force-recreate
After the upgrade, confirm:
langflow --version
# → Langflow version: 1.10.0
If you cannot upgrade immediately — a pinned dependency, a frozen prod image, a change-freeze window — the interim mitigation is to block reachability: take the instance off any public interface and put it behind authentication (Steps 3 and 4). The vulnerable endpoint is only dangerous if an attacker can reach it.
Step 3: Turn Off Auto-Login and Set a Real Superuser
Patching closes this CVE. Disabling auto-login closes the entire class — the next path-traversal or exec() bug is far less useful to an attacker who can't get a session token for free.
In your .env (or compose environment: block):
# Require real authentication. This is the single most important line here.
LANGFLOW_AUTO_LOGIN=False
# With AUTO_LOGIN off, set explicit superuser credentials —
# do NOT leave the insecure defaults in place.
LANGFLOW_SUPERUSER=admin
LANGFLOW_SUPERUSER_PASSWORD=use-a-long-random-passphrase-here
# A non-default secret key signs sessions and encrypts stored credentials.
# Generate one and keep it out of version control.
LANGFLOW_SECRET_KEY=$(python3 -c "import secrets; print(secrets.token_urlsafe(48))")
A real problem you'll hit: after flipping LANGFLOW_AUTO_LOGIN=False, existing flows created under the auto-login superuser may not show up until you log in as the superuser account you just defined. They aren't gone — they're scoped to a user, and the anonymous superuser you used before isn't the one you're now logging in as. Sign in with LANGFLOW_SUPERUSER, and re-assign or recreate ownership as needed. Set these variables before first boot on a fresh install to avoid the shuffle entirely.
Restart and verify the editor now demands a login instead of dropping you straight onto the canvas. If it still auto-signs you in, the variable didn't take — check for a stale .env, a compose override, or a shell export shadowing it.
Step 4: Get It Off the Public Internet
Langflow's default bind and port (7860) were never meant to face the open internet. Put a reverse proxy in front and firewall the rest.
Bind Langflow to localhost only:
langflow run --host 127.0.0.1 --port 7860
Then terminate TLS and enforce auth at nginx:
nginx
server {
listen 443 ssl;
server_name langflow.internal.example.com;
ssl_certificate /etc/letsencrypt/live/langflow.internal.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/langflow.internal.example.com/privkey.pem;
location / {
auth_basic "Langflow";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:7860;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade
Top comments (0)