IBM Langflow OSS EUVD-2026-67957

A valid authenticated user account on the IBM Langflow OSS instance is required (CVSS PR:L); unauthenticated exploitation is not possible. The vulnerability is most impactful in multi-user or multi-tenant deployments where users maintain private flows that other accounts should not access. The attacker must obtain or enumerate flow identifiers (e.g., UUIDs) for flows they do not own - this is the principal limiting factor. No non-default configuration is required: the flaw is present in the default application behavior for any deployment running versions 1.0.0 through 1.11.1. Exploitation is limited to authenticated sessions; network reachability to the Langflow OSS API is also required per AV:N.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N scores 6.4 (Medium), reflecting network accessibility, low attack complexity, and the need only for a valid user account. The scope change metric elevates the score by capturing the cross-user boundary violation. No EPSS score was provided in the input data; however, given AC:L and no user interaction required, exploitation probability for any authenticated account holder is non-trivial in multi-user deployments. There is no CISA KEV listing and no public POC has been identified at time of analysis, which lowers immediate urgency relative to a KEV-listed flaw. SSVC signals are partially determinable: exploitation is not yet automated or public, technical impact is partial (read plus execute on scoped resources), and automatable escalation depends on how easily flow IDs can be enumerated. The raw CVSS score of 6.4 somewhat understates risk for multi-tenant deployments where user flow isolation is a core security expectation - the integrity impact of executing another user's private flow may carry significant business logic consequences beyond what C:L/I:L numerically suggests. No conflicting signals were identified in the available data.

An authenticated user on a shared IBM Langflow OSS deployment constructs API requests referencing flow UUIDs belonging to other users - obtained through enumeration, previous access, or educated guessing. Because the application does not validate flow ownership server-side, it returns the private flow definition and allows execution. No public POC exists, but the attack requires only standard API calls with a valid session token and knowledge of a target flow identifier.