Langflow's 33 CVE records are three IBM bulletins, and the 1.13.0 one pairs none of its 4 themes with an ID

Thirty three records on one afternoon, and four IDs in the bulletin that names 1.13.0

IBM, acting as the CVE Numbering Authority, published 33 Langflow CVE records on 29 October 2026 between 15:14 and 15:19 UTC (derived from the datePublished field of each record). Those 33 sit in three IBM security bulletins: 16 in a bulletin whose fix is Langflow 1.12.4, 13 in one whose fix is 1.12.5, and 4 in the bulletin whose fix is 1.13.0 (derived: 16 + 13 + 4). So a reading of "33 CVEs fixed in 1.13.0" would fold three bulletins into one and attach the newest version to all of them.

The bulletin that does name 1.13.0 prints a summary with four themes and a table with four Langflow CVE IDs. It does not say which ID goes with which theme. The summary names "an incomplete remediation of an auto-login security control", "agentic code execution via a third-party library", "operator-injected API key exposure reachable without intended authorization" and "unauthenticated remote code execution exploitable through model context protocol tool enumeration". The record text for CVE-2026-93680 says "improper authentication" and does not mention auto login. The record text for CVE-2026-110186 says "improper control of code generation" and does not mention the Model Context Protocol (MCP). The pairing that circulates comes from a security vendor's blog post, not from IBM.

What this does not establish: that anything is exploited, how many servers are exposed, or whether a server with auto login switched off is affected by the two 9.8 records. Nothing read here states exploitation of any of the 33. This briefing was built from IBM's four Langflow bulletins, the CVE.org records, the Langflow project's own releases, source and documentation, and the CISA catalogue, read between 15:46 and 16:10 GMT on Monday 2 November 2026. The Hacker News article that prompted the story answered the request with a bot check page, which was not bypassed, so only the first lines of it that the site's own feed prints were read.

Stated and not stated

The table separates what a primary prints from what a reader has to supply. "Not stated" means the pages read are silent, not that the answer is no.

IBM's four themes and four IDs, side by side

The diagram sets IBM's summary beside the records. The left column is IBM's wording, the middle is the record text and score, the right says who makes the pairing. IBM's table lists the IDs in the order 93680, 110193, 110186, 110192, while its summary lists the themes in a different order, so position does not pair them either.

Zoom

Two things in that table matter. First, "unauthenticated" appears in IBM's summary, but the vector for 93680 and 110186 only says no privileges are required, which is not the same as no account: a default session handed out by a setting is a session. Second, the summary calls the API key theme "reachable without intended authorization" while the record text for 110192 says "authenticated". Both could be true of different parts of the same flaw. The pages do not say.

What the 33 are: three bulletins, six critical, and two bulletins that are not about 1.13.0

The CVE.org records say the 33 were published together, but they cite three different bulletins. The table lists them. The IDs for the two earlier bulletins were read from the bulletin pages and matched to the records (the 29 October set equals the union, minus three Hono IDs and minus one record published earlier).

Three consequences follow, each derived. A server on 1.12.5 to 1.12.8 is outside the printed ranges of the other 29 but inside the range of the four. A server on 1.12.3 or earlier is inside the range of all 33. And 1.13.0 is the only fixed version IBM names for the four. The bulletins do not say whether 1.13.0 repeats the earlier fixes; that is the normal expectation of a later release, not a printed statement.

Reading the vectors, six of the 33 need no privileges: 93680, 110186 and 104339 at 9.8, plus 104317 (8.1, reaches a message broker), 110245 (7.5) and 18894 (6.5). Nine carry CWE-94 code injection. Whether several share a root cause is not stated; the descriptions differ, so the count is of records, not of separate bugs. The Hacker News feed describes "two critical flaws", which is the 1.13.0 bulletin's pair; across the 33 the CNA rates six as critical. "Critical" in all of this is IBM's rating, not a finding by CISA or by the project.

