Flowise CVE-2025-71328

Exploitation requires an authenticated Flowise session (PR:L): the attacker must either be a legitimate low-privileged authenticated user acting against their own/another reachable account, or must hijack, fixate, or coerce an existing authenticated session. The specific enabling condition is that the account settings Security password-change feature does not enforce a current-password check, so any actor with valid session context can complete the change. Limiting factors that constrain realistic risk: a valid authenticated session is mandatory (no unauthenticated remote takeover), exploitation against another user's account depends on first stealing or coercing that user's session, and the issue is fully neutralized in version 3.0.10 and later. No special non-default configuration is required - the weakness is present in the default account settings flow of affected versions.

The vendor-supplied CVSS 4.0 base score is 8.7 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L, indicating remote, low-complexity exploitation by an already-authenticated low-privileged user with no user interaction, yielding high confidentiality and integrity impact. The key nuance is PR:L: this is not an unauthenticated remote takeover - it requires an authenticated session, so the realistic threat is session hijacking, session fixation, CSRF, or coercion of a logged-in user rather than mass internet-wide exploitation. No EPSS score and no KEV status were provided in the input, so probabilistic exploitation likelihood and confirmed active exploitation cannot be assessed from available data; SSVC decision inputs (automatable, exploitation status) were likewise not supplied. A working PoC is publicly documented, which raises practical risk, but absent KEV/EPSS signals this should be treated as a real-but-conditional priority: patch promptly given low attack complexity and a public PoC, while recognizing the authentication prerequisite limits indiscriminate exploitation.

An attacker obtains an authenticated Flowise session - for example via a stolen or fixated session cookie, a shared workstation left logged in, or a CSRF/coercion technique against a logged-in user - and navigates to the account settings Security section. Because no current password is required, the attacker submits a new password and immediately locks the legitimate owner out, achieving full account takeover; a public PoC with exact repro steps and a screenshot is documented in the GitHub Security Advisory.