IBM Langflow OSS EUVD-2026-71466

The attacker must hold a valid authenticated account on the target IBM Langflow OSS instance (PR:L per CVSS). No special role or elevated privilege beyond a standard user account is required. The vulnerable behavior affects all versions from 1.0.0 through 1.10.2 on all platforms (no OS or deployment-mode restriction indicated). The practical precondition limiting exploitation is that the attacker must be an authenticated user of the same Langflow OSS deployment as the victim - exploitation across completely separate instances is not applicable. There is no requirement for victim interaction. Exploitation impact is limited by scope remaining unchanged (S:U), meaning the attacker cannot escalate beyond the Langflow application boundary to the underlying host.

The CVSS 7.1 score with AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N reflects a realistic threat: a low-privileged authenticated attacker can exploit this remotely with no user interaction and no special attack complexity. The high confidentiality impact is significant in AI workflow contexts, where workflow definitions may encode sensitive system prompts, credentials, or proprietary business logic. The low integrity impact (history injection) is a secondary but real concern for audit trail integrity. Counterbalancing signals: EPSS is only 0.18% (7th percentile), SSVC rates exploitation as none and the vulnerability as not automatable, and no active exploitation or public PoC has been identified. This is a real vulnerability warranting patching but not emergency response - it is exploitable only by already-authenticated users and does not cross scope boundaries. The practical risk is highest in multi-tenant or shared deployments where users have separate workflow ownership boundaries.

An authenticated low-privileged user logs into a shared IBM Langflow OSS deployment, then iterates through workflow IDs (e.g., incrementing integer IDs or enumerating UUIDs via timing/enumeration) in API requests to the workflow history endpoint. By substituting another user's workflow ID for their own, they retrieve that user's full workflow history - potentially exposing embedded API keys, system prompts, or proprietary data. They can also call the history-injection endpoint with a victim workflow ID to plant false entries, corrupting audit trails or misleading downstream automated consumers. No public PoC is required; standard HTTP interception tooling suffices given the IDOR pattern.