Brief · Builders

Langflow again: two more no-login holes, and the only fix is 1.13.0

By alkizz · Nov 2, 2026

If you run Langflow anywhere other people can reach, it's upgrade week again. IBM, which handles Langflow's vulnerability reports, published a bulletin on Oct 28 with four new Langflow CVEs, plus three for Hono, a JavaScript library its frontend uses in development. Two of them, CVE-2026-93680 and CVE-2026-110186, are rated 9.8 and need no account at all. Every Langflow from 1.0.0 through 1.12.8 is affected, the only fix is 1.13.0, and the bulletin's workaround section says, in full, "None."

I covered Langflow's settings-page shell in October. That one needed a login, at least on paper. These two don't.

What IBM published

The bulletin (first published Oct 28, updated Oct 29) lists four Langflow CVEs, all scored by IBM:

• CVE-2026-93680, 9.8: "bypass security restrictions due to improper authentication." No account needed.
• CVE-2026-110186, 9.8: "execute arbitrary code due to improper control of code generation." No account needed.
• CVE-2026-110193, 8.8: someone with "a low-privileged authenticated account" can get the Agentic Assistant to write or submit component code that ends in "arbitrary operating system command execution on the server."
• CVE-2026-110192, 6.5: a logged-in attacker can "obtain sensitive information due to insufficiently protected credentials."

The per-CVE descriptions are thin. The bulletin's summary is more useful: it mentions "an incomplete remediation of an auto-login security control" and "unauthenticated remote code execution exploitable through model context protocol tool enumeration." IBM's per-CVE lines make 93680 the auth bypass and 110186 the code execution, but IBM doesn't say which summary line belongs to which CVE, and neither do NVD, GitHub's advisory records or the Langflow fixes I checked.

NVD has all four records (published Oct 29) and marks everything from 1.0.0 up to, but not including, 1.13.0 as vulnerable.

There's already a Metasploit module

This is the part that moves it from "patch soon" to "patch now." A Metasploit module that cites CVE-2026-93680 was merged on Oct 8, three weeks before the bulletin. It connects to Langflow's MCP endpoint (/api/v1/mcp/sse) without credentials, opens an MCP session, asks for tools/list, and saves whatever comes back.

To be fair to the module, it's a looker, not a doer. It doesn't run code or commands on the server; it collects what your Langflow exposes as MCP tools. But those tools are your flows, and a list of them is a map for whoever comes next. Its author lists 1.5.0 through 1.11.4 as affected, narrower than IBM's range, and the docs say it was tested on Langflow 1.8.4 in Docker, with setup steps that start the container with LANGFLOW_AUTO_LOGIN=true. In Langflow's code, that exact request has been refused since 1.11.5 and 1.12.0, which require credentials on the MCP endpoints even with auto-login on, so the module as written shouldn't work on a default 1.12.x. IBM still lists 1.12.x as affected without saying how.

That setting keeps coming up. Auto-login signs everyone in as the superuser, and in the 1.12.8 source it still defaults to True, with Langflow's own warning that it "bypasses authentication and should only be used in development environments." The bulletin doesn't say whether servers with auto-login turned off are vulnerable, and I couldn't find anything else that does.

Exploited yet?

Not that anyone has reported. Neither CVE was in CISA's Known Exploited Vulnerabilities catalog as of its Oct 30 release, which was still the latest when I checked this morning. Six older Langflow bugs are in there, most recently CVE-2026-9198, added Aug 4. Langflow has a habit of ending up in that catalog, so I wouldn't read much into the gap.

1.13.0, and only 1.13.0

Langflow 1.13.0 came out Oct 22. So did 1.12.8, about four hours earlier, and 1.12.8 is still affected. PyPI shows 1.13.0 as the latest release this morning; the only 1.13.1 builds are release candidates.

The upgrade has one trap. Langflow 1.13 turns auto-login off by default, so if your instance has been signing you in automatically, it may stop letting you in after the upgrade. Langflow's upgrade guidance says to set a password on the existing account before you upgrade, and it's blunt about the panic move: "Do not delete the existing account, database, or encryption key to regain access." The install page adds that deleting or reinstalling "can permanently remove your flows."

One more line from the same guidance matters for cleanup: "Disabling auto-login prevents new anonymous sessions; it does not revoke previously issued sessions or API keys." Upgrading closes the door, as long as nothing in your setup turns auto-login back on. It doesn't change the locks.

If you skipped 1.12.4 and 1.12.5, 1.13.0 also gets you past their fixes. Per The Hacker News, IBM also published CVE records for 29 other Langflow flaws on Oct 29, fixed in 1.12.4 and 1.12.5. One of them, CVE-2026-104339, is another 9.8 that NVD lists for 1.0.0 through 1.12.3, with no account needed.

