Flowise CVE-2026-56276

Exploitation requires the attacker to hold a valid authenticated session for the target account - the controller enforces currentUser.id !== id which prevents any cross-user modification, strictly limiting this to self-account credential takeover. A session must be acquired through a secondary attack (XSS, token theft, phishing, or session fixation) before this vulnerability can be leveraged; it cannot be exploited without prior authenticated access (PR:L per CVSS). The attacker must know or construct a valid bcrypt-compatible password hash to supply as the credential field value. Exploitation is applicable only to Flowise deployments running in multi-user authenticated mode; single-user or unauthenticated local-only deployments are not exposed. The vulnerability does not enable modification of other users' accounts, lateral movement, or privilege escalation beyond the attacker's own account. The AC:H rating reflects the mandatory prerequisite of prior session acquisition, which is a genuine and meaningful barrier to exploitation.

The CVSS 4.0 score of 6.0 (AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) accurately characterizes this as a moderate-severity, integrity-focused flaw. The high attack complexity (AC:H) is the key limiting factor: this vulnerability cannot be exploited in isolation - it requires an attacker to first obtain a valid authenticated session through a secondary attack such as XSS, phishing, or session token interception. It is therefore a persistence and privilege-consolidation mechanism, not a standalone initial access vector. The high integrity impact (VI:H) reflects the ability to fully hijack an account by overwriting its password hash, rendering the legitimate owner unable to recover without admin intervention. No EPSS data was supplied in the available intelligence. The vulnerability is not listed in CISA KEV and no public POC has been confirmed, suggesting no known widespread or active exploitation at time of analysis. Real-world priority should be driven by exposure: multi-user Flowise instances accessible over the internet or to untrusted authenticated users face meaningful risk, while air-gapped or single-user deployments are effectively unexposed. The AC:H constraint is a genuine mitigating factor and not merely a theoretical one - defenders should focus on eliminating the prerequisite session-theft vectors (XSS hardening, short session TTLs) in addition to patching.

An attacker who has stolen a victim's Flowise session token - for instance by exploiting an XSS vulnerability in the Flowise interface or intercepting a token via an insecure channel - issues a crafted PUT /api/v1/user request containing the victim's user ID and a pre-computed bcrypt hash of an attacker-chosen password in the credential field. Because the server merges the entire request body onto the User entity without filtering, the victim's password hash is silently overwritten with no old-password check, no re-hashing, and no session invalidation triggered. The attacker then logs in with the new password at any future time, maintaining persistent access even after the stolen session has expired and the legitimate user has changed nothing from their perspective.