IBM Langflow OSS EUVD-2026-113147

Requires an authenticated Langflow OSS account that holds a read or share grant on a target flow owned by another user, and that target flow must contain stored third-party credentials. Exploitation is limited to versions 1.0.0 through 1.12.3 and is only meaningful in multi-user/shared deployments where flows are shared across accounts - a single-user or unshared installation lacks the cross-user grant that the attack depends on. Authentication is required (CVSS PR:L), so this is not remotely exploitable by an unauthenticated attacker; no user interaction by the victim is needed.

This is a moderate-priority credential exposure flaw, not an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) indicates network-reachable, low-complexity exploitation but requires authentication (PR:L) - specifically an account that already holds a read or share grant on a victim's flow. The high confidentiality impact (C:H) is justified because stored third-party credentials are returned in cleartext, but there is no integrity or availability impact. The vuln.today Decision label is 'this_month,' consistent with a real-but-not-urgent issue. There is no CISA KEV listing (not confirmed actively exploited), no public exploit reference in the input, and no EPSS score provided, so widespread opportunistic exploitation cannot be inferred. The practical risk concentrates in multi-tenant or team Langflow deployments where flows containing API keys/secrets are shared across users; in single-user installations the sharing precondition largely eliminates exploitability. No signals conflict: all available data points to a legitimate but access-gated information-disclosure bug rather than a mass-exploitation threat.

In a shared or multi-user Langflow OSS deployment, an attacker holds a legitimate low-privilege account that has been granted read or share access to a flow built by another user. The attacker queries the flow via the API and receives the owner's stored third-party credentials (e.g., LLM provider or external service API keys) back in cleartext, which can then be reused to access those external services. No public exploit code is referenced in the input, but exploitation is low-complexity once the grant exists.