Langflow Auto-Login Superuser Bypass, RCE via MCP (CVE-2026-93680)

TL;DR

• Langflow OSS versions 1.0.0 to 1.12.8 ship with automatic login enabled by default, and a single unauthenticated GET /api/v1/auto_login returns a full superuser session. IBM scores the flaw, CVE-2026-93680, 9.8 Critical.
• From that session, the same unauthenticated attacker reaches Langflow's MCP endpoint, enumerates its flow-authoring and execution tools and executes custom component code on the server: CVE-2026-110186, also 9.8 Critical. A related flaw, CVE-2026-110193, lets a low-privileged account reach operating-system command execution through the Agentic Assistant.
• Langflow 1.13.0, released October 22, 2026, fixes all of them by turning automatic login off by default; IBM's bulletin of October 28 provides no workaround. The only fixed version is 1.13.0.
• No exploitation of these CVEs has been reported, and none is in CISA's exploited-vulnerabilities catalog as of October 30, 2026. Langflow's previous missing-authentication flaw, CVE-2025-3248, was exploited and is in the catalog with known ransomware-campaign use, so exposed instances should upgrade now.

Am I affected?

All of these must hold for the unauthenticated chain:

• You run Langflow OSS, installed from PyPI, Docker or a release archive, at any version from 1.0.0 through 1.12.8.
• The instance is reachable by anyone you do not fully trust: exposed to the internet, on a shared internal network, or reachable from a container network.
• You did not explicitly set LANGFLOW_AUTO_LOGIN=false and create a real superuser. The default in every affected release is on, which is the vulnerable configuration.

The low-privileged path, CVE-2026-110193, needs only an authenticated account on the instance, any role, plus the Agentic Assistant generating component code. CVE-2026-110192 needs an authenticated account and exposes operator-injected API keys.

Check what you run. For a pip install:

pip show langflow | head -2

For the common Docker deployment, check the running container, not a freshly pulled image:

docker exec langflow python -c "import langflow; print(langflow.__version__)"

Check whether automatic login is active on the instance. Request the endpoint from a machine you control:

curl -s -o /dev/null -w "%{http_code}\n" http://your-langflow-host:7860/api/v1/auto_login

A 403 means automatic login is off and the unauthenticated path is closed. A 200 means the endpoint just handed your request a superuser session, which is the vulnerability; you already control the instance, so nothing was lost by checking. An explicit setting shows in the environment, but an unset variable means the release default applies, which for 1.0.0 to 1.12.8 is on:

docker exec langflow printenv | grep -i AUTO_LOGIN || echo "not set: the release default (on) applies"

How do I fix it?

Upgrade to 1.13.0, the only fixed version, before anything else reaches the instance.

1. Back up the database, the secret key and the uploaded files, as IBM's bulletin directs.
2. If the deployment uses automatic login, prepare the existing account for password sign-in first, following the installation and Docker upgrade instructions the bulletin links. Skipping this leaves you locked out after the upgrade, because 1.13.0 no longer signs anyone in automatically.
3. Upgrade the package:

pip install --upgrade "langflow==1.13.0"

1. For Docker deployments, pull the fixed image and recreate the container, keeping the persistent data:

docker pull langflowai/langflow:1.13.0

IBM's bulletin provides no interim workaround for any of the CVEs. The exposure-reducing step while you schedule the upgrade is to remove untrusted network reach to the instance, through firewall rules or network segmentation. That closes the unauthenticated chain but not CVE-2026-110193, which works from an authenticated account.

What is the root cause?

An unauthenticated endpoint has been handing out superuser sessions whenever a default-on flag is left alone. The flag and the endpoint come from different layers of the code, and an earlier fix closed only part of the path.

The setting lives in the release configuration, src/lfx/src/lfx/services/settings/auth.py at v1.12.8, and every affected release defaults it to on:

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."
    ),
)
"""If True, the application will attempt to log in automatically as a super user."""

The endpoint is GET /api/v1/auto_login, in src/backend/base/langflow/api/v1/login.py. With the flag on, it resolves a superuser and returns the signing tokens as cookies, with no credential anywhere in the request:

