CVE-2025-71335: Flowise Session Invalidation Flaw Allows Post-Password-Change Account Takeover

Technical summary

CVE-2025-71335 describes a session persistence vulnerability in Flowise prior to version 3.0.10. The vulnerability stems from incomplete session lifecycle management during password rotation. Specifically, the application fails to invalidate existing session tokens stored server-side or invalidate session identifiers associated with a user account when password change operations occur. This is categorized under CWE-613 (Insufficient Session Expiration), a well-known class of authentication bypass weakness. An attacker with PR (Privileged) access—meaning an existing authenticated session—can maintain that session indefinitely, even after the user has reset their password through normal credential change mechanisms. The CVSS 3.1 score of 8.1 (HIGH) reflects the high impact on confidentiality and integrity, tempered by the requirement that the attacker must already possess an active session.

Business impact

Organizations deploying Flowise for workflow automation face a significant account takeover risk if a session token is compromised or if an employee leaves a device logged in unattended. The failure to invalidate sessions upon password change means that conventional incident response—rotating credentials—becomes ineffective as a containment measure. An insider threat or external attacker with a stolen session token can maintain persistent access across a password rotation, potentially exfiltrating sensitive data, modifying workflows, or triggering unauthorized automations. This undermines both proactive security controls (credential rotation) and reactive incident response procedures, extending the window of unauthorized access and increasing breach dwell time.

Affected systems

Flowise versions 3.0.7 and earlier are confirmed affected. Version 3.0.10 and later contain the fix. Organizations should verify their deployment version immediately, as the vulnerability affects a wide range of installations prior to the patched release. Any Flowise instance running version 3.0.7 or below should be considered at risk.

Exploitability

Exploitation requires the attacker to already hold an active, valid session—either through stolen session tokens, session fixation, or physical access to a logged-in device. Once that session exists, no additional exploitation steps are required; the attacker simply continues using the existing session after the legitimate user changes their password. The barrier to exploitation is moderate: it depends on the attacker's ability to obtain a session in the first place, but once obtained, the persistence of that session is automatic and undetectable through normal means. The vulnerability is not in the wild per CISA's KEV catalog, but the low complexity and high impact make it attractive if sessions are compromised through phishing, malware, or carelessness.

Remediation

Upgrade Flowise to version 3.0.10 or later. This release includes session invalidation logic that terminates existing sessions and tokens when a user changes their password. In environments where immediate upgrade is not feasible, implement compensating controls: enforce strict session timeout policies (e.g., 15–30 minute idle timeouts), regularly audit active sessions and terminate suspicious or stale sessions, restrict session token issuance to short-lived tokens with mandatory refresh, and require multi-factor authentication to increase the difficulty of session hijacking. After patching, consider forcing all users to re-authenticate to clear any compromised sessions in the wild.

Patch guidance

Apply Flowise version 3.0.10 or later as soon as possible. Verify patch application by confirming the version string in the Flowise admin interface or deployment logs. Test the patch in a non-production environment first to ensure workflow automation processes remain uninterrupted. After deploying the patch, consider implementing a coordinated re-authentication event (e.g., a brief maintenance window where all sessions are invalidated) to clear any lingering compromised sessions. Review vendor release notes for any configuration changes related to session management and adjust your deployment accordingly.

Detection guidance

Monitor Flowise logs for password change events and correlate them with subsequent session activity. Legitimate sessions should terminate shortly after a password change; any continued activity from a pre-change session is suspicious. Implement alerting on session tokens that remain active beyond their expected lifetime or that authenticate after a credential rotation. Review authentication logs for unusual login patterns, failed authentication attempts, or logins from unexpected IP addresses or geographic regions. Use session management tools to identify and manually revoke suspicious or long-lived sessions. If Flowise integrates with a centralized authentication provider (LDAP, OAuth, SAML), ensure those logs are monitored for discrepancies between the IdP's session invalidation and Flowise's behavior.

Why prioritize this

Although this vulnerability requires the attacker to already possess a valid session, it fundamentally breaks a core security assumption: that rotating credentials will sever an attacker's access. This makes it a high-priority fix in any organization where session compromise is plausible (which is nearly all). The CVSS score of 8.1 reflects high impact on confidentiality and integrity, and the ease of exploitation once a session exists. Organizations managing sensitive workflows or handling user data through Flowise should treat this as a critical remediation target. The lack of KEV status does not diminish the severity; it reflects absence from CISA's active exploitation list, not the vulnerability's inherent risk.

Risk score, explained

The CVSS 3.1 score of 8.1 (HIGH) derives from: Attack Vector (Network) reflecting remote exploitability via web session; Attack Complexity (Low) because no special conditions are needed once a session is obtained; Privileges Required (Low) because an existing authenticated session is needed; User Interaction (None) because no victim action triggers the persistence; Scope (Unchanged) affecting only the target application; Confidentiality Impact (High) allowing full access to user data; Integrity Impact (High) allowing unauthorized modifications; and Availability Impact (None) because the attacker does not degrade service. The score appropriately penalizes the authentication bypass nature of the flaw while acknowledging that initial session compromise is a prerequisite.

Frequently asked questions