CVE-2026-93680

What CVE-2026-93680 is. IBM describes it as improper authentication (CWE-287) that could allow a remote attacker to bypass security restrictions. Rapid7's module page adds that affected versions "allow unauthenticated connections to the MCP SSE endpoint, allowing attackers to initialize MCP sessions and retrieve privileged MCP-related information." The module's source shows the exact requests. GET /api/v1/mcp/sse to open the session, then POST /api/v1/mcp/?session_id=<id> for MCP calls, default port 7860. It saves what it collects as a JSON document. Rapid7 lists a disclosure date of September 22, 2026 and credits Richard Howe.

What CVE-2026-110186 is. A code injection flaw (CWE-94). IBM's vulnerability entry says it "could allow a remote attacker to execute arbitrary code due to improper control of code generation," and the bulletin summary describes it as "unauthenticated remote code execution exploitable through model context protocol tool enumeration." Its CVSS vector requires no privileges and no user interaction. IBM does not say that CVE-2026-110186 depends on CVE-2026-93680, so treat them as two separate flaws that both sit on Langflow's MCP interface. One check matters for both. If your MCP endpoints answer anonymous requests from untrusted networks, assume both are in play until you upgrade. No public exploit for CVE-2026-110186 was found as of this writing.

Companion. The same 1.13.0 upgrade also fixes CVE-2026-110193 (8.8), which IBM says lets a low-privileged logged-in user get the Agentic Assistant to produce component code that runs operating system commands on the server.

Two kinds of MCP endpoint. Langflow's docs describe per-project MCP servers at /api/v1/mcp/project/<project-id>/streamable, each with its own auth setting (API key, OAuth, or None), plus a legacy SSE transport. The Metasploit module hits /api/v1/mcp/sse, not a project path. A server that refuses the module's path can still have a project server set to None, which the docs themselves call a public endpoint anyone can reach without credentials. Check both.

Checks, in order. Run these only on Langflow servers your organization owns. None of them initializes an MCP session or calls a tool.

1. Version. Run pip show langflow in the Langflow environment, or check the image tag of your container. Anything from 1.0.0 through 1.12.8 is affected.
2. Network exposure. Langflow listens on port 7860 by default (LANGFLOW_PORT). From outside your network, test whether 7860 or the reverse proxy in front of Langflow answers. A proxy that forwards everything under /api/ to Langflow exposes the MCP paths too.
3. Does the legacy SSE endpoint answer without a session? From a host without Langflow credentials, run curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 https://YOUR-HOST/api/v1/mcp/sse. A 401 or 403 means the endpoint wants credentials; a 200 that holds the connection open means it accepts anonymous SSE connections; a 404 means the legacy transport is off. This only opens and closes a connection.
4. Review each project's MCP auth setting. In Langflow, open each project's MCP Server tab and check Edit Auth. Any project set to None is reachable without credentials at its streamable path regardless of the check above. Per the docs, with LANGFLOW_AUTO_LOGIN=false new projects default to API key auth; older projects may not.
5. Auto-login and default credentials. Check whether LANGFLOW_AUTO_LOGIN is true. Langflow's docs say that with auto-login on, the visual editor signs every user in as the superuser, and that official packages and Docker images now default it to false. Also check LANGFLOW_SKIP_AUTH_AUTO_LOGIN, and confirm LANGFLOW_SUPERUSER_PASSWORD is set to a strong value rather than a sample such as the "adminpass" in the docs' example .env. The default superuser username is langflow.
6. Blast radius. List what the Langflow process can reach. API keys stored in global variables or the environment, the flows themselves, the Langflow database, and any databases, vector stores or internal services the flows connect to. Code running as Langflow can reach all of it.

Upgrading to 1.13.0 is the only fix IBM names. Use these to cover the gap, and test each one on the server where it matters.

• Restrict network access. Allow port 7860, and the proxy in front of it, only from the networks and hosts that need Langflow. Then rerun the external check to confirm.
• Block or authenticate the MCP paths at the proxy. Deny /api/v1/mcp/ requests that don't come from trusted clients, or require proxy-level authentication for them. Rerun the curl check to confirm the proxy returns 401, 403 or 404. This also covers the per-project streamable paths, which sit under the same prefix.
• Set every project's MCP auth to API key or OAuth. Remove None wherever it is set, and rotate any project API keys that may have been exposed.
• Disable the legacy SSE transport if your version supports it. Langflow's current MCP server docs say LANGFLOW_MCP_SSE_ENABLED=false returns 404 from the legacy SSE transport and its message endpoint, while Streamable HTTP is unaffected. The docs don't say which versions include the setting or whether it blocks CVE-2026-110186, so confirm the 404 yourself and still upgrade.
• Turn off auto-login. LANGFLOW_AUTO_LOGIN=false is the baseline Langflow's docs recommend. It does not close CVE-2026-93680, which is an authentication bypass.

• GET requests to /api/v1/mcp/sse followed by POSTs to /api/v1/mcp/?session_id= from clients that don't normally use MCP, especially from outside your network. That is the module's exact sequence.
• MCP tool-list or tool-call requests against project paths from sources that hold no API key.
• Shells or unexpected child processes spawned by the Langflow process, and outbound connections from the Langflow host to unfamiliar addresses.
• New or changed flows and components you don't recognize.

Can someone run code on my Langflow server without logging in?

On 1.0.0 through 1.12.8, IBM rates CVE-2026-110186 as unauthenticated remote code execution through MCP tool enumeration. If the server is reachable, assume yes until you upgrade to 1.13.0.

Is CVE-2026-93680 being exploited?

No exploitation has been reported as of October 29, 2026, and it is not in CISA's KEV catalog. A public Metasploit module exists, which lowers the bar for anyone who wants to try.

Is this the Langflow vulnerability on the CISA KEV list?

No. The well-known KEV entry is CVE-2025-3248, added May 5, 2025, and Langflow has several other KEV entries since. CVE-2026-93680 and CVE-2026-110186 are newer and not in KEV.

Does turning off auto-login protect me?

Not on its own. Langflow's docs recommend LANGFLOW_AUTO_LOGIN=false as baseline hardening, but CVE-2026-93680 is an authentication bypass, so upgrade and restrict access regardless.

Which Langflow version fixes CVE-2026-93680?

1.13.0. It also fixes CVE-2026-110186 and CVE-2026-110193.

Oct 29, 2026. First published. No exploitation reported; not on CISA KEV; public Metasploit module for CVE-2026-93680.

• IBM Security Bulletin, Langflow OSS multiple vulnerabilities (Oct 28, 2026)
• Rapid7 module page, Langflow AI Authentication Bypass and module source (endpoint paths and port; read only, not run)
• NIST NVD: CVE-2026-93680, CVE-2026-110186, CVE-2026-110193
• CISA Known Exploited Vulnerabilities catalog (checked catalog version 2026.10.28)
• Langflow docs: MCP server, API keys and authentication, environment variables