Flowise CVE-2025-71335

Exploitation requires the attacker to already hold a valid, active Flowise session or session token for the target account - obtained through a stolen/captured session cookie, a hijacked token, or physical access to a device left logged in (PR:L reflects this pre-held authenticated session). No user interaction is needed from the victim beyond the conditions that already granted the attacker the session. The specific trigger context is the victim performing a password change (or reset) on an affected instance: the vulnerability manifests precisely because that credential-rotation event fails to terminate other active sessions. Limiting factors: the attacker cannot exploit this from nothing - they must first acquire a session by other means, the target must be running Flowise 3.0.7 or earlier, and the impact is scoped to the account whose session was captured; it does not grant cross-account or unauthenticated access.

The CVSS 4.0 base score is 8.6 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N and high confidentiality and integrity impact (VC:H/VI:H, VA:N). The PR:L metric correctly reflects that exploitation is not unauthenticated-from-zero: the attacker must already possess a valid session (stolen token, hijacked cookie, or an unattended logged-in device), so this is a post-compromise persistence weakness rather than an initial-access vulnerability. That nuance is important - the high score assumes the precondition of an already-held session, and the real-world severity is gated by how the attacker obtained that session in the first place. No EPSS score was provided in the input, and the vulnerability is not listed in CISA KEV, so there is no signal of widespread automated exploitation; however, a concrete reproducible PoC is published by the vendor, lowering the barrier to manual abuse. SSVC framing: exploitation status is PoC (not active), technical impact is total for the affected account, but automatable is effectively No because each instance requires a separately obtained valid session. Net assessment: a genuine and easily understood weakness that matters most in breach-response scenarios, but not a mass-exploitation emergency - prioritize patching where Flowise holds sensitive workflows or is internet-exposed.

An attacker obtains a valid Flowise session - for instance by capturing a session cookie from a shared or public machine, or by using a device the victim left logged in. The victim later notices something is wrong (or routinely) and changes their password expecting it to lock the attacker out, but because Flowise never invalidates the pre-existing session, the attacker simply refreshes the page and continues operating as the legitimate user. The published PoC (change password in one browser, refresh a second already-logged-in browser, still authenticated) confirms this works with no special tooling.