@router.get("/auto_login", include_in_schema=False)
async def auto_login(request: Request, response: Response, db: DbSession):
    auth_settings = get_settings_service().auth_settings

    if auth_settings.AUTO_LOGIN:
        auth = get_auth_service()
        user_id, tokens = await auth.create_user_longterm_token(db)
        ...
        response.set_cookie(
            auth_cookie_name("access_token_lf", request),
            tokens["access_token"],
            ...

The function behind it, create_user_longterm_token in src/backend/base/langflow/services/auth/service.py, looks up the configured superuser, or the first superuser in the database, and issues their tokens.

A comment in that function records the earlier fix, referenced as GHSA-fjgc-vj2f-77hm: before it, the endpoint minted a 365-day superuser bearer token; after it, a short-lived access token plus a refresh token. That remediation bounded the token's lifetime but left the endpoint issuing superuser sessions to anonymous callers, which IBM's bulletin calls an incomplete remediation of the auto-login security control.

A constants file in the same service confirms the gap from the API-key side: since v1.5, LANGFLOW_AUTO_LOGIN requires a valid API key on the key-authenticated paths, while the /auto_login route kept issuing sessions. A warning string states plainly that with the flag on, /auto_login is issuing a superuser session without credentials.

The second flaw, CVE-2026-110186, is the code-execution half of the chain. Langflow's MCP endpoint at /api/v1/agentic/mcp exposes the toolkit's flow-authoring and execution tools, and flows can contain custom components, which are Python code that Langflow runs on the server. The routes authenticate the caller through the same session mechanism the auto-login endpoint satisfies, so the unauthenticated chain is: anonymous request, superuser session, MCP tools, component code, server-side execution.

How is it exploited?

No public proof of concept exists for any of the October 2026 CVEs. The steps below reconstruct the path from IBM's bulletin, the CVE descriptions and the v1.12.8 source, not from a published exploit.

1. The attacker sends GET /api/v1/auto_login to a reachable instance that still has the default configuration. The response sets access-token, refresh-token and API-key cookies for the default superuser.
2. Using that session, the attacker connects to the MCP endpoint /api/v1/agentic/mcp over its Streamable HTTP transport and enumerates the exposed tools: flow authoring, flow execution and, where enabled, the assistant.
3. The attacker authors a flow that contains a custom component, which is Python code, and executes it. Langflow runs the component's code on the server as the Langflow process, which is arbitrary command execution.
4. On an instance where no unauthenticated access is possible, CVE-2026-110193 offers the low-privileged variant: an authenticated user asks the Agentic Assistant to generate or submit component code, using patterns the assistant's code scanning did not block before 1.13.0, reaching operating-system command execution.

The 1.13.0 fix set for the assistant, which blocks pydoc imports and NumPy's ctypeslib attribute including aliased and wildcard imports, names two of the patterns that were not blocked.

How does the attack flow?

One sentence: an anonymous request collects a superuser session from the auto-login endpoint, and that session drives the MCP toolkit until a custom component's Python runs on the server.

What can an attacker do?

With the unauthenticated chain, the attacker operates as the Langflow superuser on an exposed instance:

• Execute arbitrary code on the server through custom components, with the Langflow process's permissions. IBM's CVSS vector for both 9.8 CVEs scores confidentiality, integrity and availability high.
• Read and modify every flow, and with them the credentials stored in flow components and connections to model providers and APIs.
• Use the superuser position for everything else the product allows, including creating accounts and API keys.

The conditions: the instance must be reachable by the attacker, and automatic login must be on, which is the release default through 1.12.8. The code-execution step needs no further condition, because custom components are a normal Langflow feature a superuser can always create.

Separately, CVE-2026-110193 gives a low-privileged authenticated account operating-system command execution through the Agentic Assistant, and CVE-2026-110192 lets an authenticated attacker obtain sensitive information through insufficiently protected credentials. IBM rates them 8.8 and 6.5.

Why does the fix work?

The fix removes the anonymous session source by changing the release default. At v1.13.0, src/lfx/src/lfx/services/settings/auth.py reads:

     AUTO_LOGIN: bool = Field(
-        default=True,  # TODO: Set to False in v2.0
+        default=False,  # TODO: Set the development default to False in v2.0.
         description=(
-            "Set to False in production. This will default to False in v2.0."
+            "Enabled by default on development branches; official release packages and tags default to False. "
+            "Set LANGFLOW_AUTO_LOGIN=false to require authentication. "
         ),
     )

The change merged as part of the release preparation for 1.13.0, so official wheels, release-tag source archives and container images ship with automatic login off and require a configured superuser password. With the flag off, /api/v1/auto_login returns 403 and the API-key paths already required a key since v1.5, so the unauthenticated chain in this post has no entry point. Companion fixes in the same release close the other CVEs' paths:

• The assistant's code scanning blocks pydoc and ctypeslib reexport patterns.
• The agentic MCP loopback client no longer inherits the operator-injected LANGFLOW_API_KEY from the server process, and no longer runs tools under another user's identity.
• API-key issuance consults the deployment's sign-in policy at every mint point.

The fix narrows rather than removes: the automatic-login feature still exists, and an operator who explicitly sets LANGFLOW_AUTO_LOGIN=true after upgrading reopens the unauthenticated session endpoint on their instance.

How do I check if I was compromised?

IBM has published no indicators for these CVEs, and a successful auto-login takeover leaves the ordinary traces of normal superuser use, which is what makes log review the main check.

• Search access logs for requests to the endpoint. On an affected instance the path appears as GET /api/v1/auto_login; your own check requests will appear too, so compare source addresses and times.

grep "GET /api/v1/auto_login" /var/log/nginx/access.log | grep -v "127.0.0.1"

• Review flows created or modified during any window when the instance was reachable and unpatched, especially flows containing custom components you cannot attribute to a team member.
• Check the database for accounts, API keys or client registrations created around the same time.
• An attempt that failed, on an instance with automatic login off, leaves only the 403 responses in the access log.

If your instance was internet-facing on a version before 1.13.0 with the default configuration, treat a review as due regardless of what the logs show, because the takeover path needs one request.

Timeline

• 2025-04-07: GitHub publishes the advisory for CVE-2025-3248, unauthenticated code injection through /api/v1/validate/code in Langflow before 1.3.0, the missing-authentication flaw this post's chain echoes.
• 2025-05-05: CISA adds CVE-2025-3248 to its exploited-vulnerabilities catalog, recording known ransomware-campaign use.
• 2026-03-17: GitHub publishes CVE-2026-33017, unauthenticated remote code execution in Langflow through the public flow build endpoint, fixed in 1.9.0.
• 2026-09-29: The Langflow repository merges the release-preparation change that defaults AUTO_LOGIN to false in official release artifacts.
• 2026-10-22: Langflow 1.13.0 is released, carrying the default change and the companion fixes.
• 2026-10-28: IBM publishes its security bulletin for Langflow OSS 1.0.0 to 1.12.8, naming the fixed version 1.13.0 and no workarounds.
• 2026-10-29: IBM updates the bulletin with clarified remediation, and the CVE records for CVE-2026-93680, CVE-2026-110186, CVE-2026-110193 and CVE-2026-110192 are published.

FAQ

Is my instance safe if it is only on an internal network?

No, unless every peer on that network is fully trusted. IBM's CVSS vectors give a network attack vector (AV:N): an attacker needs only a route to the HTTP port, not internet exposure. Any container, laptop or process that can reach the port can collect the superuser session with one request.

Is the MCP endpoint itself unauthenticated?

No. The routes under /api/v1/agentic/mcp authenticate the caller with a session token or an API key. The unauthenticated part of the chain is the auto-login endpoint that satisfies that check without credentials. That is why the fix removes the anonymous session source rather than changing the MCP transport.

Has anyone exploited these flaws?

No exploitation has been reported for any of the October 2026 CVEs, and none of them is in CISA's exploited-vulnerabilities catalog as of October 30, 2026. The 2025 predecessor, CVE-2025-3248, was exploited in the wild, is in the catalog, and carries the catalog's known ransomware-campaign marker, which is the historical reason to treat exposure to this product as urgent rather than theoretical.

What about the Hono vulnerabilities in the same bulletin?

The bulletin also folds in three dependency fixes in Hono, the web framework Langflow bundles, all fixed in Hono 4.13.5: a query-fragment cache-poisoning issue, a denial of service in optional dot-notation body parsing, and a static-site-generation path traversal. They ship with the 1.13.0 upgrade; no separate action is needed beyond upgrading.

I upgraded to 1.13.0; am I done?

Only if you did not re-enable automatic login. The upgrade flips the default off and the setup steps walk you through creating a real superuser password. If your deployment explicitly sets LANGFLOW_AUTO_LOGIN=true to keep the old behavior, the unauthenticated session endpoint returns and stays exposed until you turn the flag off again.

Why did the earlier fix not close this?

The earlier remediation, referenced in the source as GHSA-fjgc-vj2f-77hm, changed what /api/v1/auto_login issues: a 365-day superuser token became a short-lived access token with a refresh token. It bounded the lifetime of the token an anonymous caller receives, but receiving one at all was the vulnerability, and the endpoint kept issuing sessions until 1.13.0 changed the default.

Find the Langflow version you run with Ostorlab

Ostorlab's dependency scans build the full inventory of the Python packages your services and container images install, so you can find every deployment running Langflow 1.0.0 to 1.12.8 and confirm the 1.13.0 upgrade everywhere it matters. Run a scan with Ostorlab to surface the versions before the exposure window grows.

References

• IBM Security Bulletin, "Security Bulletin: Langflow OSS is affected by multiple vulnerabilities", published October 28, 2026 and updated October 29, 2026, with the affected range, the four CVEs, the CVSS vectors, the 1.13.0 remediation and the no-workaround statement: https://www.ibm.com/support/pages/node/7294467 (checked October 30, 2026)
• CVE-2026-93680 record, IBM's CNA entry, published October 29, 2026, CVSS v3.1 9.8, CWE-287: https://www.cve.org/cverecord?id=CVE-2026-93680 (checked October 30, 2026)
• CVE-2026-110186 record, published October 29, 2026, CVSS v3.1 9.8, CWE-94: https://www.cve.org/cverecord?id=CVE-2026-110186 (checked October 30, 2026)
• CVE-2026-110193 record, published October 29, 2026, CVSS v3.1 8.8, CWE-94: https://www.cve.org/cverecord?id=CVE-2026-110193 (checked October 30, 2026)
• Langflow 1.13.0 release notes, published October 22, 2026, listing the automatic-login default change and the companion security fixes: https://github.com/langflow-ai/langflow/releases/tag/v1.13.0 (checked October 30, 2026)
• The pull request that turns automatic login off by default in release artifacts, merged September 29, 2026: https://github.com/langflow-ai/langflow/pull/14993 (checked October 30, 2026)
• Langflow v1.12.8 source: the AUTO_LOGIN default in src/lfx/src/lfx/services/settings/auth.py, the /auto_login route in src/backend/base/langflow/api/v1/login.py, and create_user_longterm_token with the earlier-fix comment in src/backend/base/langflow/services/auth/service.py, read at the v1.12.8 tag: https://github.com/langflow-ai/langflow/tree/v1.12.8 (checked October 30, 2026)
• Langflow v1.13.0 source, showing the flipped default: https://github.com/langflow-ai/langflow/blob/v1.13.0/src/lfx/src/lfx/services/settings/auth.py (checked October 30, 2026)
• The agentic MCP route and its authentication, src/backend/base/langflow/api/v1/agentic_mcp.py at v1.12.8: https://github.com/langflow-ai/langflow/blob/v1.12.8/src/backend/base/langflow/api/v1/agentic_mcp.py (checked October 30, 2026)
• GitHub advisory for CVE-2025-3248, Langflow's earlier missing-authentication flaw, published April 7, 2025, fixed in 1.3.0: https://github.com/advisories/GHSA-c995-4fw3-j39m (checked October 30, 2026)
• GitHub advisory for CVE-2026-33017, unauthenticated RCE through the public flow build endpoint, published March 17, 2026, fixed in 1.9.0: https://github.com/advisories/GHSA-vwmf-pq79-vjvx (checked October 30, 2026)
• CISA Known Exploited Vulnerabilities catalog, where CVE-2025-3248 was added on May 5, 2025 with known ransomware-campaign use, and none of the October 2026 Langflow CVEs is listed as of October 30, 2026: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (checked October 30, 2026)
• Langflow repository, 156,160 stars as of October 30, 2026, for the project's scale: https://github.com/langflow-ai/langflow (checked October 30, 2026)
• Langflow Docker Hub repository, 4,482,343 pulls as of October 30, 2026: https://hub.docker.com/r/langflowai/langflow (checked October 30, 2026)
• PyPI download statistics for langflow, 37,742 downloads in the 30 days before October 30, 2026: https://pypistats.org/packages/langflow (checked October 30, 2026)