Outside the count: in an NVD keyword search for Langflow, 24 further IBM records were published on 7 October for versions through 1.12.2, and IBM's July bulletin on MCP features listed seven more for 1.0.0 through 1.10.3, fixed in 1.11.0. Those are separate bulletins and are not part of the 33.

Fix first, bulletin later, records last

The fix date comes before the write up date, and the gaps are large. Langflow's release data gives 1.12.4 on 29 September, 1.12.5 on 6 October, 1.12.8 on 22 October at 17:08 UTC and 1.13.0 the same day at 21:20 UTC, 4 hours 12 minutes later (derived). IBM's two earlier bulletins are dated 19 October, 20 and 13 days after those fixes. The 1.13.0 bulletin is dated 28 October, 6 days after the release. All 33 records appeared on 29 October: 30 days after 1.12.4, 23 days after 1.12.5 and 7 days after 1.13.0 (all derived). The Hacker News feed item is stamped 2 November, 11 days after 1.13.0.

Zoom

Two earlier dates sit in public and predate the bulletin. The project's pull request that turns auto login off in official release artifacts was opened on 8 September and merged into the 1.13.0 branch on 29 September, 50 and 29 days before the bulletin (derived). A Metasploit pull request titled with CVE-2026-93680 was opened on 22 September, four days after the CVE.org record says the ID was reserved, and merged on 8 October, 36 and 20 days before the 1.13.0 bulletin (derived). What this does not establish: that the pull requests were written about the flaw IBM later scored, or that IBM's text was written with them in view. They show only that the ID and the default change were public before the bulletin.

Who is exposed, as the project states it

The project's source at 1.12.8 sets the auto login field to on, with its own description saying: "SECURITY WARNING: This bypasses authentication and should only be used in development environments." and "Set to False in production." Its documentation for 1.13 says what that means: "Automatic login lets anyone who can reach the server act as the superuser." So on a default install of any release through 1.12.8, the project's own text describes a superuser session available to anyone with a network route to the port. That is the project's statement about the setting, not a statement that any of the four records is that flaw.

The MCP side is stated less simply. The documentation lists the MCP server as enabled by default ("Whether to initialize an MCP server for each of your Langflow projects.") and warns that "When no authentication is configured, your MCP server becomes a public endpoint that anyone can access without providing credentials." The source for the route that Ostorlab names, the agentic MCP route, describes that route as authenticating the caller: tool calls run with "the caller's own credentials (taken from the authenticated request)", and the tool that reaches the assistant's code generating endpoints is excluded unless a setting is on. So the sources describe more than one MCP surface. IBM's bulletin names none of them, and the Metasploit documentation describes a different one again, a legacy SSE endpoint.

Zoom

What 1.13.0 changes, per the project: "Official Python packages, tagged source archives, and Docker images now set LANGFLOW_AUTO_LOGIN=false." Two cautions from the documentation matter in practice. An explicit setting wins: "An explicit LANGFLOW_AUTO_LOGIN=true in an existing environment or .env file takes precedence over the new default." And a lock out is possible: the docs say "Before installing a release that disables auto-login, prepare the existing account for password sign-in" and describe how to recover if that is skipped. The project also states that "Disabling auto-login prevents new anonymous sessions; it does not revoke previously issued sessions or API keys." Nothing read gives a default listen address for the Python package, a count of public instances, or a count of instances still on auto login.

Three third party readings, and where they disagree

Ostorlab, a security testing vendor whose post ends with an offer to run its scan, published on 30 October. It pairs 93680 with an auto login flaw and 110186 with code execution through the MCP tools, and describes a chain: an anonymous request for a superuser session, then the MCP tools, then a flow with a custom component that runs on the server. It states: "No exploitation of these CVEs has been reported, and none is in CISA's exploited-vulnerabilities catalog as of October 30, 2026." It also states: "No public proof of concept exists for any of the October 2026 CVEs." It says the agentic MCP routes "authenticate the caller" and that the unauthenticated part is the auto login endpoint. The post says its steps are reconstructed from IBM's bulletin, the descriptions and the 1.12.8 source, not from an exploit. IBM's bulletin and records do not carry its mapping.

