Flowintel EUVD-2026-67132

The attacker must already possess a valid, active session token/cookie for a target Flowintel account (>=3.3.0) - obtained from prior access, session theft, XSS, a shared/compromised device, or a leaked cookie; this is the AT:P attack requirement. The flaw cannot be used to gain initial access on its own: it only extends access that was already established. The limiting factor is precisely that precondition - without a pre-existing session, there is nothing to exploit - and the impact is bounded to whatever the compromised account can do. Local-auth accounts are the target (admin_edit_user_core gates on auth_provider == 'local'). No user interaction or additional authentication by the attacker is needed once the token is held.

The provided CVSS 4.0 score of 9.1 (Critical) is driven by AV:N/PR:N/UI:N with high confidentiality and integrity impact, but the vector also carries AT:P (attack requirement present), which is the crucial nuance: this flaw is not independently exploitable and only matters once an attacker already controls a valid session token. It is therefore best understood as a defense-in-depth / containment failure that defeats password reset as an incident-response action, rather than a primary initial-access vulnerability, so the effective real-world severity sits below the raw 9.1. There is no EPSS value, no KEV listing, and no public POC in the input, so exploitation appears theoretical or targeted rather than mass-scale at present. That said, the scenario it enables - an attacker surviving the victim's remediation attempt - is exactly what makes account-takeover incidents drag on, so even a mid-sized security team should prioritize patching once any session compromise or credential-theft concern exists on a Flowintel deployment.

An attacker obtains a valid Flowintel session token - for example via a stolen cookie, a shared or hijacked browser session, or earlier account access. The victim notices something wrong and changes their password to lock the intruder out, but on unpatched versions (>=3.3.0) the attacker's existing session is never revoked and continues to work until it naturally expires, letting the attacker keep reading cases and modifying data. No public POC is required beyond replaying the already-held session cookie.