Langflow CVE-2026-93680 and CVE-2026-110186: Two 9.8s, One Fix (1.13.0)

1. Context: Two Headline Bugs Inside a Much Larger Disclosure

The IBM security bulletin (published 28 October, updated 29 October) lists seven vulnerabilities: four in Langflow and three in its Hono dependency. The two that matter most are unauthenticated and critical. CVE-2026-93680 is improper authentication (CWE-287): a remote attacker can bypass security restrictions with no login. CVE-2026-110186 is improper control of code generation (CWE-94): a remote attacker can execute arbitrary code. Both carry the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network, low complexity, no privileges and no user interaction — so they score 9.8.

These two are the tip of a much bigger batch. IBM published its Langflow CVE records in three bulletins at once (one aggregator counts 33 CVE IDs in total): 16 fixed in 1.12.4, 14 fixed in 1.12.5, and this last set where four Langflow IDs — the two 9.8s plus an authenticated 8.8 Agentic Assistant command-execution bug (CVE-2026-110193) and a 6.5 credential-disclosure bug (CVE-2026-110192) — are fixed only in 1.13.0. Researcher Ostorlab reconstructs the no-login takeover from the 1.12.8 source: an unauthenticated GET /api/v1/auto_login hands out superuser session tokens whenever auto-login is on, and that session reaches Langflow’s MCP tools, where a custom component is Python that runs on the server. That is researcher analysis, not a vendor-published exploit.

How the batch breaks down (IBM bulletin 7294467)

Where things stand (checked 3 November 2026)

2. Five Implications for Teams That Run or Embed Langflow

IBM’s advisory gives the versions and the fix; Ostorlab’s write-up and the Metasploit wrap-up fill in how the no-login path actually works. Together they change how I would triage this.

Who is exposed, and what to do

What auto-login actually controls

On the “33 CVEs” figure and the confusing lines in the bulletin: the 33 count is the whole batch of IBM-assigned Langflow records across three bulletins, not this one, which lists seven. The “fixed in 4.13.5” line is the Hono dependency (CVE-2026-84363 / 84364 / 84365), not Langflow — Langflow’s bundled Hono is already 4.13.13 in both 1.12.8 and 1.13.0. The CWE-22 / 6.5 entry is the Hono build-time path traversal (CVE-2026-84365), and it does not conflict with the Langflow CWE-287 and CWE-94 ratings; they are different advisories inside one bulletin.

3. What to Do This Week

Same order as any runtime bug: find every reachable copy, upgrade the way each install demands, restart so the fix is real, and put mitigations in front of what you cannot upgrade today. Everything in step 1 only reads.

Step 1: Find every Langflow and read its version

# 1. The Python package: what is actually installed and running
pip show langflow langflow-base          # fixed line: 1.13.0 (both packages)
langflow --version                       # or: python -m langflow --version

# 2. A running server, over the documented version endpoint
curl -s http://127.0.0.1:7860/api/v1/version
#   {"version":"1.12.8","main_version":"1.12.8","package":"Langflow"} = affected

# 3. Docker: the tag the container really runs, not where :latest points today
docker ps --format '{{.Names}} {{.Image}}' | grep -i langflow
grep -rniE 'langflow(ai)?/langflow|openrag-langflow' --include='*.y*ml' .

# 4. Is auto-login on? That is the precondition for the unauthenticated path
docker exec <container> printenv LANGFLOW_AUTO_LOGIN   # unset or true on <=1.12.8

# Products that embed Langflow carry the flaw too. OpenRAG is the clearest case.
docker ps --format '{{.Names}} {{.Image}}' | grep -i 'openrag-langflow'
docker exec <openrag-langflow> python -m langflow --version   # 1.12.x = affected

# OpenRAG 0.8.1 builds its Langflow image on langflowai/langflow:base-1.12.x
# (base-1.12.3 in the 0.8.1 tag, base-1.12.8 on main) — inside the 1.0.0-1.12.8
# range — and its installer sets LANGFLOW_AUTO_LOGIN=true. Check what it exposes:
docker port <openrag-langflow> 7860      # 0.0.0.0:7860 = reachable off the host