What to do:

• Upgrade to Langflow 1.13.0.

  • Why: IBM lists 1.0.0 through 1.12.8 as affected and 1.13.0 as the fix, and the bulletin's workaround section says "None." Anything from 1.0.0 to 1.12.8 is exposed to all four CVEs, whatever fix you took for earlier Langflow bugs.
  • How: back up the database, the secret key and uploaded files first, as IBM says. Then pip install --upgrade "langflow==1.13.0", or move Docker to langflowai/langflow:1.13.0 and keep your persistent data, per the bulletin.

• Set a password before the upgrade turns auto-login off.

  • Why: 1.13 disables auto-login by default, and an instance that has only ever signed you in automatically can lock you out of the account that owns your flows.
  • How: follow Langflow's "Upgrade an existing auto-login installation" steps: set and test a password on the existing account, then set LANGFLOW_AUTO_LOGIN=false, LANGFLOW_SUPERUSER and LANGFLOW_SUPERUSER_PASSWORD. If an old .env or container setting still says LANGFLOW_AUTO_LOGIN=true, it overrides the new default and 1.13.0 keeps handing a superuser session to anyone who can reach it, so remove it. If you're already locked out, use the docs' "Recover access after upgrading" steps, not a reinstall.

• Get it off the open internet until it's upgraded.

  • Why: IBM lists no workaround, and the auth bypass has a public Metasploit module that needs no password against versions through 1.11.4.
  • How: my suggestion, not IBM's: put the instance behind a VPN or an authenticating proxy, or firewall port 7860 to the people who need it. The official Docker image listens on 0.0.0.0, and Docker's published ports skip ufw rules, so publish it as -p 127.0.0.1:7860:7860 instead. My builders checklist makes the same point about model servers.

• If you can't upgrade today, turn auto-login off.

  • Why: Langflow's docs say auto-login "lets anyone who can reach the server act as the superuser," and IBM's summary ties these bugs to "an auto-login security control." This is my suggestion, not a vendor workaround, so it narrows the risk until you're on 1.13.0 rather than fixing it.
  • How: on 1.12.x, set and test a password on the existing account first, then set LANGFLOW_AUTO_LOGIN=false, LANGFLOW_SUPERUSER and LANGFLOW_SUPERUSER_PASSWORD and restart. If no MCP client uses the older SSE transport, also set LANGFLOW_MCP_SSE_ENABLED=false to turn off the SSE endpoints; Streamable HTTP keeps working. Versions before 1.12.0 don't have that setting and ignore it.

• Rotate what the old version could see.

  • Why: per Langflow's docs, turning auto-login off doesn't revoke sessions or API keys issued before, and 110192 is about exposed credentials.
  • How: after upgrading, revoke and reissue Langflow API keys, change the superuser password, and rotate the provider keys and tokens your flows use, starting with anything stored in Langflow.

• Check whether anyone looked around.

  • Why: the Metasploit module only reads, but it leaves a trace, and a list of your MCP tools is what an attacker would want before trying something worse.
  • How: search your proxy logs first (Langflow itself logs only errors to stdout by default) for requests from addresses you don't know to /api/v1/mcp/sse, /api/v1/mcp/, /api/v1/mcp/streamable, /api/v1/mcp/project/, the /api/mcp/ alias and /api/v1/auto_login. If you find them, save the logs before you upgrade or rebuild, and treat the instance's secrets as exposed.

Sources

• IBM: Security Bulletin, Langflow OSS is affected by multiple vulnerabilities (Oct 28, 2026, updated Oct 29)
• The Hacker News: Critical Langflow Flaws Could Let Unauthenticated Attackers Run Code on Servers (Nov 2, 2026)
• NVD: CVE-2026-93680
• NVD: CVE-2026-110186
• NVD: CVE-2026-110193
• NVD: CVE-2026-110192
• NVD: CVE-2026-104339
• Metasploit: langflow_auth_bypass_cve_2026_93680 module
• Metasploit pull request #21942 (merged Oct 8, 2026)
• Metasploit module documentation
• CISA: Known Exploited Vulnerabilities catalog
• Langflow 1.13.0 release (Oct 22, 2026)
• PyPI: langflow
• Langflow source: AUTO_LOGIN default (v1.12.8)
• Langflow pull request #14643: require credentials on the MCP endpoints under AUTO_LOGIN (merged Aug 19, 2026)
• Langflow docs: API keys and authentication
• Langflow docs: Install Langflow
• Langflow docs: Logs
• Docker docs: Port publishing and mapping
• Docker docs: Packet filtering and firewalls

← All briefs