A Metasploit module exists with CVE-2026-93680 in its name. The framework's pull request was opened on 22 September and merged on 8 October. Its documentation says "Langflow versions 1.5.0 through 1.11.4 allow unauthenticated connections to the MCP SSE endpoint, allowing attackers to initialize MCP sessions and retrieve privileged MCP-related information." It was tested on Langflow 1.8.4 in a container with auto login explicitly on, and the sample run in the documentation reports zero tools found. So the module, as described, connects and gathers MCP metadata; it is not described as running code. Its range (1.5.0 to 1.11.4) differs from IBM's (1.0.0 to 1.12.8), and it points at a different endpoint from the one Ostorlab names. That is a conflict between two third party readings of one ID, and Ostorlab's "no public proof of concept" sits uneasily with a public module of that name; the definitions of the two may differ. No code from the module is reproduced here.

The Hacker News published on 2 November (11:50 UTC by its feed stamp). The article page itself was behind a bot check. The feed prints only its opening: "Two critical flaws in Langflow could let a remote attacker with no account bypass authentication or run arbitrary code, IBM said last week." Nothing in this briefing rests on any other part of the article.

Exploitation evidence: none stated for these CVEs, and a long record for earlier ones

CISA's Vulnrichment entries (the CISA ADP block in each record, SSVC version 2.0.3) exist for 22 of the 33 records and every one says Exploitation "none". Four of those 22 are marked Automatable "yes": 93680, 110186, 104339 and 18894. CISA assessed 110193 as Automatable "no" and Technical Impact "total". The other 11 records, including 110192, carry no CISA block when read. A "none" is an assessment at the time of the block (the ones for 93680 and 110186 are stamped 30 October), not a promise.

The CISA Known Exploited Vulnerabilities catalogue, version 2026.10.30 (the version the CISA feed served at about 15:50 GMT on 2 November), lists none of the 33. It does list six earlier Langflow entries, so the product's history is the reason for the urgency, not these CVEs.

The project's own published GitHub security advisories (37 returned, the latest published 28 September) carry none of the 33 IDs. A different Langflow flaw set, with honeypot counts, is covered in an earlier briefing, which concerns a different CVE and a fix in 1.9.0.

What the record does not establish: that these CVEs are unexploited. Absence from KEV and a CISA "none" mean no listing and no assessed exploitation on the date read.

A ranked checklist

Technical details

The primaries publish no indicators of compromise, no log lines, no detection rule and no payload for these CVEs, and this briefing adds none. What they do publish is versions, a vector per record, a configuration default, and the fix. Each block below is copied from the page named in its caption. Nothing here is an exploit or a step by step attack.

IBM's summary and its remediation, as printed on the 1.13.0 bulletin. This is the text the whole mapping question rests on. A defender uses the version line to find affected servers and the last line to understand that there is no interim control.

Issues include an incomplete remediation of an auto-login security control, agentic code execution via a third-party library, operator-injected API key exposure reachable without intended authorization, and unauthenticated remote code execution exploitable through model context protocol tool enumeration.

Langflow OSS | 1.0.0 - 1.12.8 |

IBM strongly recommends addressing these vulnerabilities now by upgrading Langflow OSS installations running versions 1.0.0 - 1.12.8 to Langflow OSS 1.13.0.
Python package: install Langflow 1.13.0 from PyPI with pip install --upgrade "langflow==1.13.0", following the installation instructions.
Docker: use langflowai/langflow:1.13.0 and follow the Docker upgrade instructions to pull the image and restart the deployment while preserving its persistent data.
Before upgrading, back up the database, secret key, and uploaded files. If the deployment uses automatic login, prepare the existing account for password sign-in as described in the installation and Docker upgrade instructions. These preparation steps accompany the product upgrade; no separate interim workaround is provided.

Workarounds and Mitigations
None

Change History
29 Oct 2026: Updated summary, clarified fixed-version remediation and installation instructions, and corrected taxonomy version formatting.
28 Oct 2026: Initial Publication

