IBM Langflow OSS CVE-2026-7663

Exploitation requires network reach to the Langflow OSS Streamable MCP transport endpoint on an affected instance (versions 1.0.0-1.9.6) that has MCP project resources configured/exposed; per CVSS PR:N/UI:N no authentication or user interaction is needed, so any exposed endpoint is directly reachable by unauthenticated remote attackers. The primary limiting factor is exposure of that specific Streamable MCP endpoint - instances that do not expose the MCP transport to untrusted networks, or that gate it behind an authenticating proxy, are not practically reachable; there is no observed exploitation (SSVC Exploitation: none, not in KEV) and no public exploit code identified at time of analysis.

The signals are mostly aligned toward a genuine, high-priority network exposure but with a nuance. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H, 9.8) describes trivially remote, unauthenticated, low-complexity exploitation with total impact, and SSVC corroborates this with Technical Impact: total and Automatable: yes. However, SSVC Exploitation is 'none' (no observed or public exploitation), it is not on CISA KEV, and EPSS is only 0.24% (15th percentile) - meaning that despite the critical score, real-world exploitation is not yet observed or widely predicted. The gap between a 9.8 base score plus 'automatable: yes' and the low EPSS is best read as a freshly disclosed vendor-reported issue that has not yet attracted public exploit tooling, rather than a low-risk issue: the exposure is severe for any internet-reachable Langflow instance, so it should be patched promptly even though mass exploitation is not currently indicated. Note the CVSS A:H (availability) impact is not obviously explained by the description, which centers on unauthorized access and operation execution - verify the availability impact against IBM's advisory.

An attacker who can reach a Langflow OSS instance's Streamable MCP endpoint over the network sends crafted requests to the transport without any credentials, and because authorization is not enforced, the server returns protected MCP project resources and executes MCP operations on the attacker's behalf. No user interaction or prior authentication is needed, so an internet-exposed instance can be abused directly; no public proof-of-concept has been identified at time of analysis.