IBM Langflow OSS EUVD-2026-77781

The attacker must first hold a valid, authenticated Langflow OSS account (CVSS PR:L) on an instance running versions 1.0.0 through 1.10.2, and must be able to reach the Langflow web UI or REST API over the network (AV:N) with the password-change functionality enabled and reachable - this is a default, always-on feature of the product, not an optional module. No victim user interaction is required (UI:N) and attack complexity is low (AC:L); the only genuine prerequisite is the authenticated session plus knowledge or enumeration of the target account identifier. Exploitation is limited by the fact that unauthenticated external attackers cannot trigger it at all, by the requirement that a second, pre-existing account be the target, and by CISA SSVC judging the issue non-automatable with only partial technical impact - meaning a single successful hijack gains one account's rights rather than instance-wide control, unless the victim happens to be an administrator.

The signal set is mixed but leans toward a moderate, contained risk: CVSS 5.4 with PR:L and UI:N means the attacker must already hold a working account, so this is not a pre-auth mass-exploitation bug, while CISA's SSVC assessment explicitly states Exploitation: none, Automatable: no, and Technical Impact: partial - the strongest available evidence that this is not currently a wormable or scripted-at-scale issue. There is no KEV listing and no public exploit code identified, so the practical threat is a malicious or compromised insider account, a shared multi-tenant Langflow deployment, or lateral movement after an unrelated credential leak; even so, a mid-sized municipal IT team in gniezno running a shared Langflow instance should treat this as urgent enough to patch on the normal maintenance cycle rather than an emergency, given that account takeover can hand over stored LLM provider keys. Note the gaps: no EPSS score was supplied, so probabilistic exploit likelihood cannot be quantified, and the temporal picture rests solely on SSVC and the absence of KEV/POC - the CVSS integrity-only impact (I:L, C:N) somewhat understates downstream risk if the hijacked account is an administrator, so defenders should not read 5.4 as negligible.

An attacker who has obtained or been granted a low-privileged Langflow account - for example a contractor login on a shared instance - sends a crafted HTTP request to the password-change API naming a different user's identifier, and because the endpoint fails to verify that the caller owns the target account, the victim's password is reset to an attacker-chosen value. The attacker then logs in as the victim; if that victim is an administrator or flow owner, the attacker inherits access to flows and the LLM provider credentials stored inside them. Exploitation is low-complexity and requires no user interaction, but is not automatable per SSVC and no public exploit code is known, so the realistic vector is an insider or a compromised credential rather than opportunistic internet scanning.