Safeguard
Vulnerability Analysis•

CVE-2026-7663: Critical MCP Auth Bypass in Langflow OSS

CVE-2026-7663 is a critical authorization flaw in Langflow OSS 1.0.0 to 1.9.6 on the streamable MCP endpoint. Upgrade to 1.10.0 and check MCP Composer use.

Safeguard Security Team
3 min read

CVE-2026-7663 is a critical (CVSS 9.1) authorization bypass in Langflow OSS 1.0.0 through 1.9.6. Unauthenticated users can reach other users' MCP project resources through the Streamable transport endpoint, and run MCP operations. IBM recommends upgrading to Langflow 1.10.0. No workaround is listed.

What's affected

  • Product: Langflow OSS, as described in the IBM security bulletin.
  • Affected: 1.0.0 through 1.9.6.
  • Fixed: 1.10.0.
  • Weakness: CWE-285, improper authorization, and CWE-863.
  • CVSS 9.1 (critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Not listed in CISA KEV.

Per the bulletin, exploitation needs network access to a Langflow instance with MCP Composer enabled, and target projects using OAuth or another non-API-key mode. The SSE endpoint is not affected. The problem is specific to the Streamable transport path.

How to check if you're exposed

Check the installed version.

pip show langflow

For container deployments, read the image tag. Then see whether MCP Composer is turned on and whether any projects use OAuth authentication for MCP. If both are true and you are on 1.9.6 or older, treat the instance as exposed. The bulletin says the abuse can reveal private tool metadata, project files and flow definitions, and let a caller run MCP tools with superuser rights.

What to do now

  1. Upgrade Langflow OSS to 1.10.0 or later, and redeploy.
  2. Until you can, restrict network access to the instance to trusted users and networks, since no workaround exists.
  3. Review which MCP projects use OAuth, and which tools they expose.
  4. Check access logs for requests to the Streamable MCP project path from callers you do not know.
  5. Rotate secrets that flows or uploaded files may contain if you find suspicious access.

Why it matters

The cause is improper authorization on one transport. The same project resources were protected on the SSE endpoint but the Streamable path did not enforce ownership. This pattern shows up often when a service grows a second way to do the same thing.

Agent platforms make the cost high. An MCP tool is an action, so unauthenticated access can mean running tools with the service account's rights. Test every transport and route for the same authorization rules, not just the first one you built.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Is the SSE endpoint safe?

IBM says the flaw is specific to the Streamable transport path and that the SSE endpoint is properly secured.

Is there a mitigation?

The bulletin lists none. Upgrade to 1.10.0, and limit network access in the meantime.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.