Step 2: Upgrade per install type

A fix on disk does nothing for a process that loaded the old code, so each card ends in a restart or recreate. Before you start, back up the database, the configuration directory and the secret key — 1.13.0 also moves local knowledge bases from Chroma to SQLite on first start, and a misconfigured Docker upgrade can lose data.

pip install --upgrade "langflow==1.13.0"
uv pip install --upgrade "langflow==1.13.0"   # if you use uv
langflow --version                             # 1.13.0

docker pull langflowai/langflow:1.13.0
docker buildx imagetools inspect langflowai/langflow:1.13.0 | grep -m1 Digest
#   image: langflowai/langflow:1.13.0@sha256:<digest>
docker compose pull && docker compose up -d --force-recreate
docker compose exec app curl -s http://127.0.0.1:7860/api/v1/version

LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER=<existing-username>     # default: langflow
LANGFLOW_SUPERUSER_PASSWORD=<strong-password>
LANGFLOW_SECRET_KEY=<keep the same key so stored flows decrypt>

Step 3: Mitigate what you can’t upgrade today

IBM offers no workaround and says 1.13.0 is the fix. What you can do is remove the preconditions: keep untrusted callers off the server, and turn off the setting that hands out sessions.

# Do not publish Langflow to every interface. Bind it to localhost and put an
# authenticating reverse proxy in front (Langflow's own guidance).
docker run -p 127.0.0.1:7860:7860 ...    # NOT -p 7860:7860, which binds 0.0.0.0

# Docker publishes ports to all addresses by default and bypasses the host ufw
# rules for them, so pin the bind address instead of trusting the firewall.

# Close the documented unauthenticated path: turn auto-login off and require a password.
# 1.13.0 does exactly this by default; on 1.12.x you set it yourself.
LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER=<existing-username>    # default: langflow
LANGFLOW_SUPERUSER_PASSWORD=<strong-password>   # startup fails closed without it
LANGFLOW_ENABLE_SUPERUSER_CLI=false       # recommended by the docs
LANGFLOW_SECRET_KEY=<your-own-32-byte-key>

# If the instance was ever exposed, rotate the key AND re-encrypt the secrets it
# protected (global variables, component API keys, stored credentials):
uv run python scripts/migrate_secret_key.py --dry-run
uv run python scripts/migrate_secret_key.py

Conclusion

Two unauthenticated 9.8s in a code-execution platform is close to the worst case for a web application, and the twist here is reach: Langflow is not only a thing you self-host, it is the engine inside OpenRAG and other RAG products, and all of them sit in the 1.0.0–1.12.8 range until they rebase on 1.13.0.

The good news is that the fix is clean and the mitigations are concrete. Upgrade to 1.13.0, which turns auto-login off by default; where you can’t upgrade yet, turn auto-login off yourself, keep the server off the public internet behind an authenticating proxy, and rotate any secrets it held while it was exposed. The CVEs aren’t in CISA KEV today, but Langflow’s history says that window can close fast.

Sources

• IBM — Security Bulletin: Langflow OSS is affected by multiple vulnerabilities (7294467)
• CVE.org — CVE-2026-93680 record (authentication bypass, CVSS 3.1 9.8)
• CVE.org — CVE-2026-110186 record (code injection → RCE, CVSS 3.1 9.8)
• Langflow — v1.13.0 release notes (auto-login disabled by default)
• Langflow docs — API keys and authentication (AUTO_LOGIN, superuser, secret key)
• Rapid7 — Metasploit wrap-up: Langflow, MongoDB and more (auth-bypass module)
• Ostorlab — Langflow auto-login auth bypass (CVE-2026-93680) analysis
• The Hacker News — Critical Langflow flaws could let attackers run code
• GBHackers — Critical Langflow AI vulnerabilities allow unauthenticated RCE
• CISA — Known Exploited Vulnerabilities catalog