Langflow Security Hardening 2026: Patch CVE-2026-5027

By AIFoss · 10 min read
langflowsecurityselfhostedcveai

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.

CVECVSSRoot causeFixed in
CVE-2025-32489.8/api/v1/validate/code ran exec() on unauthenticated input (Flodrix botnet)1.3.0
CVE-2025-342919.4Account takeover + RCE via malicious page (linked to MuddyWater)1.5.x
CVE-2026-330179.3/api/v1/build_public_tmp executed Python in node definitions1.9.0
CVE-2026-50278.8/api/v2/files path traversal → arbitrary file write → RCE1.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:

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    $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Block the app port from outside, so nobody bypasses the proxy:

sudo ufw default deny incoming
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw deny 7860/tcp
sudo ufw enable
sudo ufw status numbered

This is the same playbook that closes exposed-instance risk for any local AI service. If you’re running Ollama or Open WebUI on the same box, the Ollama security hardening guide walks through the identical binding-and-proxy pattern for port 11434 — worth doing in the same sitting.

Step 5: Audit — Were You Already Hit?

If your instance was internet-facing on a vulnerable build, treat it as compromised until proven otherwise. The traversal writes files, so look for files you didn’t write.

# Recently modified files under the Langflow data dir and home — last 7 days
find ~/.cache/langflow / -xdev -mtime -7 -type f 2>/dev/null \
  | grep -vE '^/(proc|sys|run)' | head -50

# Cron is the classic post-traversal RCE vector — inspect every cron path
cat /etc/crontab; ls -la /etc/cron.* /var/spool/cron/crontabs/ 2>/dev/null

# Unexpected outbound connections from the Langflow process
sudo ss -tanp | grep -i langflow

If you find anything you can’t account for, assume credential theft. Rotate everything the instance could see: the .env contents, the Langflow database credentials, any API keys stored in flows (OpenAI, Anthropic, cloud provider keys), and any secrets the host had access to. VulnCheck and Sysdig both flag secret and .env exfiltration as the immediate post-exploitation goal on these Langflow bugs.

When NOT to Self-Host Langflow on the Open Internet

Langflow is a genuinely good builder, but be honest about the threat model. Do not expose it directly to the internet if any of these are true:

  • You can’t commit to patching within days of disclosure. Langflow’s exploitation-to-patch window has repeatedly been measured in hours, not weeks. If your ops cadence is monthly, a public Langflow is a liability between cycles.
  • It holds production API keys or touches sensitive data. The post-exploitation payoff is secret theft. Keep those flows on an internal-only instance behind a VPN.
  • It’s an unmonitored side project. The exposed instances getting hit are mostly the ones nobody is watching. If you won’t see the alert, don’t open the port.

For a throwaway prototype on 127.0.0.1 behind a VPN, Langflow is fine. As a multi-tenant service on a public IP, it needs the full treatment above — and even then, a managed offering may be the saner choice. If you’re choosing a workflow builder partly because of the security posture, the trade-offs against the alternatives are covered in Flowise vs n8n vs LangGraph, and the broader supply-chain picture for open-source AI is in the OSSRA security wake-up call.

FAQ

Is CVE-2026-5027 fixed if I’m on Langflow 1.9.0? Yes. The path-traversal write was patched in 1.9.0 (April 15, 2026) and langflow-base 0.8.3. 1.10.0 and later also carry the fix. Anything ≤ 1.8.4 is vulnerable.

Does disabling AUTO_LOGIN alone protect me? It removes the free-session-token problem and makes the endpoint much harder to reach unauthenticated, which is a strong mitigation. But it is not a substitute for patching — apply the upgrade and disable auto-login. Defense in depth, not either/or.

I run Langflow only on localhost. Am I affected? Your exposure is far lower because an external attacker can’t reach the endpoint. Patch anyway — a local-only bug still matters if anything else on the box is reachable, and “localhost only” has a habit of quietly becoming 0.0.0.0 after someone debugs a connection issue.

How do I know if my instance was exploited? Look for files modified in the last several days outside the upload directory, unexpected cron entries, and unusual outbound connections (Step 5). If you find any, rotate every credential the instance could access.

Is this the same as the older Langflow RCE from 2025? No — CVE-2025-3248 was an exec() flaw in /api/v1/validate/code, fixed in 1.3.0. CVE-2026-5027 is a separate path-traversal bug in the file-upload endpoint. Same lesson, different door.

Sources

Was this article helpful?