The CVSS 3.1 vectors that IBM assigned to the four records, from the CVE.org records. They are here, and not in the table, because a vector is a long unbroken string. The two 9.8 records have the same vector; read PR:N as no privileges required, PR:L as low privileges.

CVE-2026-93680  9.8  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2026-110193  8.8  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2026-110186  9.8  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2026-110192  6.5  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

The setting at the centre of the story, in the project's own source. The first block is the field at the 1.12.8 tag, the second at the 1.13.0 tag. A defender checks the environment and any .env file for an explicit override, because an explicit value beats either default.

AUTO_LOGIN: bool = Field(
    default=True,  # TODO: Set to False in v2.0
    description=(
        "Enable automatic login with a configured or generated bootstrap account. "
        "SECURITY WARNING: This bypasses authentication and should only be used in development environments. "
        "Set to False in production. This will default to False in v2.0."
    ),
)

AUTO_LOGIN: bool = Field(
    default=False,  # TODO: Set the development default to False in v2.0.
    description=(
        "Enable automatic login with a configured or generated bootstrap account. "
        "SECURITY WARNING: This bypasses authentication and should only be used in development environments. "
        "Enabled by default on development branches; official release packages and tags default to False. "
        "Set LANGFLOW_AUTO_LOGIN=false to require authentication. "
        "Planned to default to False for all installations in v2.0, requiring an explicit "
        "LANGFLOW_AUTO_LOGIN=true to enable automatic login."
    ),
)

The project's documentation for 1.13 gives the configuration for an instance that requires sign in. These two lines are its example; the password value is the documentation's own placeholder and is not a credential.

LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER_PASSWORD=REPLACE_WITH_A_STRONG_PASSWORD

Automatic login lets anyone who can reach the server act as the superuser.
An explicit LANGFLOW_AUTO_LOGIN=true in an existing environment or .env file takes precedence over the new default.
Disabling auto-login prevents new anonymous sessions; it does not revoke previously issued sessions or API keys.

Lines from the 1.13.0 release notes on the project's repository that relate to the themes in IBM's summary. The project does not label them with CVE IDs. The author and pull request suffix on each line is omitted here; the pairing of any line with a CVE is not stated by the project or by IBM.

* fix: disable automatic login by default
* fix(auth): keep the default superuser's data when AUTO_LOGIN is turned off
* fix(cli): warn when the default superuser has signed in and AUTO_LOGIN is on
* fix: block unsafe module reexports in assistant code scanning
* fix: preserve caller credentials in agentic MCP requests
* fix(api-key): consult a deployment policy wherever a key is minted
* fix: guide recovery after upgrading from an auto-login installation
* docs: auto_login is false by default

A separate IBM bulletin, for fixes in 1.12.5, prints two configuration controls for deployments that use MCP stdio. They are not part of the 1.13.0 bulletin, which prints no workaround, and they do not replace upgrading. They can break existing MCP launch configurations, as IBM says.

Set LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true to reject direct shell-script execution, and set LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true to block non-admin MCP stdio access. Restart the Langflow service after updating its environment configuration.

The documentation also prints a setting for the legacy MCP SSE transport, which is the kind of endpoint the Metasploit documentation describes. The docs do not tie it to any of these CVEs; it is listed because it narrows one MCP surface.

Set LANGFLOW_MCP_SSE_ENABLED=false to return 404 from the legacy SSE transport and its message endpoint.
LANGFLOW_MCP_SERVER_ENABLED: Whether to initialize an MCP server for each of your Langflow projects. (default True)

The question the bulletin leaves open

IBM's summary says the code execution is unauthenticated and reachable through MCP tool enumeration. The project's source says the agentic MCP route authenticates the caller. The record says neither: it says improper control of code generation, no privileges, 9.8. A security vendor supplies the missing link, an auto login session, and a framework module supplies a different MCP endpoint under the same ID. So which request, on which route and under which setting, did IBM score at 9.8, and why should a defender have to assemble that from a vendor's blog and a test module rather than read it in the bulletin?

Key facts